Welcome [www.opengroup.org]

Download Report

Transcript Welcome [www.opengroup.org]

Welcome
Jericho Forum Meeting
21-22 September 2006
Hosted by The Boeing Corporation
Seattle, WA., USA
www.jerichoforum.org
Introductions & Overview
 Ian Dobson
Director, Jericho Forum, The Open Group
 Chris Parnell
Director, Membership & Services, The Open Group
 Stephen Whitlock
Chief Security Architect, Boeing
and Jericho Forum Board Member
Housekeeping & Logistics
 Thursday
– Health & Safety
– Facilities
– Breaks & Lunch
– Evening networking arrangements
 Friday
– Marriott Sea-Tac Airport
– Start 09.00
– Close 15.30
Agenda – Thursday September 21
 09.30 Introductions and overview (Ian Dobson, The Open Group)
 09.40 Our de-perimeterized environment - responding to the challenge










(Stephen Whitlock, Boeing)
10.40 Break
11.00 Client machines (Chandler Howell, Motorola)
12.15 Network controls (Carl Bunje, Boeing)
13.00 Lunch
14.00 Network Controls (contd.)
14.30 Application/server (Conrad Kimball, Boeing)
15.45 Break
16.15 Data/Information Security (Jeremy Hilton, Cardiff University)
16.45 Summary (Ian Dobson)
17.00 Close
 17.00-18.00: Visit round main area of the Museum of Flight
 18.30-21.00: Networking dinner in Personal Courage Wing
Agenda – Friday September 22












09.00 Introductions & Overview (Ian Dobson, The Open Group)
09.10 Opening Keynote (Ben Norton, The Boeing Corporation)
09.30 The Commandments (Jeremy Hilton, Cardiff University)
10.30 Break
11.00 Position Papers: overview, highlights in selected papers (Stephen
Whitlock, The Boeing Corporation)
11.45 Q&A
12.45 Lunch
13.45 Case Study: Migration to de-perimeterized environment
(Stephen Whitlock)
14.15 Future Directions (Jeremy Hilton)
14.50 Q&A
15.25 Summary (Ian Dobson)
15.30 Close
Some of our members
Foreign &
Commonwealth Office
Cabinet Office
What’s in a name …

Why we chose Jericho …
– “the walls came tumbling down”

Other Jerichos
– Biblical – Joshua and the battle of Jericho – amidst blowing of loud horns and
shouting, the walls of Jericho came tumbling down
– CBS series: Jericho, Kansas - a baffling explosion occurs in the distance - Jericho's
residents are plunged into social, psychological and physical chaos - how will they
respond? - www.cbs.com/primetime/upfront_2006/jericho.shtml
– Jericho Web site design - www.jericho.co.nz
– National Jericho Movement – www.thejerichomovement.com
– Chris Jericho – www.chrisjericho.com
– Jericho, Vermont - www.jerichovt.gov
– Jericho Road – matching gifts to needs and programs to service – www.jericho.org
– More …

De-perimeterization … again, why this name?
– Re-perimeterization - the interim step of moving perimeters to protecting groups
of computer servers or a data centre – rather than the perimeter.
– “micro-perimeterisation” – moving protection to individual computer systems or
an individual application (comprising a cluster of computers)

A word of caution: Analogies are like a bucket with a hole filled with water –
you can only take it so far before it ceases to work …
So - Agenda for today
 09.40 Our de-perimeterized environment - responding to the challenge










(Stephen Whitlock, Boeing)
10.40 Break
11.00 Client machines (Chandler Howell, Motorola)
12.15 Network controls (Carl Bunje, Boeing)
13.00 Lunch
14.00 Network Controls (contd.)
14.30 Application/server (Conrad Kimball, Boeing)
15.45 Break
16.15 Data/Information Security (Jeremy Hilton, Cardiff University)
16.45 Summary (Ian Dobson)
17.00 Close
 17.00-18.00: Visit round main area of the Museum of Flight
 18.30-21.00: Networking dinner in Personal Courage Wing
Jericho Forum Introduction
 Steve Whitlock
The Jericho Forum Board
The Jericho Forum originated in
the UK in 2003 with:
Paul Dorey,
BP
John Meakin,
Standard
Chartered Bank
David Lacey,
Royal Mail
Paul Simmonds,
ICI
The Business Problem

Business trends & needs breaking traditional
network perimeter
–
–
–
–

Cost effective networking
Collaborative business
Outsourcing
Joint venturing
For Standard Charter Bank:
– Challenge of doing business in Africa
• Network bandwidth availability
– Challenge of grasping market opportunity
• Eg Afghanistan, Iraq
Current Network Security
Strategy


“It’s all about the firewalls….”
Premise:
–
–

Control remote connectivity for:
–
–
–
–




SCB internal network is “open” at network layer
All restriction of access and protection of data occurs at higher
layers (host, application, etc)
off-network hosts/people via “trusted”/“untrusted” networks
“trusted” third-parties via “trusted” third-party networks
“trusted” third-parties via “untrusted” networks, ie Internet
“untrusted” third-parties via Internet
Maintain same level of trust at each layer in multi-layer
boundary model
Ensure that SCB network protected by “defence in depth”
Provide range of cost-effective solutions for above scenarios
Provide resilient connectivity as option where
business transaction requirements specify
The Death of the Perimeter

Business is conducted over networks
– Multitude of connection points
– Multitude of traffic types (protocols, content)
– Complication!

Traditional perimeter security doesn’t scale:
– For filtering of addresses or protocols
– For management of multiple gateways



Mobile & wireless technology (largely) ignores the
perimeter control
Most large corporations have leaky perimeters
Perimeter security does nothing about data flow
and residence
The Challenge
 Business transactions
– from any PC
– on any network
– anywhere
– by anyone of a wide range of different
personnel
 Direct to one/more small corporate “island”
core(s)
 With fully “externalised” network
Increasing Management & Integration Required
“Traditional” Internet B2B
“Traditional” Trusted Third-Party
Core to Core over Internet
Branch Office to Core over Internet
Rep Office to Core over Internet
Third-Party Managed Office to Core
Server to Server over Internet
Home PC to Core over Internet
Mobile Device to Core over Internet
Kiosk PC to Core over Internet
Shrinking Perimeter
Scenarios
Where are we heading?
Secure buildings
Personnel contracts
Permissions/ Vetting
Guards and gates
1980s
1990s
Network
firewalls
Managed Networks
Directories
Single sign-on
Perimeter Security
?
Streetwise users
Virtual Enterprises
Virtual Security…?
?
21st Century
Cyberspace
road warriors
How soon will this hit us?
“People often overestimate what will
happen in the next two years and
underestimate what will happen in ten.
I’m guilty of this myself.”
Attributed to Bill Gates
So, the Vision we agreed was:
Vision
 To enable business confidence for collaboration
and commerce beyond the constraint of the
corporate, government, academic & home office
perimeter, through;
– Cross-organisational security processes and services
– Products that conform to Open security standards
– Assurance processes that when used in one organisation
can be trusted by others
Initial visioning whitepaper at:
http://www.jerichoforum.org
…and the Mission and
Milestones:
Mission
 Act as a catalyst to accelerate the achievement of the Vision,
by;
– Defining the problem space
– Communicating the collective Vision
– Challenging constraints and creating an environment for
innovation
– Demonstrating the market
– Influencing future products and standards
Timetable
 A period of 3-5 years for the achievement of its Vision, whilst
accepting that its Mission will be ongoing beyond that.
Originally established six
Working Groups . . .

Meta
Architecture
 Conceptual scope, structure, dependencies and

Trust
Models
 Future business requirements for identity

Technology
& Standards
 Intercepts with current/future vendor R&D and

Requirements  Future business requirements for information
& Ontology
management and security requirements management

Management
& Monitoring
 Future business requirements for operational security

PR, Media
& Lobbying
 Promotion of our programme in public affairs, relevant
objectives for de-perimeterisation
management and assurance
product roadmaps
management in de-perimeterised environments
interest groups and regulatory/ legislative agendas;
collaboration with these groups
Now collapsed to three
Working Groups . . .

Requirements

Ensure the Jericho Forum vision is analysed and articulated in
detail:
 define business principles and scenarios that coherently define
de-perimeterisation and its relevance to organisations' business
goals

Solutions

Identify the technology and standards needed to achieve the
Jericho Forum vision and mission, via
 immediate and near term implementations of available
technology
 longer term evolution of technical standards (both de facto and
de jure)
 vendor roadmaps

Stakeholders

Ensure the Jericho Forum involves and gets its message
across to 'movers and shakers' in relevant business,
government, pan-government, citizen, academic, technology,
business venturing and security communities
Initial set of scenarios
 Provide low-cost
connectivity
 Support roaming
personnel
 Allow external access
 Access over wireless/public networks
 Domain inter-working via open networks
 Phoning home from a hostile environment
 Enable portability of identities and data
 Application access by suppliers, distribution agents
or business partners
 Outsourced help desk access to int. systems
 Improve flexibility
 Connect organisations using secure XML
 Consolidate/ interconnect identity & access
management
 Automate policy for controlled info sharing
 Harmonize identities and trust relationships with
individuals
Initial Conclusions…
Impacts of the information age are now well known:
Network externalities, disintermediation
Power of globalisation
Information Risks and their impacts
We have lessons from other infrastructure changes
(electricity, railways, etc)
 Tools such as Technology Road Mapping and Scenario
Planning can be used to explore the impact of key drivers,
trends and events
 IT products emerging in the next 3 -10 years
are likely to be in today’s research labs
…so this is about getting the right products in place





Observations on root causes…








Many IT ‘standards’ are broken in practice, e.g.:
Certificate/CRL (non) processing in SSL
Bug-compatible implementations of X.509 certificate
extensions processing in crypto software
Representing collaborating/cooperating organisations in
X.500/LDAP; directory interoperability
Re-inventing the wheel for security services for XML
(Signatures, Encryption, Key Management…)
Repeated technical standards initiatives with little or no
‘user’ / vendor dialogue:
Vendors supposedly understand ‘user’ requirements
‘Users’ can’t and/or don’t articulate what they want…
…as well as lively debate on
what to call it…
 De-Perimeterisation
 Re-Perimeterisation
 Radical Externalisation
 Shrinking Perimeters
 Security Without Frontiers
 Boundary-Less Information FlowTM
 antideperimeterizationestablishmentarianism
…with a key qualification
on the “de-”
 Why would you still have a perimeter?
–
–
–
–
–
–
–
–
Block external attacks in network infrastructure
IP spoofing
Block noise and control intranet
Denial of service attacks
Protection from random traffic
Routing and network address management
Legal barrier
Evidence of corporate boundary
Depending on business mission, criticality etc.
So what is de-perimeterisation?
It’s fundamentally an acceptance that;
 Most exploits will easily transit perimeter security
– We let through e-mail
– We let through web
– We will need to let through VoIP
– We let through encrypted traffic (SSL/TLS, SMTP-TLS, VPN)
 Your border has effectively become a QoS Boundary
 Protection has little/no benefit at the perimeter,
 it’s easier to protect data the closer we get to it,
 A hardened perimeter strategy is at odds with current and/or
future business needs,
 A hardened perimeter strategy is un-sustainable.
So what is its effect?
 Your border is effectively a QoS Boundary
 Protection has little/no benefit at the
perimeter
 It’s easier to protect data the closer we get
to it
 A hardened perimeter strategy is at odds
with current and/or future business needs
 A hardened perimeter strategy is
un-sustainable.
So what is it actually?
It’s a concept;
 It’s how we solve the business needs for our businesses
without a hardened perimeter,
 Its how businesses leverage new opportunities when there is
no hardened perimeter,
 It’s a set of solutions within a framework that we can pick and
mix from,
 It’s defence in depth,
 It’s business-driven security solutions
It is not a single solution – it’s a way of thinking . . .
Thus;
 There’s a need to challenge conventional thinking
 There’s the need to change existing mindsets
Why the Jericho Forum?
No one else was discussing the problem
Everyone was fixated on perimeter based designs
Somebody needed to point out the “Kings new clothes” to
the world
 Someone needed to start the discussion



What’s in it for us?
 We need Security Solutions that support de-perimeterisation
– so we aim to stimulate a market for solutions to
de-perimeterisation problems
 We want these solutions to use open standards, to improve
interoperability and integration, both within our own IT
systems and with our business partners
 Ultimately, we need products to implement
The Jericho Forum Composition
Initial Composition
 Initially only consumer (user) organisations
–
–
–
–
To define the problem space
To create the vision
Free from perception of taint from vendors
With the promise of vendor involvement once the vision defined
That point is here now, and we have our first vendor members
But with safeguards to ensure independence;
 User members own the Forum, vote on the deliverables and run
the Board of Managers
 Vendors have no voting rights on deliverables or the direction
and management of the Forum.

The Open Group relationship
 Why The Open Group?
– Experience with member-led “groups” of organisations and
individuals
– Track record of delivery
– Regarded as open, vendor neutral, and impartial
– All published output is free or available under equal fair
license terms
– Existing governance framework with a good fit for Jericho
Forum requirements
– Existing legal framework – protects Forum members
– Global organisation
– Open Group vision for Boundaryless Information Flow is
well aligned with Jericho Forum vision for deperimeterisation
The Jericho Forum Charter
The Jericho Forum Aims . . .






to drive and influence the discussion / change the mindset
to demonstrate how de-perimeterised solutions can work in
the corporate space
to refine and distinguish between what are Jericho Forum
architectural principals vs. good secure design
to build on the work in the published Visioning Document
to define key items aligned with messages that make them
specifically part of the Jericho Forum solutions space
to clarify that there is not just one “Jericho Forum solution”
The Jericho Forum IS NOT . . .



another standards body
a cartel – this is not about buying a single solution
here to compete with or dismantle existing “good security”.
Jericho Principals vs. Good
Secure Design
Fast Delivery
COTS
Secure Design
Inherently Secure
Systems, Protocols
& Data
De-Perimeterised
Architecture
Feature Rich
Business
Driven
Some things to think about…

The remote PC
– Is it securely configured?
– Is it infected with malware?
– What about data stored locally?

The network
– What happens to my data passing over it?

The island host
– Who do I let in?
– How to I exclude others?

The management
– How to manage ‘000s of points of control to the same
standard with robustness
Organisations will continue to
change …
Strong
“Organism”
External
relationships
Trend
“Machine”
Weak
‘Soft’
Internal
relationships
‘Hard’
How will we respond?
 The loss of perimeter security will force us to shrink
perimeters to clients, applications and ultimately
data
 IP Convergence will accelerate this process by
challenging existing network security architectures
 We will realise that securing our own backyard is no
longer sufficient, and work together to develop
federated solutions to secure data across
boundaries
 We need common policy languages to support
cross-organisational processes, including federated
identity and access management
The Jericho Forum Challenge
We believe, that in tomorrow’s world
the only successful e-transactions &
e-businesses will utilise a
de-perimeterised architecture
Thus you only have two choices;
 Do you sit back and let it happen to you?
Or
 Do you help design the future to ensure it fits
YOUR business needs?
Current Jericho Forum Board
 Nick Bleech, Rolls-Royce plc
 David McCaskill, Proctor & Gamble
 John Meakin, Standard Chartered Bank
 Paul Simmonds, ICI
 Shane Tully, Qantas Airways
 Steve Whitlock, The Boeing Company
 Andrew Yeomans, Dresdner Kleinwort
Some of our members
Foreign &
Commonwealth Office
Cabinet Office
Shaping security for
tomorrow’s world
www.jerichoforum.org
Client Security in a Deperimeterized
World
Motorola Document Classification, File Name, Rev Number
Add additional legal text here if required by your local Legal Counsel.
MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office.
All other product or service names are the property of their respective owners. © Motorola, Inc. 2005
Agenda
What is a client? Everything
Requirements: What we need to do
Capabilities: What we can do
Gaps: What we can’t do (yet)
Progress: What we’re doing about it
Motorola Internal Use Only, Jericho Forum Client Security.ppt, Rev 1.0
MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office.
All other product or service names are the property of their respective owners. © Motorola, Inc. 2005
What is a client?
Everything
Data leaks into every corner of every little place we keep
electrons:
•
•
•
•
•
•
Workstations
Laptops
Mobile Phones
PDA’s
Kiosks
Flash Drives
Motorola Internal Use Only, Jericho Forum Client Security.ppt, Rev 1.0
MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office.
All other product or service names are the property of their respective owners. © Motorola, Inc. 2005
• Personally-owned
computers
• Shared Workstations
• Services (Google
Office/Gmail)
• iPods
Requirements
What we need to do
Extend the Enterprise
Beyond the office walls
Beyond company-owned devices
Access Applications and Information
Email
Documents/Presentations/Spreadsheets
Internal Web sites
Instant Messaging
Telephony
Protect Information at-rest
Full-Disk Encryption
Rights Management
Files & Email encryption (Public Key Cryptography)
Protect Hosts
Anti-Virus/Anti-Malware
Firewall
Patch automation & management
Configuration management
Motorola Internal Use Only, Jericho Forum Client Security.ppt, Rev 1.0
MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office.
All other product or service names are the property of their respective owners. © Motorola, Inc. 2005
Capabilities
What we can do
Extend the Enterprise
Beyond the office walls
Laptops (Traditional clients)
IPSEC & SSL VPN
Beyond Company-owned devices
SSL VPN’s
Smartphones and “Thin” clients
Transient (display-only) access
Access Applications and Information
Outlook Web Access
Portal-izing/Proxying applications
Protect Information at-rest
Full-Disk Encryption
Email & File Encryption (Public Key Cryptography)
Protect the Host
Anti-Virus, Anti-Spyware
Personal Firewalls
Patch & Configuration Management
Motorola Internal Use Only, Jericho Forum Client Security.ppt, Rev 1.0
MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office.
All other product or service names are the property of their respective owners. © Motorola, Inc. 2005
Gaps
What we can’t do (yet)
Extend the Enterprise
Focus on the data, make the device irrelevant
Support Microsoft-y protocols
Too many ports, too little control, too much bad history
Even Microsoft admits this problem is still unsolved
Easy Strong Authentication
Especially on Mobile Devices
Protect Information at Rest
Rights Management
Provide rights management for arbitrary file types
Support ad-hoc protection (This will come as the tools mature)
Protect the Host
Host protection often still requires users to lose control
Ensure patching and configuration management
Motorola Internal Use Only, Jericho Forum Client Security.ppt, Rev 1.0
MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office.
All other product or service names are the property of their respective owners. © Motorola, Inc. 2005
Progress
What we’re doing about it
Extend the Enterprise
Data-Centric Protection
Focus on defending the data, make the device & network location irrelevant
Transient/Display-only access
Mobile Portal
Application proxying, screen scraping
SSL VPN
Limited access, non-Domain member access
Protect Information at Rest
Rights Management
Control what authorized users do with information
Trusted Computing
Already exists in phones but is frequently cracked
Prospects for the PC are probably worse
Protect the Host
Trusted Computing
Time will tell, but it’s not doing well thus far
Motorola heavily involved in Rights Management on the product side
Host validation
Patches & configuration checked, but only with SSL VPN
Motorola Internal Use Only, Jericho Forum Client Security.ppt, Rev 1.0
MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office.
All other product or service names are the property of their respective owners. © Motorola, Inc. 2005
Thank You
Questions and Discussion
Contact: Chandler Howell
[email protected]
Motorola Internal Use Only, Jericho Forum Client Security.ppt, Rev 1.0
MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office.
All other product or service names are the property of their respective owners. © Motorola, Inc. 2005
Network Controls
Engineering, Operations & Technology | Information Technology
• Network Controls
Discussion on Approach and Implications
for a Deperimeterized Enterprise
• Carl Bunje
The Boeing Company
•
Jericho Forum
20 September 2006
Seattle, Washington, USA
Copyright © 2006 Boeing. All rights reserved.
Agenda
Engineering, Operations & Technology | Information Technology
• 12:15–13:00 Presentation and Discussion
• 13:00–14:00 Lunch
• 14:00–14:30 Continued Discussion
Copyright © 2006 Boeing. All rights reserved.
Key Architectural Principles and Desired Characteristics
Engineering, Operations & Technology | Information Technology
• Least Privilege
• Provide only the least number of privileges necessary for the
principal to be able to perform his/her/its assigned tasks
• Defense in Depth
• Layered access control
–
–
–
–
Platform Hardening
Network Reachability
Application Access Control
Information/Operation Access Control
• Intrusion Detection and Prevention
– Network
– Server
– Application
• Audit and Conformance
• Plus…
• Personal Responsibility and Behavior
Copyright © 2006 Boeing. All rights reserved.
Layered Access Controls
Engineering, Operations & Technology | Information Technology
This diagram represents, beginning at
the outer ring, the multiple IT
components that are traversed when
attempting to access computers and
hosted data.
Access to Data
Encryption
Data
Encryption / DRM
(may be null)
Each layer represents an opportunity to
implement access control measures that
can contribute to the overall security of
computers and our data.
Application
(may be null)
Hosting OS Instance
Access to Host
Encryption
This is intended to be a reference model
to facilitate discussion of which
measures to implement, and where to
place them.
(may be a partition or virtual machine)
Hypervisor / VMM Environment
(may be null if not a partition or virtual machine)
Internal Network
(switches / routers / VLANs / packet filters / etc.)
Perimeter & DMZ
(may be null for devices connected to internal network)
External Network
In any particular real-life scenario under
discussion, some of these layers likely
will be null.
(switches / routers / VLANs / packet filters / etc.)
Accessor Device Hypervisor / VMM Environment
(may be null if only one OS instance on the device)
Accessor Device OS Instance
(device = user device, server, etc.)
Copyright © 2006 Boeing. All rights reserved.
Scenario 1 – Traditional Perimeter
Engineering, Operations & Technology | Information Technology
User
Device
Trusted Internal Environment
What are the implications of trust within the
perimeter?
IPP
Public
Internet
Extrnl
Applic.
Enterprise
Intranet
PEP
PEP-1
IPP
Traditional Perimeter PEPs:
 Authenticate external source.
 Determine health of external source.
 Enforce encryption.
 Control external access to internal IPPs.
 Control internal access to external IPPs.
 Hide internal addresses (NAT).
 Hide internal URLs
 Provide identity and health information to
other PEPs and to higher-level access
control layers.
 Log accesses.
Copyright © 2006 Boeing. All rights reserved.
IPP
IPP
IPP
User
Device
User
Device
User
Device
IPP
Internal
Applic.
IPP
Internal
Applic.
IPP
Internal
Applic.
IPP
Internal
Applic.
IPP
Internal
Applic.
PEP = Policy Enforcement Point
IPP = IP address : Port : Protocol
Scenario 2 – Reduced Perimeter
Type 3 PEPs:
? Any of the functions listed under Type 1
? Authorize internal source
? Control access to Access Zones (IPPs)
? Control access among IPPs (within Access Zone)
? Log accesses
Engineering, Operations & Technology | Information Technology
User
Device
? Trusted Environment ?
What level of trust is associated with elements
within the enterprise boundaries?
IPP
Public
Internet
Extrnl
Applic.
Enterprise
Intranet
PEP-1
PEP-1
PEP-3
PEP-3
IPP
IPP
Internal
Applic.
IPP
Internal
Applic.
IPP
Internal
Applic.
IPP
Internal
Applic.
IPP
Internal
Applic.
PEP-2
PEP-2
Type 1 PEPs:
? Authenticate external source.
? Determine health of external source.
? Enforce encryption.
? Control external access to internal IPPs.
? Control internal access to external IPPs.
? Perform network address translation (NAT).
? Provide identity and health information to
other PEPs and to higher-level access
control layers.
? Log accesses.
Copyright © 2006 Boeing. All rights reserved.
IPP
User
Device
IPP
User
Device
IPP
User
Device
Type 2 PEPs:
? Same as Type 1 PEPs
? Control access among user
PEP = Policy Enforcement Point
device IPPs.
IPP = IP address : Port : Protocol
? Control access from external
or other IPPs
Scenario 3 – No Perimeter
Type 3 PEPs:
? Any of the functions listed under Type 1
? Authorize internal source
? Control access to Access Zones (IPPs)
? Control access among IPPs (within Access Zone)
? Log accesses
Engineering, Operations & Technology | Information Technology
User
Device
IPP
Untrusted Connectivity Infrastructure
What are the implications of untrusted
connectivity among sites and services?
Public Internet
Extrnl
Applic.
PEP-3
PEP-3
IPP
IPP
Internal
Applic.
IPP
Internal
Applic.
IPP
Internal
Applic.
IPP
Internal
Applic.
IPP
Internal
Applic.
PEP-2
PEP-2
Type 1 PEPs:
? Authenticate external source.
? Determine health of external source.
? Enforce encryption.
? Control external access to internal IPPs.
? Control internal access to external IPPs.
? Perform network address translation (NAT).
? Provide identity and health information to
other PEPs and to higher-level access
control layers.
? Log accesses.
Copyright © 2006 Boeing. All rights reserved.
IPP
User
Device
IPP
User
Device
IPP
User
Device
Type 2 PEPs:
? Same as Type 1 PEPs
? Control access among user
PEP = Policy Enforcement Point
device IPPs.
IPP = IP address : Port : Protocol
? Control access from external
or other IPPs
Discussion / Q&A
Engineering, Operations & Technology | Information Technology
• Have you considered these scenarios? Others?
• What do you think the characteristics of these PEPs need to be?
• What are the implications of shifting or eliminating some of these
controls?
• Are Layers of Network controls desired or redundant?
Copyright © 2006 Boeing. All rights reserved.
Discussion / Q&A
Engineering, Operations & Technology | Information Technology
• What does Scenario 3 – No Perimeter REALLY look like?
• Collection of Site Perimeters?
• Is it viable for YOUR business environment?
• Why or Why not?
Copyright © 2006 Boeing. All rights reserved.
Shaping security for tomorrow’s world
Engineering, Operations & Technology | Information Technology
www.jerichoforum.org
Copyright © 2006 Boeing. All rights reserved.
Deperimeterization
vis-à-vis
Servers & Applications
Conrad Kimball
9/18/2006
BOEING is a trademark of Boeing Management Company.
Copyright © 2006 Boeing. All rights reserved.
Agenda
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
If the perimeter disappears, how do I still
accomplish computing security?
• No answers – just work-in-progress thoughts about how to frame the
discussion.
• A taxonomy of how we view the server & application access control
landscape.
• A reference model for placing access control points.
• Open discussion.
Copyright © 2006 Boeing. All rights reserved.
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
A Taxonomy of
Protective Measures
Copyright © 2006 Boeing. All rights reserved.
Keeping Computing Security Happy
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
When we expose a system to external users we must:
• Protect the system’s software and data from unauthorized
disclosure.
– Comply with regulations such as ITAR and EAR, protect our
intellectual property, comply with contractual agreements for
handling intellectual property of others, etc.
• Protect the system itself from compromise (system vulnerability).
• Protect the rest of our systems from unauthorized access
originating from this system (transitive access).
– Premise: the rest of our systems are vulnerable, and we do not plan
to fix them, so the burden is on the externally-accessed system.
Copyright © 2006 Boeing. All rights reserved.
Why This Talk About OS Instances?
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
Prior to virtualization mechanisms such as VMware the terms
“computer” and “OS instance” were synonymous - a computer
could have just one instance of an operating system.
But now a single computer can host multiple operating system
instances in the form of “virtual machines”, each owned by a different
organization, performing a different function, and with differing security
requirements and characteristics.
Particularly for “network reachability”, it is no longer sufficient to think
in terms of controlling access to physical computers or to Cisco switch
ports:
• There can be multiple OS instances on a computer, all behind
a single NIC, all on the same switch port, and they can communicate
with each other without ever involving the NIC or Cisco switch.
Copyright © 2006 Boeing. All rights reserved.
A Taxonomy of Protective Measures
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
1. Limit who can reach your OS instance in the first place
(“network reachability”).
•
Controls that operate at the network level.
– Limit at the transport level, by controlling connectivity (airgaps,
VLANs, etc.) or by IP address / port number filtering (firewalls,
packet filters, router ACLs, etc.)
– Limit at higher levels of the protocol stack by content inspection
(proxy servers, etc.).
•
If doing filtering, ideally the Policy Enforcement Point makes
decisions based on user identity.
– But in many situations (filtering at the transport level) the PEP does
not know the user identity.
– Decisions generally can be based only on origin and/or destination
IP address and/or port number (e.g. packet filters, router ACLs), or
on other equivalent attributes (e.g. packet tagging).
Analogy: a fence around your property.
Copyright © 2006 Boeing. All rights reserved.
A Taxonomy of Protective Measures
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
2. Once they’ve reached your OS instance, limit the ways in.
•
Limit the source addresses / port numbers that you are willing
to talk to (firewall software, IPSec filtering, etc.)
•
Limit the entry points that are open (port numbers, etc.)
•
Control who can gain access through those entry points
(require user login, etc.)
Analogy: limit the number of doors and windows in your building,
secure them, ask for ID, etc.
Copyright © 2006 Boeing. All rights reserved.
A Taxonomy of Protective Measures
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
3. Once they’ve gained access to your OS instance,
limit what they can do within your OS instance.
•
At the OS level, control access to software and OS-managed
information (use ACLs on file systems & directories, use
techniques like chroot to construct a jail environment, use
more sophisticated software like Vormetric CoreGuard, etc.)
•
At the application level, control access to application
functionality, and to application-managed information
(row-level access controls in databases, People & Organization
roles within a ENOVIALCA, etc.)
Analogy: secured rooms within a building, put your valuables
in a safe, etc.
Copyright © 2006 Boeing. All rights reserved.
A Taxonomy of Protective Measures
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
4. Once they’ve gained access to your OS instance, limit where they
can go (they can get in, but they can’t get out…)
•
Try to limit access to software and APIs capable of initiating
outbound connections.
– Example: block access to the ftp program.
– Often a lost cause (business requirements that include scripting,
development projects where users need administrative rights, etc.)
•
Or institute “roadblocks” at the network level, either internallyor externally-implemented.
– Internal example: IPSec capability in the OS to filter
outbound connections on IP address & port.
– External examples: packet filter, router ACLs.
Note: This is really a burden imposed on you because other
systems are vulnerable – their problem, which you get to fix.
Copyright © 2006 Boeing. All rights reserved.
A Catalog of Protection Techniques
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
The preceding taxonomy speaks in terms of what must be done,
not how to do it.
There is not one “right” architecture, tool, or technique to implement
any of these measures.
Instead, we have a variety of sometimes overlapping mitigation techniques
available to us, which can address one or more of these categories of
protection, with varying degrees of comprehensiveness, generality,
technical difficulty, operational difficulty, and expense.
Copyright © 2006 Boeing. All rights reserved.
A Catalog of Protection Techniques
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
Which mitigation technique(s) to employ will depend greatly on the specific
situation at hand.
To that end I propose we build a catalog of these techniques, identifying
which protection categories each addresses, how well it does or does
not do so, and so forth.
This catalog should be accompanied by some design patterns and
examples of how these techniques can be applied to common scenarios,
to promote reuse and best practices.
Copyright © 2006 Boeing. All rights reserved.
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
A Reference Model
for Placing
Access Control Points
Copyright © 2006 Boeing. All rights reserved.
A Reference Model of the Potential Points to Place
Access Control Around Our Computers and Our Data
Engineering, Operations & Technology | Information Technology
This diagram represents,
beginning at the outer ring,
the multiple IT components
that are traversed when
attempting to access our
computers and our
hosted data.
Computing & Network Operations
Access to Data
Encryption
Data
Encryption / DRM
(may be null)
Application
(may be null)
Access to Host
Encryption
Hosting OS Instance
(may be a partition or virtual machine)
Hypervisor / VMM Environment
(may be null if not a partition or virtual machine)
Each layer represents an a
potential place to implement
access control measures that
can contribute to the overall
security of our computers and
of our data.
Internal Network
(switches / routers / VLANs / packet filters / etc.)
Perimeter & DMZ
(may be null for devices connected to internal network)
External Network
(switches / routers / VLANs / packet filters / etc.)
Accessor Device Hypervisor / VMM Environment
(virtual switches, etc. - may be null if only one OS instance on the device)
Accessor Device OS Instance
(device = user device, server, etc.)
Copyright © 2006 Boeing. All rights reserved.
A Reference Model of the Potential Points to Place
Access Control Around Our Computers and Our Data
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
Identify user and apply
data-specific access rules
Identify user and apply
computer-access rules,
application access rules,
and/or file access rules
Data
Encryption / DRM
(may be null)
Application
(may be null)
Apply network reachability rules
Hosting OS Instance
(may be a partition or virtual machine)
Hypervisor / VMM Environment
Identify user and apply
network reachability filters
(may be null if not a partition or virtual machine)
Internal Network
(switches / routers / VLANs / packet filters / etc.)
Validate end-point configuration
before permitting connection
Perimeter & DMZ
(may be null for devices connected to internal network)
External Network
(switches / routers / VLANs / packet filters / etc.)
Accessor Device Hypervisor / VMM Environment
Discount controls within accessor device
(virtual switches, etc. - may be null if only one OS instance on the device)
(owned by a business partner) and external network Accessor Device OS Instance
we have no configuration control over these (device = user device, server, etc.)
Copyright © 2006 Boeing. All rights reserved.
Example of Mapping Internal Enclaves to the Model
Engineering, Operations & Technology | Information Technology
Internal enclaves are a security
mechanism that sequesters one
or more computers behind a barrier
mechanism, segregated from the
rest of the network.
Computing & Network Operations
Data
Encryption / DRM
(may be null)
Application
Enclaves operate by controlling
“network reachability” –
implemented within the network
(packet filters, etc.) or within the
Hosting OS (IPSec filters, etc.)
(may be null)
Hosting OS Instance
(may be a partition or virtual machine)
Hypervisor / VMM Environment
(may be null if not a partition or virtual machine)
Internal Network
(switches / routers / VLANs / packet filters / etc.)
Perimeter & DMZ
Enclaves can be a
“fortress” or a “jail”.
(may be null for devices connected to internal network)
External Network
(switches / routers / VLANs / packet filters / etc.)
Accessor Device Hypervisor / VMM Environment
We are mostly concerned
with “jail” enclaves.
Copyright © 2006 Boeing. All rights reserved.
(virtual switches, etc. - may be null if only one OS instance on the device)
Accessor Device OS Instance
(device = user device, server, etc.)
Example of Mapping a Citrix Enclave to the Model
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
Data
Encryption / DRM
(may be null)
Application
Application
(may be null)
(may be null)
Hosting OS Instance
Hosting OS Instance
(may be a partition or virtual machine)
(may be a partition or virtual machine)
Hypervisor / VMM Environment
Hypervisor / VMM Environment
(may be null if not a partition or virtual machine)
(may be null if not a partition or virtual machine)
Internal Network
(switches / routers / VLANs / packet filters / etc.)
Perimeter & DMZ
(may be null for devices connected to internal network)
External Network
(switches / routers / VLANs / packet filters / etc.)
Fortress-style server hosts data:
Accessor
Device Hypervisor / VMM Environment
Jail-style enclave hosts Citrix
server
(virtual switches, etc. - may be null if only one OS instance on
the device) OS and/or
Hardened
and limits network reachability
Accessor Device OS Instance
Hardened Application
to a hardened server (device = user device, server, etc.)
Copyright © 2006 Boeing. All rights reserved.
Discussion / Q&A
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
If the traditional perimeter goes away, where do those
control functions go – do they simply disappear, or are
they allocated to another part of the model?
• Network reachability (access zones, enclaves, etc.)
• Server hardening.
• Application hardening.
• DRM or in-transit encryption.
• Etc.
Copyright © 2006 Boeing. All rights reserved.
Mapping Your Access Controls to the Model?
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
Data
Encryption / DRM
(may be null)
The perimeter goes away, or has
much less functionality –
Application
(may be null)
Hosting OS Instance
(may be a partition or virtual machine)
Where do those functions go?
Hypervisor / VMM Environment
(may be null if not a partition or virtual machine)
Internal Network
(switches / routers / VLANs / packet filters / etc.)
Perimeter & DMZ
(may be null for devices connected to internal network)
External Network
(switches / routers / VLANs / packet filters / etc.)
Accessor Device Hypervisor / VMM Environment
(virtual switches, etc. - may be null if only one OS instance on the device)
Accessor Device OS Instance
(device = user device, server, etc.)
Copyright © 2006 Boeing. All rights reserved.
Shaping security for tomorrow’s world
Engineering, Operations & Technology | Information Technology
Computing & Network Operations
www.jerichoforum.org
Copyright © 2006 Boeing. All rights reserved.
Copyright © 2006 Boeing. All rights reserved.
Real World Application
 Data/Information Security
 Jeremy Hilton
Cardiff University
Problem
 Access to data should be controlled by
security attributes within the body of the
data itself – JFC #9
 Current access control model doesn’t scale
in a de-P environment
Why Should I care
 Electronic information sharing
 Virtual organisations
 Retain control of ‘information in the wild’
Recommended Solution/Response
 Information to be self-protecting
 Meta-data part of the body of information
 Effectively an access control policy
 User must have right of access at time of
use – each time
Background & Rationale
 De-p has happened
 JFC #11 data to be secure when stored, in
transit and in use
 Loss of centralised access control in a de-p
environment
 Rise of collaboration and virtual
organisations
 JFC #10 highlights that permissions, keys,
privileges must fall under independent
control
Challenges to the Industry
 Policy Definition Language
 Information Classification Scheme
 Access Control Infrastructure
The Way Forward
 Proposal is, in effect, an interpretation of a
DRM approach to fine-grained access
control
 BUT Jericho Forum principles require
policies, schemas & software be fully open
standards-based, freely available and
heterogeneous