COUNTERING OBSOLESCENCE VIA HIGH ASSURANCE

Jess Irwin, Raytheon CompanySenior Manager Systems Engineering - Secure Processing

W. Mark Vanfleet, National Security AgencyGlobal Network Vulnerability Analyst

System Life Total Cost of Ownership• Implementation• Certification / Accreditation• Deployment• Operations, Maintenance, and Administration• Technology Refresh

• Growing Attack Surface over time• Obsolescence Events

2

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

3

Public Law 111-23Weapon 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…(1) measures to ensure competition, or the option of competition; and(2) 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.

4

5

CONFIDENTIALITYo Critical Data PROTECTED

INTEGRITYo Free of Unauthorized Manipulation

AUTHENTICATIONo Identity Confirmed

AUTHORIZATIONo Privilege Confirmedo Mutual Suspicion

(Reduced access based on authentication uncertainty) NON-REPUDIATION

o Proof of Data Origin & Delivery AVAILABILITY

o Critical functions READY SAFETY

o Determinismo Reliabilityo Independence

DETERRENCEo Undesirable Consequenceso Strength of Mechanism

PREVENTIONo Defense in Deptho Obfuscation

DETECTIONo Visual, Alarm, Loss of Function, Attestationo Monitoring

RESPONSEo Destruction, Disabling, Zeroizationo Adaption

DESIGNATE KEY INTERFACESo Based on speed of volatility, criticality, and the high cost of change over extended period of time MODULARITY & VISIABILITYo Design for change and affordable technology refresheso Minimize attack surfaceo Design for recovery and adaptation against Zero-day Defects

RE-USEABLE COMPONENTSo Commercial based standards (POSIX, Open GL) - unmodifiedo Published standards (IEEE 1394, 802.11) - unmodifiedo Established proprietary standards (USB, Blue Ray) - unmodified

INTEROPERABILITY & SECURITY (CJCSI 6212.01E)o Global Network Information Enterprise Architectureo Support for Distributed degree of trust systems

ENABLING ENVIRONMENTSo Infrastructure and Enterprise API’s Separableo Decouple data producers and consumers (cloud computing)o Register data grams and data streams within metadata registry

Survivability

IAInformationAssurance

OAOpen

Architecture

ATAnti-

Tamper

PIT

Observe

Decide

Act Orient

6

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.

7

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.

8

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

9 9

Detecting Defects10

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: 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

• MILS: an emerging RTOS and system architecture based on partitioning

• Common Criteria security evaluation methodology

Approach

12

ApplicationorMiddleware(U)

ApplicationorMiddleware(C)

ApplicationorMiddleware(S)

ApplicationorMiddleware(TS)

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

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 development and certification

• Reduce security-critical code• Therefore increase scrutiny of

security-critical codethrough “Divide and Conquer”

• Separation• Composition• Layered assurance

SupervisorM

odeU

ser Mode Partitions

Split app reduces cost of development, cert, operation

Appor MW1

U

App2a

S

Separation Kernel (SK)

Trusted Hardware

TrustedNetworkDriverTS

HA RuntimeGuest OS Guest OS HA Runtime

HA Runtime: High Assurance EAL6+ SK interfaceGuest OS: Traditional RTOS, Linux, Windows

App 2bTS/SDown-grader

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

14

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

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

SupervisorM

odeU

ser Mode Partitions

Split app reduces cost of development, cert, operation

Separation Kernel (SK)

Trusted Hardware

TrustedNetworkDriverTS

HA Runtime HA Runtime

HA Runtime: High Assurance EAL6+ SK interfaceGuest OS: Traditional RTOS, Linux, Windows

Appor MW1

U

Guest OS Guest OS

App 2bTS/SDown-grader

App2a

S

16

17

Separation Kernel (SK)

Trusted Hardware

TrustedNetworkDriverTS

HA Runtime HA Runtime

Layered Assurance is NEAT

• Assurance of a component builds on the assurance of any components it uses

• Assurance is NEAT:• N on-bypassable• E valuatable• A lways-invoked• T amper-proof

• Goal: reusable commercial certified components assembled into a certified system

MILS enables the system architectureto be aligned with the assurance case

Appor MW1

U

Guest OS Guest OS

App 2bTS/SDown-grader

App2a

S

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.

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.