The NSFF ( http://nsff.xservices.com) is a working group established by NSA to discuss DoD security needs. It meets about once every six weeks at the Maritime Institute near Baltimore MD. The following is a synopsis of one such workshop on MLS held 2 March 1998 in Baltimore. The meeting consisted of three main parts: MLS Past (a history of MLS), MLS Present (what's going on today), and MLS Future (what we should expect), plus an introductory session, a lunchtime session on their framework, and a wrapup Q&A session. There were about 250-300 attendees. For the number of words spoken, there were amazingly few interesting things said. The one sentence summary is that nothing is new in the wonderful world of MLS: some people think we still need it, other people thing guards do the job just fine, and there are very few new ideas on how to solve the problems that MLS was designed to address.
This report consists of two parts: the few interesting points and a summary of the sessions. The opinions are those of the author, and not necessarily those of his employer!
INTERESTING POINTS
Among the more interesting points in the meeting were:
* Some people are still arguing for MLS operating systems (e.g., Jim
Anderson).
* While most vendors were represented, there were no representatives from
Microsoft there.
* At a recent high level meeting Microsoft was asked (by government
representatives) about their plans for MLS, and was told that Microsoft has
no interest in MLS.
* For the forseeable future, there's no real alternative to guards, even
though they're admittedly dangerous.
* The hacker community (specifically, Phrack) has copies of the attack
scripts used against the Pentagon in February, and is trying to decide
whether to post them on their web site. (This was hallway chatter, not a
presentation.)
SESSION SUMMARY
Session 0: Welcome, etc.
Dave Luddy (NSA X1) talked about the first public draft of "DoD Technical Framework for User/Applications-Layer Security Services" (formerly known as "Technical Framework for DoD Security Enabled Desktops") which is now available on their web site; and they are seeking industry feedback. The goal of the framework is to provide guidance on what's available today, as well as to guide industry on what NSA thinks is needed for tomorrow. The next NSFF meeting (April 16 & 17) is to discuss feedback on the framework. [As this article was going to press, that date has been cancelled. The workshop will be rescheduled for the summer.]
Session 1: MLS Past
Summary: We have the same MLS problems we've always had, and government has done a lousy job solving them.
Grant Wagner (NSA, session chair) reviewed what MLS is, and what the environment was (mostly large non-networked systems that were too expensive to afford one per classification). He then explained the attempted simplification of the yellow book (risk indexes) and how they tried to make it mandatory, with the goal of stimulating market demand. NSA tried to push vendors to build MLS products, but it failed miserably. The reasons for that failure included vendors and customers not believing in the threats (since NSA kept the good stuff classified), the lack of rewards to industry (government promised to buy MLS systems, but didnt in sufficient numbers to pay back the vendor investment), and customers were more interested in features than in security. Perhaps the most important reasons, though, are that (1) systems became too complicated for any real assurance and (2) the time to market overcame everything else in the product development processes. What we should do is return to original goals, by getting vendors and customers to sign on. The need is greater than ever: we have real attackers, mobile/malicious code, and risk management is harder than ever.
David Bell (Mitretek) also talked about what went wrong. We didnt leverage what we knew into new products and development. We set our goals too low: C2 by 92 set a minimum (which we missed) instead of trying for MLS. As a result, we overspecialized and overspecified: we needed MLS, but got C2 and hi/low guards. DoD was caught off guard by pervasive networking, desktop advances, etc. The needs today are the same as before: MLS controls wherever there's data.
Marv Schaefer (Arca systems) talked about the changes in our computing environment. Systems went from monolithic computing to distributed, from configuration management to self-installing, self-extracting programs (10 years ago, we didnt have programs that installed themselves and unknown other software when you insert a CD into your PC), from professional system administrators to user self-administration (who are less skilled and less interested in security), from Trojan horses to applets and macros as the threats, and from skilled penetrators to hackers (who are less skilled, but better tools). The needs havent changed though: we need a "sound balance of technologies and assurances: not a band-aid, never a tourniquet".
Jim Anderson (independent consultant) noted that "the traditional Bell LaPadula MLS model was right, it still is, and it met all its objectives". What went wrong is that the PC revolution caused evaluations to take longer than product cycles, the Government market didn't materialize, so vendors stopped investing, NSA didn't practice what it preached (no worked examples, no showcases, and demos were unrealistic), we ignored networks until it was too late, and we didnt pay attention to running COTS software at workstations. His chief point is that we havent learned our lessons. Instead, we substituted "crypto is the answer, what was the question?", and substituted guards which are fundamentally wrong. The net result is that we lost capability: there are very few capable of doing MLS work any more. The INFOSEC community is proceeding as if MLS is a solved problem, but it's not. What we should do is build MLS products that run arbitrary COTS at workstation. The government will have to pay for MLS products, as no vendor would build on speculation after the government history of not purchasing the last generation of MLS products.
Session 2: MLS Present
Summary: People are using guards, and (IMHO) ignoring assurance.
Col Joe Sheldon (NSA, Chair) summarized the currently available guard solutions available including the C2 Guard, Ops/Intel workstation, N-level workstation, SNS Standard Mail Guard, ISSE Guard, Radiant Mercury, and MLS networks using SCO CMWs. Man-in-the-loop downgrade is common. The strategy for making COTS applications work on CMWs is to give them all the privileges, then remove them one at a time until the application breaks, and decide whether you can live with the risk of assigning the required privileges. (IMHO, this is a truly amazing approach to security.) NSA is working on building a version of the C2G that will pass MS Office documents from high to low. (It absolutely floored me that anyone would consider such a thing, given the amount of data hidden (i.e., object reuse problems) in MS Office files.) Auditing is a problem for all of the guards: too much data, too hard to analyze.
According to Col Sheldon, there are 539 MLS connections (e.g., Unclassified to Secret) fielded throughout DoD today! Theyre revisiting each of the accreditations now, and anything that isn't re-approved must be turned off in September. They have major data classification cascading problems, which aren't being addressed. He concluded by noting that technology isn't a panacea but procedures can help, and the guard product aren't perfect, but they're a solution.
Joe Alexander (Sun) noted that DoD isn't buying Trusted Solaris (which is one of the few commercial MLS products), but that other countries are, including UK, Canada, South Africa, Japan, Singapore, Poland, and Czechoslovakia. He noted with scorn that Australia has been buying Trusted Solaris, but decided NT was good enough. NCSC evaluations are important, but the ease of getting waivers make them irrelevant. At Sun, they have enough resources to evaluate OR develop new versions of the MLS product, but not enough sales to justify both, so they focus on building products and skip the evaluations. He concluded by noting that the "Internet is our greatest friend", because its scaring people into buying security.
Capt Dan Galik (SPAWAR) described the IT21 program (Information Technology for 21st Century) which is putting PowerPoint and similar stuff on every desktop. He said that Microsoft told DoD they don't see any business case for MLS, so we shouldnt expect anything in that area (DoD is less than 1% of Microsofts business, so even if DoD used MLS exclusively, it wouldnt be enough for Microsoft to spend their effort on it). As a result, IT21 is using multiple single level networks rather than MLS. In places where MLS is truly necessary, they are using a bunch of CMWs and some guards.
Erika Langerman (Joint Staff) is using SNS with SMART (Standard Mail Attachment Review Tool) to send email across levels. Theyre now sending 1500-2000 pieces of email per day from high to low, half of which have attachments. For moving data up, theyre still using sneakernet. Since theyre not doing MLS at the desktop, so everything is system high. Theyre also using "Cybershield" (which is the equivalent of the B2-targeted Dockmaster 2) to allow Top Secret users to go web surfing.
Louanna Notargiacomo (Trusted Computer Systems) described the Ops/Intel workstation, which is built on B1/CMW-like products from Sun & DEC. There are over 100 Ops/Intel systems fielded and accredited by DIA. For $3500, TCS will offer a Sun Ultra 5 that runs MS Office apps at multiple levels simultaneously. They also provide a MLS web server, and Trusted Oracle as the MLS DBMS. The SSL Proxy Gateway includes HTTP request filtering based on a dirty word search, and can also filter out executable content. The bottom line is that people just want to interconnect, so they do it without understanding the risks.
John Pescatore (TIS) got a good laugh with the comment that "any vendor who can't develop a product faster than government evaluates it is either (a) out of business or (b) a government contractor". He also commented that system high model is easier than MLS for all the standard reasons: competition vs. single vendor lock-in, understandable vs. hidden costs, expensive vs. really expensive, etc.
Lunchtime Session: User/Applications Level Security Services Framework
Todd Inskeep (NSA) described the framework, noting that it took the challenge from presidential commission to improve assurance. Their goal is to provide quick directions, and long term buyin. They want to rely on information security solutions from industry. The framework has three pieces: security services API, generic applications, and custom applications. The security services API includes security & crypto features for security aware applications (e.g., CDS, Microsoft crypto API). The generic applications layer includes high assurance email with DMS, file encryption, databases, collaboration. (No explanation of how to justify the claim of "high assurance".) And the custom applications layer relies on using CORBA or DCE. They also want to address remote access. The framework draft (available on the web page) has been provided to big vendors (e.g., Oracle, Microsoft) for comments. A follow-up workshop on April 16 & 17 will review industry comments on the framework, with final release in June.
Session 3: MLS Futures
Summary: No one has any good answers for how to do things better.
Bill Neugent (MITRE) gave a very entertaining speech, with nuggets like: "If you like the features, who cares about assurance; if you don't like the features, who cares about assurance?" and "MLS: A good idea carried too far, or a bad idea carried too far?". He noted that NT 5.0 has 26 million lines of code, with an average of 20% replaced every year (we don't need no stinkin' minimal TCB!). Bill suggested that guards don't necessarily need high assurance operating systems for bases, as the security is at the applications level. He noted that we hear what the CINCs need, but not what we need for infrastructure protection. Buying MLS workstations isnt a solution, as they typically get put in the corner to gather dust. MLS protection needs intrusion detection systems that look at MLS-specific attacks, and shut off connections in case of attack. He suggested getting luminaries like Cheswick & Bellovin to look at how guards work and making suggestions for improvements.
Bill suggested some things we need to improve security, including tools that look for backdoors around guards and for illegal traffic, and low-side "detonation chambers" to try running attachments before sending them along to high systems. There should be many fewer interconnection points: not the 539 talked about by Joe Sheldon. Switched workstations are a great choice. We need to avoid overconfidence and stupidity (which is difficult, since we're not sure what it is that constitutes stupidity). He concluded by noting that we have to find solutions: "winning the war trumps saving the systems, unless losing the systems means losing the war".
Carl Landwehr (NRL) talked about a three simple technologies that can be used in place of building MLS systems: the NRL Pump sends information reliably from low to high; the Australian-developed Starlight provides safe MLS windowing; and onion routing provides anonymous web browsing. We still need a downgrader, but given these tools there should be far less to downgrade. What we really need is more good ideas like these, rather than guards and similar devices.
George Schou (Oracle) talked about the increasing concerns about security in the commercial world. The commercial world is mainly interested in electronic commerce. He mentioned an NIH project (PCASSO, thePatient Centered Access to Secure Systems Online) which is the first civilian use of MLS.
Doug Schultz (USACOM) talked about the MLS hexagon: labelling standards, Doug Schultz (USACOM) talked about the MLS hexagon: labelling standards, software for release, electronic tagging, personal authentication, MLS workstations, and MLS security. I didn't understand the point of his talk or what it *really* has to do with MLS.
Charlie Testa (Infosystems Technology) described Trusted Rubix, which is a DBMS hosted on a B3 operating system (XTS-300). It can be used to bridge Secret & SCI, with appropriate information flow enforced. Charlie claimed it can be used as a guard, although he didnt explain how its a guard. ITI recently submitted RUBIX for NSA evaluation as a TNI/TDI "M" layered component on top of a Wang XTS-300. (IMHO, this is the same old MLS DBMS that no one wanted before, and I dont know why anyone would want it now.)
Last Session: Q&A/Wrapup [Nothing reported]