March 14, 2006 () Editor’s note: As NIST gathers this spring to ponder a common event-logging format, the pressure on vendors to hew to at least basic common event-logging and audit structures makes itself plain throughout the industry. Mary Ann Davidson, chief security officer at Oracle Corp., shares her thoughts on what’s at stake.
When it comes to IT security, it often seems that vendors would rather build and sell a point solution to customers -- solving just one problem in a proprietary way -- than play nicely with other vendors to improve the security landscape for all. This is painfully apparent in the area of event logging and auditing (or eventing).
There’s an old maxim, “For want of a nail, the shoe was lost; for want of a shoe, the horse was lost,” culminating in “… the kingdom was lost.” The lack of common event logging and auditing requirements -- and a common format for that data when collected -- may well result in our collective network kingdoms being indefensible. Furthermore, a kingdom that can’t be defended can indeed be lost.
Nowhere is the need for a common requirement more apparent than in the U.S. Department of Defense. The DOD’s Global Information Grid (GIG) program seeks to connect physically separate networks (for classified, unclassified and war-fighter information) so that selected intelligence information can flow in real time to a combatant accessing information wirelessly in a battle zone.
However, removing the physical barriers to network connectedness heightens the risk profile for the collective DOD network. The network itself becomes the battlefield, since the DOD’s entire war-fighting capability is based on an IT backbone. Just as combatants need “situational awareness” on the physical battlefield – Where are my forces? Where are the enemy’s forces? – they will need situational awareness for the IT backbone on which their capabilities depend. Opposing forces might not be able to muster superiority of arms, but they’re likely to find it worthwhile to attack the network, thereby disrupting the DOD’s ability to wage war.
The DOD’s prospects for situational awareness of that IT backbone are severely hampered by the fact that the off-the-shelf software on which much of its systems depend – commercial operating systems, routers, firewalls, databases, directories and applications – often have little or no auditing. Moreover, what auditing data exists is not expressed in a common format. While third-party software can parse and redact multiple log file formats, consolidate them and “connect the dots” to show related activity, their job would be markedly simpler if at least some core data were both collected and expressed in the same way across products. (And of course, if no data exists, these products cannot correlate data at all.) The value these vendors add is largely not in their ability to perform the network security equivalent of translating Coptic, Koinic Greek and Hebrew into English, but in being able to correlate information, which is a data warehousing problem. Translation in that situation is just the cost of correlation.
Though its data processing may have more direct life-and-death outcomes than that of the average office, the DOD is not the only organization that needs situational awareness on its networks. Increased interconnectedness and fluidity of networks – not to mention the bogeyman of regulatory compliance – make it ever more critical for network administrators, or chief security officers, to answer questions like, Who is on my network? What are they doing? What activities should I be concerned about? Few can answer these questions in anything like real time, in part because of the lack of audit and event records as well as the incompatibility of file formats for the records that are created.
The U.S. government has a key role in resolving this impasse. First of all, the DOD has a critical need for better situational awareness on its network, because the network is the battlefield. Secondly, the U.S. government has entities whose job it is to produce technical standards -- specifically, the National Institute of Standards and Technology. NIST has an excellent track record of producing technical standards in conjunction with industry (meaning that the standards are not developed in an ivory tower but are vetted by the people who have to implement them).
Second, creating standards is NIST’s day job. Unlike industry players, the organization has no other agenda. NIST’s only goal is to make things work better for everybody. Third, the government is a large procurer of IT systems and software, to the tune of many billions of dollars each year. As a major customer base, it has the potential to move the marketplace to meet its needs.
Lastly, the government is in the business of promoting the public good. It’s one of the reasons it exists. Having a common logging and auditing standard promotes the public good.
To make an off-line analogy, how well would 911 work if, in each jurisdiction, the phone number to call for assistance were different? How well would it work if a user in Omaha called up 911 and said, “He pilikia ko'u!”? (That's Hawaiian for “I have a problem!”) Without a common framework and language for auditing and logging, we can’t begin to address problems in real time.
To reach back into history, prior to the 1860s, there was no standard railroad gauge. Passengers literally got off one line, carried their baggage down the track to the next train and got on. To promote the common good of coast-to-coast rail access, the U.S. government standardized the train gauge (at feet’ 8.5 inches) in conjunction with building the transcontinental railroad, stepping in and enforcing a technical standard the railroad industry would never have agreed to on its own.
We're long overdue for a common logging and auditing format. Therefore, I am pleased to note that NIST is hosting a sorkshop on a standard for COTS Logging Information Exchange” (CLIX) in Gaithersburg, Md., on May 17. I urge all interested parties to participate so that we might – for the public good – increase our collective ability to know who is on our networks and what they are doing. Our kingdoms will be more secure if we do.
Mary Ann Davidson is chief security officer at Oracle Corp., responsible for security evaluations, assessments and incident handling. She represents Oracle on the board of directors of the Information Technology Information Security Analysis Center and is on the editorial review board of the Secure Business Quarterly.
Davidson has a BSME from the University of Virginia and an MBA from the Wharton School of the University of Pennsylvania. She has also served as a commissioned officer in the U.S. Navy Civil Engineer Corps, where she was awarded the Navy Achievement Medal.