cisr high assurance research program · 2017-04-29 · cisr high assurance research program january...
TRANSCRIPT
Calhoun: The NPS Institutional Archive
Faculty and Researcher Publications Faculty and Researcher Publications Collection
2005-01-24
CISR High Assurance Research Program
Irvine, Cynthia
http://hdl.handle.net/10945/49156
CISR High Assurance Research Program
January 2005 Cynthia Irvine
Naval Postgraduate School
January 2006 2
NPS Team
• Faculty and Staff – Cynthia Irvine, Thuy Nguyen, Timothy Levin, Paul Clark, John
Clark, Richard Harkins, Jean Khosalim, Donna Miller, David Shifflett, Buddy Vernon, Daniel Warren, Naomi Falby, Matthew Rose, Mike Thompson, Phil Hopfner
• Current Students – Jeremy Bradney (civ), Jason Cullum (civ), Melissa Egan (civ), Mark
Estlund (USAF), Patrick Whitehorn (civ), Mark Orwat (USA), Randy Avray (USA), Alan Schaffer (USN), Mike Schumann (USMC), Daniel DeCloss (civ),
• Graduated Students (recent) – Major Francis Afinidad (USAF), Major David Bibighaus (USAF),
Catherine Dodge (civ), John Horn (civ), Rob Kane (USN), Jack Lysinger (USN), Carrie Ruppar (civ), Chua Chay (Sing. Army), Ng, Chee Mung (Sing. Civ), Tan, Nai Kwan (Sing. Civ), Lily Tse (civ) …
January 2006 3
Agenda
• Synergistic Research Projects – Multilevel Testbed and CDS – Trusted Computing Exemplar – Protection Profile Development – SecureCore – RCSec
• CyberCIEGE
Trusted Computing Exemplar Project
January 2006 5
Trusted Computing Exemplar
• Technical Problem Definition • Social Problem • TCX Concept • High Assurance Kernel • High Assurance Development Framework • Exemplar High Assurance Application • Project Evaluation and Dissemination
January 2006 6
General Taxonomy of Attacks
Attack Motive Attack Strategy
Attack Resources Threat Assurance
Required
Political-Military
Long-Term Planning Well Funded System
Subversion Highest
Political-Military
Mid-Term Planning
Modest to High Funds Trojan Horse High
Malicious Amusement
Short-Term Planning Low to Modest Flaw
Exploitation Moderate
Malicious Amusement Ad Hoc Low Interface
Exploitation Low
January 2006 7
Attacks: Means, Motive, Opportunity
• Means – Skill in system design and artifice construction
• Motive – Clandestine access to critical information
• Opportunity – Join development team for target system – Modify system design, specifications, or code – Insert artifice during distribution, configuration,
or maintenance
January 2006 8
Address Subversion - Limit Opportunity
• Need lifecycle assurance – High assurance – Protection via rigorous security engineering
• No unspecified functionality • Use of formal verification techniques
– When Applied in MLS Context: • Bound information flow
– Prevents Trojan Horse damage
• Uses formal models – Supports implementation assessment
January 2006 9
National Capability Atrophied
• Few can construct high assurance systems – Evaluated high assurance secure systems not
built in past two decades • People dispersed • Systems proprietary
• Few teams to evaluate systems • Universities do not know high assurance methods
– Vicious cycle - no input for teams • Solution: a high assurance exemplar
– NPS has experience and critical mass
January 2006 10
TCX Integrated Activities
• Rapid High Assurance Development Framework – Configuration Management, Engineering Process, … – Semantic programming-based documentation system
• Develop High Assurance Security Concepts – Separation Kernel - EAL7
• Many student research projects – High Assurance Application
• Authentication Device for MLS Trusted Path
• Evaluate Components for High Assurance – Developing EAL6+ Separation Kernel Protection Profile
• ST will be EAL7
• Disseminate Results via Open Methodology
January 2006 11
• Define and leverage assurance- and policy-driven processes
• Focus on efficiency and repeatability – Integrate Tools Specific for High Assurance
• Configuration management • Specification and coding • Teamwork and training support
– Mentored teams • Transfer of high assurance capabilities
– Integrate open methodology for dissemination
Activity 1: HA Development Framework
January 2006 12
Support Development Functions
• Specification of security properties • Design specification • Verification that security properties are self-
consistent • Code development • Verify that implementation meets its target (& no
more) • CM of specifications, SW, tools and processes • Specification-based testing • Evaluation support through document structuring • Teamwork and training support • User document support
January 2006 13
Current Status - Life Cycle Con
figur
atio
n M
anag
emen
t Pl
an
Dev
elop
men
t Sta
ndar
ds
…
Adm
inis
trat
ive
Sec
urity
Pla
n
Phys
ical
Sec
urity
Pla
n
Lifecycle Management Plan
ConceiveDesign
BuildModify
and Maintain
Retire
Documentation required for all aspects
of lifecycle
January 2006 14
High Assurance Life Cycle Framework
• Spiral Life Cycle Model – Augmented With EAL7 Life Cycle Requirements
• Rigorous Configuration Management (CM) – Track Changes, Only Authorized Changes Accepted – Ensure Integrity Of Configuration Items
• Strict Developmental Security Safeguards – Ensure Confidentiality & Integrity Of TCX Materials
• Current Status – Life Cycle Plan – Personnel Security Plan, Physical Security Plan – CM Plan, CM Procedures – Physically Isolated CM System, Perforce CM Software
January 2006 15
HA Rapid Development Environment
• Evaluation-Driven Processes – Focus on Efficiency and Repeatability
• Tools Specific for High Assurance – Automated Documentation Referencing System
• Facilitate Traceability and Correspondence Between Spec & Code – Software Development Environment
• Processes for Design, Review, Approval, Development – Verification Environment
• Verify Correctness of Formal Model and Specifications • Current Status
– Documentation Development Standards – XML-Centric Documentation Integration Environment Prototype – Software Development Standards – Protected Development Network Prototype – Verification Tool Sets (FDM, PVS, ACL2, Specware, Spark ADA,
etc.)
January 2006 16
• Security Policy and Formal Model – Model mapped to policy – Model consistency proof – Model captures salient system abstractions
• Formal High Level Specification – Formally mapped to model – Basis for Test Plan
• Demonstrate presence and absence of functionality • Implementation
– mapped to FHLS • Covert channel analysis • Lifecycle configuration management
Apply Developmental High Assurance
January 2006 17
• Configuration Management System – Detailed Design & Implementation
Procedures – Initial Baselines for all Configuration Items
• High Assurance Development Environment Plan – Development Tools – Programming Language Survey
• Hardware Platform Survey and Analysis • Hardware Specific Development Tools Under
CM
Status: Configuration Management
January 2006 18
• Embedded Separation-Kernel • Network Trusted Path Extension Appliance
• High Assurance applied for entire lifecycle – Design, implementation, distribution,
maintenance – Evaluatable processes
Activity 2: Develop HA Components
January 2006 19
TCX Separation Kernel
• Simple, Compact, Structured to be Evaluatable at EAL7 – Static Security and Resource Configuration
• Flow Control – Process and Data-Domain Separation
• Access Control Policy – Static Process/Resource Access Bindings
• Basic Kernel Services – Static Scheduling – IPC via Shared Memory Segments and Simple Synchronization
Primitives – Device Interrupts Handling
• Current Status – Threats and Security Requirements Analysis
• Working with NSA to Develop EAL6+ Protection Profile – Least Privilege Separation Model
• Demonstrated using Formal Development Methodology Tool Set
January 2006 20
Separation Kernel
• Static resource allocation reduces “covert channels” – Fixed number of processes and subjects – Fixed subject/resource bindings
• Results in global and persistent policy enforcement
– Fixed scheduling allotments per block • Entities within block share allotment
– Kernel mechanisms to handle asynchronous interrupts • I/O handled by kernel • Presented to processes via memory segments
– IPC via shared memory segments • Simple synchronization primitives
January 2006 21
• Access Control Policy – Static runtime process/resource binding
• in equivalence classes or blocks – Enforce process and inter-block separation – Can support lattice-based domain policies – Inherent support for least privilege: LPSK
• Verification Properties – Process Isolation
• controlled communications – Covert Channel
• Simplified by static resource allocation
Separation Kernel - continued
January 2006 22
Status- Requirements Specification
• TCX Kernel Security Target – Based on SKPP – Preliminary draft created – Will include EAL 7 requirements
• Some Common Criteria requirements extend high assurance security engineering
• NPS providing interpretations for review
January 2006 23
• Model Application • TPE functions
– Gatekeeper between workstation and LAN • High assurance separation via TCX separation kernel • Isolate untrusted workstation until session established
– High assurance mutual authentication • Remote Multilevel Secure (MLS) Server
– Login and Session Level negotiation • Configured Commercial (COTS) Client Workstation
– MLS Session-level negotiation, encryption, etc. • Software Structure
– Layered component built on top of LPSK • Hardware
– Appliance form factor (handheld scale) • User input and display devices
Trusted Path Extension
January 2006 24
• Application (layer 2) – move packets between LAN and workstation
• Trusted Path Policy (layer 1) – Manage I/O between remote TCB and user
• Login • Session-level negotiation
– Ensure workstation isolation until session established – Ensure workstation isolated from Trusted path dialogs – Secure communication tunnel
• Separation-Kernel (isolation policy) configuration – ensure packet mediation between LAN and workstation
TPE Layered Design
January 2006 25
• EA6+ Separation Kernel protection profile – Common Criteria model and guidelines – Working with NSA team – Contribute comments to CC evolution
• Basis for EAL7 Security Target – Objective to be compliant to EAL6+ SKPP
• Basis for third-party evaluation • Basis for subsequent layer 1 and layer 2
evaluations at EAL6
Activity 3: High Assurance Evaluation
January 2006 26
• Provide how-to examples for high assurance – Previously unavailable – Document HA development framework,
techniques, social model – Distribute in open web-based format
• Security Target and other requirements documents • Source code, development framework, plans, etc. • Evaluation evidence and reports, including
– Formal model – Formal Specification – Covert channel analysis
Activity 4: Disseminate via Open Methodology
January 2006 27
Dissemination System Overview
Local CA
Dissemination Environment
Dissemination System
Local Web Server
Fire
wal
l and
Sec
urity
Dom
ain
Releasing Agent
User Database Export
Data Export
Data Export
Labeled Document
Releasable Items List (RIL)
Policy Database
Project Manager
Generate RIL
Configuration Management
3 4
1
2
87
5
6
Legend: Data/Database: Process/Activity:
DS Certificate
Local CALocal CA
Dissemination Environment
Dissemination System
Dissemination System
Local Web Server
Local Web Server
Fire
wal
l and
Sec
urity
Dom
ain
Releasing Agent
Releasing Agent
User Database Export
Data Export
Data Export
Labeled DocumentLabeled Document
Releasable Items List (RIL)
Releasable Items List (RIL)
Policy DatabasePolicy Database
Project ManagerProject
Manager
Generate RIL
Configuration Management
Configuration Management
3 4
1
2
87
5
6
Legend: Data/Database: Process/Activity:
DS Certificate
January 2006 28
Requirements Derivation Process
Phase ISystem
Description
Phase IIObjectives
Phase IIIRequirements
Ideas
ConcreteDescription
FormalRequirements
InformalRequirements
Objectives
SecurityEnvironment
Assumptions PoliciesThreats
January 2006 29
Dissemination System Status
• System-level requirements defined • Under development
– Dissemination System detailed requirements – Policies and procedures – Manual dissemination system
January 2006 30
• Evaluatable Reference Implementation • Components with a priori Assurance Against
System Subversion • Public Availability of High Assurance
Development Framework • Transfer to Next Generation
– New Experts in Security Development – High Assurance Knowledge and Capabilities
TCX Benefits
Protection Profile Development
January 2006 32
Separation Kernel Protection Profile
• Separation kernels in DoD programs – JTRS, JSF, etc.
• NPS – Needs for Protection Profile for TCX – Provides objective support for PP development
• SKPP initial draft July 2004 • Final draft in progress
– Compliant with Common Criteria Version 2.2
January 2006 33
Benefits of SKPP Effort
• Better understanding of CC Methodology • Contribute to future version of CC
– Explicit high assurance requirements that should be in CC
• Development of methodology for informally specified systems
• Basis for TCX Security Target • Participation in definition of assurance
requirements for future systems
January 2006 34
Project Description
• DoN needs shared printing capability in multilevel environment • Establish security requirements for dedicated multilevel print server
(MPS) – Utilize Separation Kernel technology – Support HP PCL 5 printer protocol
• MPS must be certifiable and accreditable – Meet DoDD 8500.1 and DoDI 8600.2 requirements
• Use Common Criteria (CC) framework – CC Version 2.2 – Initial goal: Draft Protection Profile (PP) – Draft PP as basis for development of formal PP or Security Target – Evaluation Assurance Level: EAL4 with augmentation
• Methodically designed, tested and reviewed
January 2006 35
Accomplishments
• Phase 1 – Draft PP as Masters Thesis
• December 2004 à June 2005 • Extensions to several Common Criteria requirements • Extrapolation from existing guidance and examples
– US Medium Robustness Consistency Instruction Manual – Medium Robustness MLS OS PP
• Phase 2 – Common Criteria Version 3.0 – Translation process started November 2005
January 2006 36
System Overview
Dedicated Printer Networked Printer
Unclassified Confidential Secret Top Secret
Security Environment
System High
January 2006 37
System Characteristics
• MLS Print Server – Handle print jobs of different sensitivity levels – Physically isolated and protected – Act as a proxy, transparent to users
• Single-level client systems – Sensitivity levels determined by attached network interface
• Printers – Located on system high network, physically protected – Two configurations: dedicated, networked
• Print jobs – Preloaded delimiter pages reflect sensitivity level of sender – Use of delimiter pages differs for each printer configuration – Manual sorting by trusted administrative users
January 2006 38
Unencapsulated Print Job
Delimiter Pages
Dedicated Printer
Separator Page
Printed Orientation
First Page Printed
Last Page Printed
Networked Printer
Separation Page
Unencapsulated Print Job
Separator Page
Encapsulated Print Job
Printed Orientation
First Page Printed
Last Page Printed
Separation Pages identify jobs received from single-level clients
January 2006 39
Security Functionality
• Mandatory Access Control (MAC) – Control the use of system resources based on DoD data sensitivity
classification model • Administrative Access Control (AAC)
– Restrict access to objects based on user’s administrative role bound to a subject
• Identification and Authentication (I&A) – Uniquely identify and authenticate administrative users before
allowing access to system resources • Trusted Path
– Provide administrative users direct link to the I&A functions for AAC enforcement
• Audit – Allow security administrators to detect and analyze potential
security violations.
January 2006 40
Target of Evaluation (TOE)
• Trusted base – Hardware, Separation Kernel
• Trusted partitions (TSF) – Runtime
• MLS Services • System High Services
– Initialization • Single-level partitions
– Print spoolers, one per input port
January 2006 41
TOE Components
System Services
Job Queues
Top Secret Spooler
System Services
Input/ Output Buffer
TSF Boundary
Hardware
Separation Kernel
Input/ Output Buffer
Job Queues
Secret Spooler
Initialization
System Services
System Services
TCP/ IP
Stack M
alicious PJL Filter
AA
C Services
Configuration Tools
Runtim
e Tools
Audit Logger
Label Partition
Label
Delimiter Page
Handlers
MLS Services
Process within a Partition
Label = Logical Function
MPS Config.
Data
S.K. Config.
Data System Services
System Services
System Services
System Services
Trusted Security Functions (TSF)
January 2006 42
Multilevel Components
• Separation Kernel – Enforce information flows control policy between partitions – Enforce MAC policy via its configuration data – Configuration data determine static runtime behavior
• All resource allocations • All allowed information flows • Sensitivity level of partitions • Binding of input ports and partitions
• MLS Services – Enforce MAC supporting policy for print job labeling
• Map sensitivity level of jobs based on level of spooler partition • Label jobs with human readable markings
January 2006 43
System High Services
• Administrative Access Control Services – Enforce ACC policy to restrict access to objects based on User IDs
bound to the administrative subjects – Identification and authentication of administrative users – Trusted path for administrative operations
• Audit Logger – Manage audit log
• Audit records generated in partitions where events occurred • Runtime Tools
– Audit analysis, export audit data to external entity • Configuration Tools
– Create, manage MPS configuration data • Printer Services
– Filter embedded PJL code, transfer jobs to printers
January 2006 44
Non-TSF Components
• Single-level print spooler – Service print requests from clients – Manage job queues – Format and filter print jobs – Pass processed jobs to Delimiter Page Handler in MLS
partition – LPRng-like implementation
• Initialization – Read MPS configuration data – Establish MPS runtime configuration – Execute once, remain inactive during runtime
January 2006 45
Print Job Data Flow
Job Queues
Top Secret Spooler
System Services
Input/ Output Buffer
TSF Boundary
Hardware
Separation Kernel
Input/ Output Buffer
Job Queues
Secret Spooler
Initialization
System Services
System Services
TCP/ IP
Stack M
alicious PJL Filter
AA
C Services
Configuration Tools
Runtim
e Tools
Audit Logger
Label Partition
Label Delimiter
Page Handlers
MLS Services
Process within a Partition
MPS Config.
Data
S.K. Config.
Data
Networked Printer
Secret
System High
Label = Logical Function
Dedicated Printer
System Services of a Process
January 2006 46
Error Message Flow
Job Queues
Top Secret Spooler
System Services
Input/ Output Buffer
TSF Boundary
Hardware
Separation Kernel
Input/ Output Buffer
Job Queues
Secret Spooler
Initialization
System Services
System Services
TCP/ IP
Stack M
alicious PJL Filter
AA
C Services
Configuration Tools
Runtim
e Tools
Audit Logger
Label Partition
Label Delimiter
Page Handlers
MLS Services
Process within a Partition
Label = Logical Function
MPS Config.
Data
S.K. Config.
Data
Dedicated Printer
Networked Printer
Secret
System High
System Services of a Process
January 2006 47
Audit Management
Job Queues
Top Secret Spooler
System Services
Input/ Output Buffer
Hardware
Separation Kernel
Input/ Output Buffer
Job Queues
Secret Spooler
Initialization
System Services
System Services
TCP/ IP
Stack M
alicious PJL Filter
AA
C Services
Configuration Tools
Runtim
e Tools
Audit Logger
Delimiter Page
Handlers
MLS Services
MPS Config.
Data
S.K. Config.
Data
Administrator Console
TSF Boundary
Label Partition
Label
Process within a Partition
Label = Logical Function
System High
System Services of a Process
January 2006 48
Scope of Draft MPS PP
• Requirements derivation is iterative • Require traceability between activities
– Demonstrated by evidential material defined as rationale description
• Draft PP only includes – TOE description – Security environment description – Security functional requirements – Security assurance requirements
• Draft PP lacks – Traceability analysis & rationale description
January 2006 49
Security Environment & Objectives
• Security environment – Threats (16) – Assumptions (8) – Organizational Security Policies (6)
• Security objectives – TOE security objectives (24) – Security objectives for TOE environment (9)
January 2006 50
Threats, Assumptions, Policies
January 2006 51
Security Objectives
January 2006 52
Security Requirements
• Derived from security objectives • Security functional requirements (SFR)
– CC groups SFRs into 11 Classes – MPS PP includes
• 9 Classes for TOE • 1 Class for TOE environment
• Security assurance requirements (SAR) – Specify constraints and quality – EAL 4 with augmentation
January 2006 53
Security Functional Requirements
January 2006 54
Security Assurance Requirements
• Base requirements for EAL 4 • Extended requirements include
– Flaw remediation procedures – Assurance maintenance plan – Administrative guidance regarding proper setting of
configuration data • MAC enforcement: SK configuration data • MAC supporting: MPS configuration data
– Administrative guidance regarding proper handling of printed material
January 2006 55
Transition to CC V3.0
• Developed using CC V2.2 • CC V3.0 significantly different
– SFR: 6 classes instead of 11 • FCS, FMT, FPR, FRU, FTP: removed/integrated into other
classes • New class: Miscellaneous (FMI)
– SAR: ADV rewrite, new Composition class (ACO) • Challenges include
– Mapping of affected requirements – Composite evaluation – V3.1 scheduled to be released in July 2006
• Synergistic with SKPP V3.0 transition effort • Anticipated completion in April 2006
SecureCore
January 2006 57
Focus 1
• Problem – New DoD systems are based on an untried
system security architecture • MILS
– Solution • Develop new system security architecture with
proper use of emerging “high robustness separation kernel” technologies
January 2006 58
Focus 1: Optimize Use of Separation Kernel Architecture
• Separation Kernel used in – F-35, F22, Joint Tactical Radio System, C-17A
Globemaster III, and Unmanned Combat Air Vehicle • Question of cost, efficiency and security of
– Current system architecture • MILS
– Vs. other approaches • MLS security kernel • Domain and type enforcement
• New separation kernel-based architecture provides – Point for analysis and comparison – Functional and assurance improvements over MILS
January 2006 59
Focus 2
• Problem: – Future DoD security policies lack foundational
technical support 1. Dynamic and adaptive security 2. Dissemination-control
– e.g., ORCON
• Solution: – Develop sound foundations for temporal and
event-based access control
January 2006 60
Focus 2a: Dynamic Security Policies
• Access control policy may need to adapt to situational changes – Inconsistent with traditional models and
approaches • Uncharted territory
– New temporal/event model addresses significant subset
• Access denied after time or event occurs • Access denied until time or event occurs
– Complementary to other security models
January 2006 61
Focus 2b: Dissemination Control
• Longstanding technical problem • Solutions likely to enable new global information
management solutions • New temporal/event enforcement mechanisms
– Can make data “disappear” • After an untoward event
– e.g., signal that device was captured
• After time period – e.g., 24 hours without login
January 2006 62
SecureCore
• Trustworthy Commodity Computation and Communication • Sponsor: NSF and DARPA • Partners: Princeton and USC/ISI • Objective
– Design secure integrated core architectures for trustworthy operation of mobile computing devices
• Includes – Security-aware SecureCore hardware – SecureCore Least Privilege Separation Kernel – SecureCore Security Services – Secure communications
January 2006 63
Secure Core Clean-Slate Approach
• Examine past and current mechanisms • Understand context of mechanisms
– Hard 30 years ago but easy today? – Easy years ago but increasingly difficult now?
• Combine of past, present and new techniques – Utilize the best of emerging technology – Create new mechanisms as needed
• Develop – Security architecture to achieve objectives – Base for experimentation – Metrics for analysis
January 2006 64
Accomplishments to Date
• System-level description • Architectural definition • New comprehensive study of security design
principles • New conceptual model of temporal access control • Integrated hardware-software mechanism for
temporal access control and revocation • Hardware-enhanced secure object reuse
mechanism • Hardware simulator prototype to study
– Low-level system constructs – New hardware mechanisms
January 2006 65
Design Principles for Security
• Design principles key to project were identified – Technical Report prepared
• 6-month deliverable
– Will guide subsequent development – Available on NPS website
• http://cisr.nps.navy.mil/projects/securecore.html
– Currently being used in NPS Secure Systems class
• Provides roadmap for in depth topics.
January 2006 66
Least Common Mechanism
Clear Abstractions
Partially Ordered Dependencies
Efficiently Mediated Access
Minimized Sharing
Reduced Complexity
Economy and Elegance
Secure System Evolution
Trusted Components
Hierarchical Trust for Components .
Inverse Modification Threshold
Hierarchical Protection
Minimized Security Elements
Least Privilege
Self-Reliant Trustworthiness
Trust
Secure Distributed Composition
Trusted Communication Channels
Composition
Structure
Secure Defaults
Secure Failure
Self Analysis
Accountability and Traceability
Continuous Protection of Information
Economic Security
Performance Security
Ergonomic Security
Acceptable Security
Logic and Function
Repeatable, Documented Procedures
Procedural Rigor
Secure System Modification
Sufficient User Documentation
System Life Cycle
Security Design Principles
January 2006 67
System Architecture - Context
• Mobile Devices – Resource Constrained – Hostile Environments - full threat gamut – Wireless, ad hoc networks
• Security-aware – Requirements for policy flexibility while ensuring
baseline confidentiality and integrity – Able to function in changing network
environment • Mix of high and low assurance
January 2006 68
System Architecture
January 2006 69
Anticipated Technical Advances
• Kernel-based fine grain control of trusted subjects – Trusted subject may only access certain objects
in its trust range • minimizes reliance on correctness of application-
domain security services. – Formal model and architectural solution define “controlled interference” for trusted subjects.
• Subjects “read down” to blocks at lower levels, as allowed by kernel – Also, kernel-controlled controlled write-up – Traditional separation kernel architectures lack
these abilities
January 2006 70
Anticipated Advances
• Exportation of hardware interrupts to client OS. – Enables OS-specific interrupt handling regarding
subjects’ access violations to individual resources – Traditional separation kernel architectures only provide
block-level notification • Kernel-based “intransitive information flow” enforcement
– Traditionally requires trusted subjects – SecureCore supports, for example, a policy whereby
each subject may only read down one level, because of data integrity or system assurance concerns.
January 2006 71
Ongoing Work
• Least privilege-based security architecture – assured transient-trust in hand-held devices – COTS and highly trusted transactions on single
platform • Model for kernel-based control
– Intransitive information flow – Read-down by virtual machines
• Model and hardware support design for temporal access control and revocation
• Requirements definition for TPM and SP integration for Secure Core cryptographic services
• Hardware-simulator development for secure HW & SW co-design
• Distillation of design principles for modern secure systems
January 2006 72
TPM/SP Services Virtualization in SCSS
• Goal: services to support networking effort – Storage of secrets required
• Virtual functions – Make SP useable by
• SCOS, and applications • Specification of SW / HW interface • Identify additional support from
– SP – SCSS
• Benzel will lead, USC PhD student
January 2006 73
Platform Support Requirements
• Revocation – Extension of TIAC and TIMPS to accommodate highly
dynamic policies – Integrate TIMPS into ARM with Linux
• Modify Linux to use TIMPS • Develop test applications
– Will support Transient Trust • Least Privilege and virtualization
– SCSS and SCOS domains • Malleable hierarchy of privilege
– Requirements for SCOS and SCSS support • Irvine will lead, NPS staff and students
January 2006 74
Trust in Cluster Head Selection
• Cluster heads in ad hoc networks • To date, resource-based cluster head selection • New effort to integrate trust considerations • Problems to be investigated
– Attributes for trust negotiation – Event-triggered trust negotiation – SCSS primitives to support trust negotiation – Dynamic transfer of trust
• Tension between “right” trust selection and other network performance attributes
• Irvine and Chiang collaboration, NPS PhD student
January 2006 75
Protected Communications Channel
• SecureCore CONOPS includes both high integrity and multilevel channels – Must
• Protect network communications • Support external initiation of transient trust • Support applications in transient trust domain
– Explore • Existing and emerging protocols
– Context: mobile, low power, wireless • Adapt protocols for SecureCore, as needed • Leverage SP support • SCSS primitives to support PCC
• Irvine will lead, NPS PhD student
January 2006 76
Tasks and Metrics
• System Level Description • SecureCore Security Services • New Kernel and Hardware Services • New Primitives for Access Control and Revocation • Security Architecture Metrics and Analysis • SecureCore Operating System • Advancement Metrics
– Performance and security parameters – Metric definition part of research – Produce scales and points of comparison – Start with Boolean and progress to granular scale
January 2006 77
Measurement Parameters
• Granularity of privilege • Completeness of mandatory policy enforcement • Complexity of relaxed policy enforcement • Factoring and reusability of components • Large label space support • Dynamicity of security policy • Intransitive information flow • Partial ordering of dependencies • Hierarchical trustworthiness of components • Secure Defaults • Performance overhead
January 2006 78
Annotated Bibliography
• 50 Years of Hardware/OS Security • Encompasses technical literature from 1951 to
2001 • Focused on system and security-related articles • Reviewed over 360 articles in open literature
– Identified all with hardware-relevant contributions
– Prepared notes on contribution in each article • In preparation for publication
January 2006 79
Temporal Access Control
• Objective: To address revocation • Time Interval Access Control Model (TIAC)
– Uses Interval Algebra to define • Time relationships: e.g. before, during, overlaps, etc. • Current time • Subject and object authorization times
• Time Interval Memory Protection System (TIMPS) – Temporal analysis of access – Time-aware TLB mechanism – Resource and performance analysis – Logic circuit design – SimpleScalar Prototype using PISA
January 2006 80
Platform Support Requirements
• Revocation – Extension of TIAC and TIMPS to
accommodate highly dynamic policies – Integrate TIMPS into ARM with Linux
• Modify Linux to use TIMPS • Develop test applications
– Will support Transient Trust • Least Privilege and virtualization
– SCSS and SCOS domains • Malleable hierarchy of privilege
– Requirements for SCOS and SCSS support
January 2006 81
Summary
• Significant DoD problems being addressed – Revocation – Temporal access control support – Read down from virtual machine – Modeling and assured control of trusted
subjects – Codesign of HW/Kernel/Services – Unified processor approach
RCSec
January 2006 83
DRAM
DRAM
DRAM
DRAM
DRAM
DRAM
FPGA chip
SR
AM
Blo
ck
µP
BR
AM
BR
AM
BR
AM
BR
AM
B
RA
M
BR
AM
BR
AM
B
RA
M
SDRAM (offchip)
DRAM
DRAM
DRAM
DRAM
DRAM
DRAM
FPGA Fabric
Chip Melting IP Theft DoS Interference
Snooping
FPGA Fabric
µP
µP µP
Reconfigurable Hardware Problem
January 2006 84
RCSec Objectives
• Adaptive Security and Separation in Reconfigurable Hardware – Reconfigurable policy enforcement – Reconfigurable memory protection – Logic separation
• Team – UCSB:
• Tim Sherwood (PI), Ryan Kastner (Co-PI)
– NPS: • Cynthia Irvine (Co-PI), Tim Levin, Thuy Nguyen
January 2006 85
RCsec
• Adaptive Security & Separation in Reconfigurable Hardware – Reconfigurable Systems are embedded in
• Mars Rover, wireless access points, etc. – Hardware malleability can be twisted
• disrupt critical operations • snoop on supposedly secure channels, • physically melt a device.
– Need reconfigurable and secure system – Areas to be addressed:
• Logic • Memory • Dynamic policy management
CyberCIEGE
January 2006 87
CyberCIEGE Motivation
• Information Assurance is implicit in everyone’s job – Personnel need to understand their important role in IA – Administrators must know security impact of choices – Managers must understand how IT infrastructure can
support (or detract) from security policy enforcement – Certifiers must appreciate big-picture security
• Problem: – Training and Awareness can be boring – Good security practice is not “automatic”
• Should be like washing hands and using seat belts
– Many security measures combine for overall security • Complexity is hard to convey and hard to internalize
January 2006 88
CyberCIEGE Solution
• Teaching tool that engages the imagination • Demostrates consequences of security choices • Student/player responsible for organization IT
– Keep organization virtual users happy • Purchase hardware and software components • Design networks • Configure components • Manage IT staff • Ensure physical security • Require background checks for certain information access • Provide IA training • Ensure that security does not get in the way of productivity
– Protect information assets from cyber threats • Greater asset value greater attacker motivation
January 2006 89
Vandals Computer Computer
User User
Goal Goal Goal Goal
ENTERPRISE (corporation, command, etc.) PLAYER = Information Security Decision Maker
Asset $$
Asset $
Asset $$$$
Network
January 2006 90
Risk = Threat x Vulnerability
Attacker motive to compromise assets
Results of player choices
Too high and the player will lose.
Easy to reduce, but inhibits goal achievement
Players manage risk by making choices that affect vulnerabilities.
January 2006 91
PLAYER CHOICES: Affect user behavior
User User Procedural Security (e.g., logoff when away from workstation) Training
Background Checks
January 2006 92
PLAYER CHOICES: Affect computer & network configurations
Computer Computer
Network
Which computer and O/S
Configuration Settings (e.g., enforce password policy)
Asset $$
Asset $
Asset $$$$
January 2006 93
PLAYER CHOICES: Affect physical security
Who is allowed to enter the zone?
Zone access enforcement, e.g., guards, alarms.
January 2006 94
Risk = Threat x Vulnerability
Player must understand attacker motives and results of asset compromise.
…so they can make informed choices that will affect vulnerabilities.
…to manage risk such that goals are met and assets are secured.
January 2006 95
Elements of CyberCIEGE
• Simulation Engine – All security policies & wide variety of security
mechanisms – Graphics easily added
• Scenario Definition Language – Describes how Simulation Engine runs – Rich semantics – Triggers for “plot twists” and to log student progress
• Scenario Definition Tool – Supports scenario creation using a GUI
• Encyclopedia – How to use the game, security facts, why you lost
• Movies supplement encyclopedia
January 2006 96
Cynthia Irvine, Ph.D. Center for Information Systems Security Studies and Research
Computer Science Department Naval Postgraduate School, Monterey, CA 93943
[email protected], 831 656-2461
Questions and Contacts