phil yialelogou - northrop grumman corporation - criticality of employing deception in conventional...
DESCRIPTION
Phil Yialelogou delivered the presentation at the 2014 ADM Cyber Security Summit. The 2014 ADM Cyber Security Summit focused on “Combatting Emerging and increasingly sophisticated cyber threats” both domestically and internationally, and showcased relevant organisational case studies and supporting research from academia. For more information about the event, please visit: http://www.informa.com.au/cybersecuritysummit14TRANSCRIPT
Security and Separation
in a Mobile World
19th June, 2014
Phil Yialeloglou, Senior Consulting R&D Engineer
Cyber Solutions Division
2
“How hard can it be?”Jeremy Clarkson
“What were you thinking!”Dr Phil
Mobility Reality Check
• Relentless demand for “anywhere” access to information
• Users accustomed to unfettered access to unclassified information
demand similar access to classified information
• Low acceptance factor for carrying multiple devices for “Work” and
“Play”
• Denial is not a good coping strategy
Additional Risks in a Mobile Environment
• Using the device to access sensitive information in insecure locations
• Drawing unwanted attention by carrying easily identified classified
hardware
• Increased possibility of device loss e.g. Theft, seizure, loss in taxi, etc
Design Goals
• Enable a commercial smartphone or tablet to provide concurrent
access to multiple security zones
• Each security zone must support enterprise applications normally
available for a smartphone or tablet, and provide local storage for
classified data
• Each security zone must have strong isolation from other zones for
data at rest, in use and in motion
• Achieve high assurance levels for data protection with the aim of
allowing devices to be treated at a lower security classification when
not in use
Architectural Approaches to Mobility Security
• Bottom Up:
– Start with commercial baseline and harden up to your requirements.
• Top Down:
– Start with a high security reference design and relax security controls down to your
requirements.
Conventional Operating System Implementation
• Security trade off in favour of usability
• Feature bloat
– Linear growth in code and features results in exponential growth in complexity
• “After all our hard work, we finally have a secure baseline. Now
what?”
– Patches and hot fixes create a moving assurance target
• Summary: Mixing security and complexity usually ends in tears
Survey of existing CoTS Mobility Solutions
• Android 4.4 (KitKat)
– Uses SE Android in enforcing mode
– Provides SE Linux kernel Mandatory Access Control (MAC) and Middleware MAC
(MMAC) to provide strong isolation between applications, effectively reducing the
likelihood that applications can access each other’s data or escalate privileges
– Uses a mixture of native and vendor provided Mobile Device Manager APIs that
primarily monitor enterprise policy compliance. Minimal enforcement.
– Provides trusted boot via vendor-specific boot chain
– Open source
Survey of existing CoTS Mobility Solutions
• Samsung Knox
– Builds on SE Android by implementing secure boot via ARM’s trustzone
– Isolates enterprise application network access via per-application VPN
– Provides per-application encryption of Data at Rest
– Provides Mobile Device Manager APIs that allow for enterprise policy enforcement
– Samsung Knox extensions are closed source
Survey of existing CoTS Mobility Solutions
• Apple iOS 7
– Trusted boot
– Implements similar capabilities with application isolation, per app data encryption,
managed applications and per application VPN
– Relatively strong MDM APIs providing for device lockdown and policy enforcement
– Address Space Layout Randomisation (ASLR)
– Predominately closed source, rendering independent kernel modification and
security analysis impractical
Survey of existing CoTS Mobility Solutions
• Microsoft Windows RT 8.1
– UEFI for trusted boot
– Trusted Platform Module (TPM) support
– Kernel memory randomisation
– Remote device management via Open Mobile Alliance Device Management (OMA
DM) protocol
– Predominately closed source, rendering independent kernel modification and
security analysis impractical
Suitability of existing CoTS Mobility Solutions
• The isolation based application models used by SE Android and Knox
are a leap forward in protecting against rogue applications
• They have a sea of complexity below their container models making
accreditation above Protected impractical
• Kernel and privileged user space application vulnerabilities not yet
addressed
• Underlying SE Linux helps, but residual threats can’t be addressed by
SE Android and SE Linux alone
MLS or MILS?
• Multiple Levels of Security (MLS) system
– An information system that handles information at different security
classifications, typically via labelling and access controls
– Traditionally achieved via a trusted operating system
• Multiple Independent Levels of Security (MILS)
– Isolated security zones, each handling a single security classification,
interconnected or isolated by cross-domain trusted components
– Architecture divided into trusted and untrusted components, allowing for a divide-
and-conquer security model
Trick Question
• How do I trust a conventional mobile device operating system to keep
my secrets?
• Answer: You don’t!
Isolate it in a single security domain and trust the isolation mechanisms instead.
Conclusions
• Minimise trusted code base to simplify accreditation
• Ensure OS has minimal security role to allow for easy upgrade with
minimal accreditation impact
• Obvious choice: Separation kernel based multiple persona device
Virtualisation 101
• Enterprise Virtualisation
– Goal: Allow separate servers to execute as VMs on a single physical machine to
leverage available hardware, memory and storage
– Examples: VMWare, HyperV, Xen, KVM
• Separation Kernels
– Goal: Provide security isolation and strictly enforced access controls between VMs
– Examples: Integrity, seL4
Tools for Handling Classified Information with
Commercial Systems
• NSA Suite B Cryptography
– Equivalent protection to Suite A using appropriate MoTS implementation
– Cannot guarantee equivalent protection in CoTS
• NSA CSfC Program
– VPN Capability Package
• Current Approved Version: 2.0, May 2013
• Current Draft Version: 2.08
– Mobility Capability Package
• Current Draft Version: 2.3
– Currently best practice for CoTS risk management
Mobility Accreditation Building Blocks
• ASD ISM
• Common Criteria Protection Profiles
• Defence in depth architecture leveraging a separation kernel for
containment
• Risk minimisation strategies leveraging NSA’s CSfC VPN and Mobility
capability packages
– Accreditation trend originating from US for CoTS based solutions to support up to
Top Secret with appropriate controls
System Accreditation
• Biggest project risk
• Early and regular engagement with accrediting body
– Lowers accreditation risk
– Eliminates “bolt-on” complexity to meet unforseen security requirements or design
flaws
– Removes unnecessary complexity based on security “over-engineering”
Handset Case Study - Design
• Install a separation kernel on a CoTS Android handset
• Provide high assurance isolation of sub-systems on the handset by
hosting “sandboxes” with enforced kernel communication channels
• Host separate instances of Android for “Work” and “Play”
• Isolate hardware components by assigning them to “handler”
sandboxes
Handset Case Study (continued)
• Use a “secure element” for cryptographic functions, keystore and
encryption of Data at Rest
• Use CSfC framework to implement two layer Suite B VPN with
separate trust anchors for the Inner and Outer VPN
• Implement a trusted boot chain to provide assurance of the initial
handset state
• Implement remote attestation to evaluate the runtime security posture
of the handset
Handset Case Study (continued)
Security Zone HighSecurity Zone Low
Separation Kernel
HW Layer
Guest Android Guest Android
Virtual Services
CellvAudio,
vDisplay, vRIL,
vWifi, vGSM,
vSys, IP
Gateway
Android Apps
MDMAndroid
AppsMDM
Security Services
Cell
Secure Element Services
CellvHSM,
vKeyStore
vDaR
z
z
Baseband
Radio
WiFi
Radio
Bluetooth
RadioCamera
Touch/
keys
Secure
Element
Speaker/
MicStorageGraphics
Gateway Case Study
• Two independent VPN layers with different codebases and separate
inner and outer trust anchors
• Strict whitelist policy on network traffic at each layer enforced by
firewalls and cryptographic separation
• Cybersecurity monitoring at each layer
• Inner security zone separated from internal network by trusted filters to
manage exposure risk from mobile environment
Gateway Case Study
User Experience
Or “A day in the life of a dual-domain phone user”
Summary
• Virtualisation does not fundamentally change the security model
• New focus on assurance of separation kernel, trusted VMs and
underlying hardware
• Defence in depth using “secure element” for dual VPN keying and DaR
lowers the risk of using CoTS hardware
• Lowering security reliance of hosted operating system allows for rapid
upgrade cycle
References
Australian Signals Directorate
Australian Government Information Security Manual (ISM)
Mobile Device Fundamentals Protection Profile, version 1.1
ASD Mandatory Requirements Addendum, version 1.0
http://www.asd.gov.au/infosec/ism/index.htm
G. Heiser, “Hypervisors for Consumer Electronics”
http://www.ssrg.nicta.com.au/publications/papers/Heiser_09.abstract
S. Smalley, “Laying a Secure Foundation for Mobile Devices”
http://www.internetsociety.org/doc/laying-secure-foundation-mobile-devices
NSA CSfC Program
http://www.nsa.gov/ia/programs/csfc_program/index.shtml
NSA Suite B Cryptography
http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
28