Countering Obsolescence via High Assurance

1. Countering Obsolescence via High Assurance Jess Irwin, Raytheon Company Senior Manager Systems Engineering - Secure Processing W. Mark Vanfleet, National Security Agency Global Network Vulnerability Analyst

2. System Life Total Cost of Ownership • Implementation • Certification / Accreditation • Deployment • Operations, Maintenance, and Administration • Technology Refresh • Growing Attack Surface over time • Obsolescence Events

3. 3 Obsolescence Issues • Moore’s Law • GOTS vs. COTS • Sole Source vs. Multi-source • Supported (Licensed) vs. Communal (Unlicensed) • Security vs. Functionality • Customization vs. Mainstream • Tight Control vs. Monolithic Control • Easy to Lock Down, Niche Market, Small Vendor • Hard to Lock Down, Excessive Functionality, Large Vendor/Prime • Made in the USA vs. Made in China, Russia, Japan, et.al. • Growing Attack Surface over time

4. Public Law 111-23 Weapon Systems Acquisition Reform Act of 2009 • SEC. 202. ACQUISITION STRATEGIES TO ENSURE COMPETITION THROUGHOUT THE LIFECYCLE OF MAJOR DEFENSE ACQUISITION PROGRAMS. • (a) ACQUISITION STRATEGIES TO ENSURE COMPETITION… • measures to ensure competition, or the option of competition; and • adequate documentation of the rationale for the selection… • (b) MEASURES TO ENSURE COMPETITION…: • Competitive prototyping. Dual-sourcing. Unbundling of contracts. • Funding of next-generation prototype systems or subsystems. • Use of modular, open architectures to enable competition for upgrades. • Use of build-to-print approaches to enable production through • multiple sources. • Acquisition of complete technical data packages. • Periodic competitions for subsystem upgrades. • Licensing of additional suppliers. • Periodic system or program reviews to address long term competitive • effects of program decisions.

5. 5

6. 6 Survivability • DESIGNATE KEY INTERFACES • Based on speed of volatility, criticality, • and the high cost of change over extended period of time • MODULARITY & VISIABILITY • Design for change and affordable technology refreshes • Minimize attack surface • Design for recovery and adaptation against Zero-day Defects • RE-USEABLE COMPONENTS • Commercial based standards (POSIX, Open GL) - unmodified • Published standards (IEEE 1394, 802.11) - unmodified • Established proprietary standards (USB, Blue Ray) - unmodified • INTEROPERABILITY & SECURITY (CJCSI 6212.01E) • Global Network Information Enterprise Architecture • Support for Distributed degree of trust systems • ENABLING ENVIRONMENTS • Infrastructure and Enterprise API’s Separable • Decouple data producers and consumers (cloud computing) • Register data grams and data streams within metadata registry Observe Act Orient • CONFIDENTIALITY • Critical Data PROTECTED • INTEGRITY • Free of Unauthorized Manipulation • AUTHENTICATION • Identity Confirmed • AUTHORIZATION • Privilege Confirmed • Mutual Suspicion (Reduced access based on authentication uncertainty) • NON-REPUDIATION • Proof of Data Origin & Delivery • AVAILABILITY • Critical functions READY • SAFETY • Determinism • Reliability • Independence Decide OA Open Architecture • DETERRENCE • Undesirable Consequences • Strength of Mechanism • PREVENTION • Defense in Depth • Obfuscation • DETECTION • Visual, Alarm, Loss of Function, Attestation • Monitoring • RESPONSE • Destruction, Disabling, Zeroization • Adaption IA Information Assurance PIT AT Anti- Tamper

7. Cross Domain Solutions as an ExampleNetwork Centric Operations and Global Information Grid Interoperability required the connection of disparate Domains of Information. This interface emphasizes the requirement for standards based Open Architecture to enforce to protect privacy, proprietary rights, digital rights and to mitigate the risk of exposure of sensitive information whether it be commercially or government owned. The proper use of a Cross Domain Guard should be as an Information Flow Reference Monitor, mitigating the difficulties caused by disparate Security Classification Guidelines associated with the separate domains in question. Their purpose should not be to change the inherent sensitivity of the information, but to adjust that sensitivity based upon the context of the new domain. A Cross Domain Solution that filters information in an attempt to reduce its sensitivity does not fully mitigate the risk resulting from relating associated artifacts that can recover and in many cases emphasizes the attempt. Unfortunately as many systems have merged information of multiple levels of security into a system high environment, and as the volume of information flow has increased, we are seeing an increasing number of proposals to redact information through the inappropriate use of Cross Domain Solutions. This problem is eliminated when information is properly and immediately associated with its security and privacy credentials at creation in a manner that is incorruptible and imitation resistant in accordance with existing standards that are recognized as part of the Open Architecture.

8. Software Reliability as an Example The increasing complexity and size of software programs contribute to the growth in software flaws. For example, Microsoft Windows XP reportedly contains about 40 million lines of code, compared with about 16 million lines for Windows NT (V4.0). As reported by the National Institute of Standards and Technology (NIST), based on various studies of code inspections, most estimates suggest that there are as many as 20 flaws per thousand lines of software code. While most flaws do not create security vulnerabilities, the potential for these errors reflects the difficulty and complexity involved in delivering trustworthy code. As soon as vulnerabilities are discovered, attackers concentrate on attempting to exploit them almost immediately. This prompt exploitation sometimes includes such things as setting up Web sites to take control of entire systems enabling the hacker to read, modify, or delete information on victim systems; disrupt operations with viruses and worms,149 or launch any of many other forms of attack against systems. Attacks can be launched against distributed systems through viruses and worms. These are the basic reasons for installing patches promptly.

9. 9 Open Architecture Separation Goals • Isolate architectural components that evolve at different rates • Abstraction Layers isolate S/W (evolves slowly) from H/W (Moore’s Law) • Open interfaces that conform to business objectives • Open interfaces around enablers, support insertion of 3rd party enablers • Use canonical modularity of the system • Most mature domains already have well defined H/W and S/W boundaries, need to be opened • Architect for Composability, Separation, Reuse (multiple instatiation), Refresh • OA and IA both manage complexity • Real Time Operating Systems (RTOS) must be COTS and unmodified • Hands Off the internals – allows non-disruptive H/W and peripheral upgrades • Separate Infrastructure from Mission • Infrastructure enables composability and compositionality • Separation and Composition is the only game in town for managing complexity • A good architecture simplifies the assurance case

10. Detecting Defects • Most software applications are at least 1 million lines of code in size • XP has 40 million lines • RHEL5 has 30 million lines • Not feasible to evaluate the assurance of source code to reveal any malicious intent • Number of lines of source code increase: • Complexity increases • Misuse of the principle of least privilege increases • On monolithic systems number of lines of source code that can be reviewed per year decreases • Open Architecture is about making decisions now so that when major technology refreshes occur that security will not decrease and cost to maintain will not increase

11. MILS: an emerging RTOS and system architecture based on partitioning • Common Criteria security evaluation methodology Approach MILS: Multiple Independent Levels of Security • A multi-level secure (MLS) system running multiple software components in a strictly controlled manner • Lower-cost evaluationto show security and safety with high assurance Goal

12. MILS: Multiple Independent Levels of Security A multi-level secure system based on MILS can: Host multiple applications on one processor Top Secret, TS/SCI, Secret, Unclassified, … Multiple coalition partners Other types of domains Strictly control all resources and all component interactions Have user software components certified at different levels Be certified as a system at the required level ApplicationorMiddleware(S) ApplicationorMiddleware(U) ApplicationorMiddleware(C) ApplicationorMiddleware(TS) 12

13. MILS Architecture Architecture with three layers Trusted hardware Separation kernel (SK) in supervisor mode User components (applications, middleware, drivers) in user mode Enable independent developmentand certification Reduce security-critical code Therefore increase scrutiny of security-critical code through “Divide and Conquer” Separation Composition Layered assurance Split app reduces cost of development, cert, operation Appor MW 1 U User Mode Partitions App2a S TrustedNetworkDriver TS App 2b TS/SDown-grader Guest OS Guest OS HA Runtime HA Runtime SupervisorMode Separation Kernel (SK) Trusted Hardware HA Runtime: High Assurance EAL6+ SK interface Guest OS: Traditional RTOS, Linux, Windows

14. 14 MILS Architecture – Trusted Hardware • No exploits or covert channels • Or any known covert channels can be avoided or are low relative bandwidth • Widely used commercial hardware • For high assurance, must support “secure boot” • Ensure the code that is booted is the code that was evaluated and certified • Intel processors with Trusted Execution Technology (TXT) • Others: FPGA or other assist on the board Trusted Hardware

15. MILS Architecture – Separation Kernel • Small code size for high assurance evaluation • ~5,000 SLOC • Supervisor mode • Implements only four functions • Data isolation(space partitioning) • Periods processing(time partitioning) • Information flow control • Fault isolation Separation Kernel (SK) Trusted Hardware

16. Split app reduces cost of development, cert, operation 16 MILS Architecture – User Components • Three types of user components run in user-mode partitions: • Applications, middleware, drivers • Drivers usually in user partitions • Any supervisor-mode drivers must be in separate memory spaces, be evaluated, not invalidate SK cert • Any component type can beat any assurance level • User components run on either: • High assurance EAL6+ “minimal runtime” interface to the SK • Guest OS: traditional RTOS, Linux, Windows Appor MW 1 U User Mode Partitions App2a S TrustedNetworkDriver TS App 2b TS/SDown-grader Guest OS Guest OS HA Runtime HA Runtime SupervisorMode Separation Kernel (SK) Trusted Hardware HA Runtime: High Assurance EAL6+ SK interface Guest OS: Traditional RTOS, Linux, Windows

17. Layered Assurance is NEAT • Assurance of a component builds on the assurance of any components it uses • Assurance is NEAT: • Non-bypassable • Evaluatable • Always-invoked • Tamper-proof • Goal: reusable commercial certified components assembled into a certified system Appor MW 1 U App2a S TrustedNetworkDriver TS App 2b TS/SDown-grader Guest OS Guest OS HA Runtime HA Runtime Separation Kernel (SK) Trusted Hardware MILS enables the system architectureto be aligned with the assurance case

18. Architecture Properties • Architecture properties describe critical aspects of a systems architecture with regard to information assurance • These properties are based on the results of other work in the MILS research community • These properties directly support the establishment of the Application properties • Information Flow • The set of communications flows in systems that are authorized to permit communications between system partitions. These flows are the only flows that are allowed to cross partition boundaries. • Least Privilege • This property requires that in a particular abstraction layer of a computing environment every module (such as a process, a user or a program on the basis of the layer we are considering) must be able to access only such information and resources that are necessary to its legitimate purpose. • Damage Isolation • The consequences of an error or security breach are limited by specified partition boundaries and data protection mechanisms. • Data Isolation • The architecture provides partitioning such that there are no data dependencies that cross partition boundaries.

19. Infrastructure Properties • Infrastructure properties describe the IA capabilities of critical infrastructure components • Separation Kernels, IPC mechanisms, Filters • Properties at this level of decomposition are amenable to formal proofs • Can also incorporate component level certification results (such as Common Criteria) • Type Safety • Inputs are validated before being accepted into critical components. • Infiltration • Processing does not depend on information that should not affect it. • Processing must not be affected by state in other partitions. • Mediation • The effect of a subject's execution depends only on resources with which it is allowed to interact . • Exfiltration • Processing cannot influence data/flows other than the ones specified in the communications policy • The act of executing an object cannot affect the state of other objects out side the communications policy.