Contents: What is this IA stuff? Going to West Point to see Gene SITAR: The researchers strike back The SITAR architecture Next time About the author Resources About the author Rate this article Related content: Encrypting with Stunnel Mind your FAQs Subscriptions: dW newsletters dW Subscription (CDs and downloads)

Larry Loeb (larryloeb@prodigy.net)
Author, Secure Electronic Transactions
01 Jun 2001

Information Assurance (IA) is a technique used by large organizations such as the military to deal with the large volumes of information. Its goal is to make sure the information used is transmitted and computed in a non-corrupted state. Developers can use some of these techniques in their own work to keep information states pure. In this two-part article on the IEEE Systems, Man, and Cybernetics Information Assurance Workshop, Larry Loeb takes a look at the evolution of IA and what it means from a security standpoint. Here in Part 1, he explores Dr. Eugene Spafford's keynote address, and takes detailed look at SITAR, an architecture that was presented at the conference.

When an organization is so large that information becomes another fungible commodity for it to use, it wants and needs assurance that the information it feeds on is accurate and untainted. Recent consolidations in the technical industry (especially in the aerospace sector) have created even larger organizations than were the norm just a few years ago. This consolidation parallels the rise of "information assurance" (IA) as an IEEE special interest group in the last year. Just as the actual quality of a product is only one part of "quality assurance," so security is only one part -- albeit central -- of the overall information assurance effort.

What is this IA stuff?
By itself, security is usually implemented in large organizations as a threat-reactive process. It deals with the abnormal, which is measured relative to what is agreed to be the normal configuration of something -- as in, someone hacks your network and you respond to the hack. IA is more than this: It includes security, sure -- but as a metric. In IA situations, the outcome of security processes must be measured, and the results of those outcomes reported so that they can be effectively acted on. This closes the loop on an organization's information flow. Any organizational researcher will tell you how useful it is to provide feedback to a group effort, and that's what IA should be doing on a macro scale.

Figure 1: Information assurance model

Figure 1 delineates three of the four dimensions of IA (the fourth being time). Over time (and change) there can be several of these discrete "McCumber"-like models (so named from John McCumber's 1991 paper on INFOSEC) along the timeline of an organization. Each of the models might not link to other ones, but they still reflect the concerns that IA deals with.

The large organizations that are trying the IA approach hope to automate the underpinnings of information collection while at the same time implementing any security services that might be needed. At this high level of data flow, automation of some processes is both desirable and necessary. Otherwise, decision makers become drowned in data -- much like reading raw console traffic. Instead of an Intrusion Detection System (IDS) ringing the system administrator's pager and stopping there, IA would have the IDS post the event to a feedback file (not just a console log) for later review. Whatever the system administrator does in response should also be picked up and put into the same feedback file. Ideally, all the security efforts in a system are integrated into the IA review.

Going to West Point to see Gene
The Second Annual IEEE Systems, Man, and Cybernetics Information Assurance Workshop (held at the U.S. Military Academy at West Point, NY) brought together some of the bigger players in the IA space for two days of "show and tell" plus all the hallway schmoozing you could want. As with any good conference, you end up learning as much from your lunch companions as you do from the formal presentations. The presentations were no slouch, though, and you know you're in the right place when Dr. Eugene Spafford is giving the keynote.

And what a keynote it was. Spafford, the Director of the Center for Education and Research in Information Assurance and Security at Purdue University, was one of the Internet's architects, referees, and early adopters (see Resources). He has done so much for the computing industry, and the Internet in particular (and continues to do so through the Association for Computing Machinery), that it's impossible to summarize. His keynote offered some plain talk about security and the IA effort that put the rest of the upcoming conference in perspective. Any developer who actually has to work with the rivets of security would have felt at home at the keynote. For Spafford really just told attendees what they might not have wanted to hear, but had to be told anyway.

He started by saying that he had to give current security efforts a "poor" rating, mainly due to the widespread use of commercial off-the-shelf (COTS) OS systems on PCs. He contended that the very use of the most popular proprietary (and unnecessarily large) OS on a PC presents a demonstrable risk to the underlying data flow. The COTS problems illustrates the deviance of commercial software design -- which favors the cheaper ship-it-and-then-patch-it approach -- from what should be the preferred design approach: Specifying and revising system performance goals until they are obtainable and verifiable, and only then coding anything.

Spafford posited there is one "hidden" error per 500 lines of "checked" code (which is the kind of code that is released commercially). So, if this ratio were applied to, say, the most widely-used OS COTS with its 30 million lines of code, Spafford would expect to find about 6,000 unfixed errors. Because users seem to complain to the manufacturer about only 5% of the total number of errors, fixing all 100% of them would be not economically advantageous to a company since 95% of the errors are seemingly not noticed by the users. Of course, knowing which 5% are going to hit the fan would be advantageous, but with a ship-then-patch mentality it doesn't seem to matter much.

The coding languages used in most commercial software (C and C++) came under fire as well for being architecturally impossible to truly test, thus making the resultant software untestable on a low-level basis. Spafford offered no panacea to these ills, but acknowledged that some of them have been present since mainframe days. A 30-year-old Air Force report bemoaned the unsuitability of then-current technology for security purposes. That the problem still exists does not invalidate what he called the "wonderful research going on" that was to be talked about at the conference, but points out that this research will not solve -- because it was not commissioned to solve -- what Spafford considers to be a sick horse pulling a well-maintained and intricately designed coach. Achieving the goal of actually getting somewhere requires that both parts work together.

SITAR: The researchers strike back
While Spafford migh have been dismissive of the "wonderful research," there were some presenters directly addressing his problems with the use of COTS. One paper described "SITAR: A Scalable Intrusion-Tolerant Architecture for Distributed Services," which has as its core two general concepts. The first is that security precautions -- no matter how extensive -- must fail at some point. They cannot guarantee that a system will not be penetrated. (Think of it as the Second Law of Thermodynamics applied to security.) The second concept is that even if compromised or under attack, a mission-critical system needs to provide a minimum level of services; SITAR places importance on the continuity of operation. The first derivative of these ideas is that attack effects are more important than attack causes. A system must be able respond to adverse situations while delivering services, regardless of whether these situations originated from hostile action or from system failure.

Consider this approach applied to intrusion detection. Focusing on the attacks themselves will by definition fail, because, in the real world, there will always be an unknown-at-design-time attack. Intrusion tolerance will focus on the functions and services that require protection (that is, be made intrusion-tolerant). Triggers for action will be based only on those events that pose a threat, rather than on general, arbitrary events. Because these events are more defined (and hence, constrained) than the general case, they are more easily solvable.

The SITAR architecture

Figure 2: A generic, intrusion-tolerant service architecture

Figure 2 shows the main SITAR elements (within the dotted lines) and their relationship to one another. This system is protecting a generic server farm, which is using a known-insecure COTS as its operating system. SITAR uses redundancy and diversity to implement its fault tolerance.

Proxy servers are the public access points of SITAR. They are where requests come for processing. Proxy servers enforce the service policy specified by the operative intrusion strategy. The policy tells which server(s) the request should be forwarded to, as well as how results from the server(s) should be adjudicated to arrive at a final response. Policy also defines the criteria for external attack triggers that the proxy server generates and passes to the adaptive reconfigurative module (ARM). This is done with intrusion detection software that is rule-based, protocol-based, and statistically based. The ARM can adjust the level of access control imposed on the clients, degrees of redundancy used to fulfill client requests, and increased auditing.

Figure 2 shows (as thin lines going to the COTS servers) the requests that the proxy server is handling for the client. The relevant ballot monitors and acceptance monitors involved (more on these structures later) are also notified of these requests as they occur.

When responses from the COTS servers have been generated (shown in Figure 2 as the thick lines going from right to left) they are routed to the acceptance monitors where a validity check is performed. This check is forwarded with the server response to the ballot monitors. Acceptance monitors also perform compromise monitoring on the COTS server, which produces triggers that go to the ARM.

Figure 3: Architecture of acceptance monitor

Ballot monitors decide on a course of action either though a simple majority vote or some Byzantine agreement process. The final action is dependent on the current level of detected security threat and is forwarded to the proxy server for delivery to the client that initiated the request. Before balloting can occur, the secure hash value of some result must be calculated. SITAR can use the Fletcher checksum (which is used in the OSI network and transport layers), MD5 checksum (which is 128 bits and considered more reliable than the Fletcher checksum), and Keyed MD5 (used if the messages from a possibly compromised acceptance monitor must be authenticated before use).

One voting machine can serve as an announcer to the proxy servers, telling them the voting results. It's also possible to have a dynamic announcer setup, where different ballot monitors serve as announcers for different requests. Or, the proxy server might just be informed directly by all the ballot monitors of what their individual vote is. It depends just how tolerant you want the system to be -- as well as what performance hits you might want to take to get there.

Single ballot voting is suitable for benign situations, but when the ARM says one or more of the voting machines are compromised, then the shift must be made to distributed voting.

The ARM obtains input from all other modules, and evaluates threats, tolerance objectives, and cost/performance impact. What it comes up with based on all of these factors is a new configuration for the system that it implements.

The audit control module (ACM) audits the behavior of everything else in the system, based on signed logs that each of the other modules produce. The audit records contain information about such things as logins, command executions, file access, and the like. Additionally, the ACM can run diagnostic tests.

In short, SITAR accepts that COTS will fail, and tries to put a filter of sorts in front of it. Though not yet implemented in commercial-level software, this architecture holds the promise of being able to respond to failure by still delivering essential services. The continuity of system operation is the primary design goal of SITAR.

Next time
In Part 2, we'll take a broader view of IA and what it means to a developer. We'll also look at other relevant IA examples and research going on in the field.

About the author

BYTElarryloeb@prodigy.net

Resources

• Cipher is the electronic newsletter of the IEEE's Technical Committee on Security and Privacy.
  
  
• For more on SITAR (Scalable Intrusion-Tolerant Architecture) visit http://www.anr.mcnc.org/projects/SITAR/SITAR.html.
  
  
• Read the USA Today article about Dr. Eugene Spafford as well as his Purdue University faculty listing.
  
  
• See the official site for the IEEE Systems, Man, and Cybernetics Information Assurance Workshop.
  
  
• Find out the latest IBM security news.
  
  
• IBM WebSphere's Web Trust Association feature allows you to enable entry-level authentication with a third-party security server, and then lets the application server handle the rest of the authorization. Here's how.
  
  
• Return to the Security special topic here on developerWorks for more security resources.
  

Rate this article This content was helpful to me: Strongly disagree (1) Disagree (2) Neutral (3) Agree (4) Strongly agree (5) Comments?

developerWorks > Security >