Welcome

1. Welcome Jericho Forum Meeting 21-22 September 2006 Hosted by The Boeing Corporation Seattle, WA., USA www.jerichoforum.org

2. What we covered on Thursday • Our de-perimeterized environment - responding to the challenge (Stephen Whitlock, Boeing) • Client machines (Chandler Howell, Motorola) • Network controls (Carl Bunje, Boeing) • Application/server (Conrad Kimball, Boeing) • Data/Information Security (Jeremy Hilton, Cardiff University)

3. Agenda – Friday September 22 • 09.00: Introductions & Overview (Ian Dobson, The Open Group) • 09.10: Opening Keynote (Ben Norton, Boeing) • 09.30: The Commandments (Jeremy Hilton, Cardiff University) • 10.30: Break • 11.00: Position Papers: overview, highlights in selected papers (Stephen Whitlock, Boeing) • 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

4. Setting the Foundations • The Jericho Forum “Commandments” • Jeremy HiltonCardiff University

5. I have ten commandments. The first nine are, thou shalt not bore. The tenth is, thou shalt have right of final cut.

6. Rationale • Jericho Forum in a nutshell: “Your security perimeters are disappearing: what are you going to do about it?” • Need to express what / why / how to do it in high level terms (but allowing for detail) • Need to be able to draw distinctions between ‘good’ security (e.g. ‘principle of least privilege’) and ‘de-perimeterisation security’ (e.g. ‘end-to-end principle’)

7. Why should I care? • De-perimeterisation is a disruptive change • There is a huge variety of: • Starting points / business imperatives • Technology dependencies / evolution • Appetite for change / ability to mobilise • Extent of de-perimeterisation that makes business sense / ability to influence • So we need rules-of-thumb, not a ‘bible’ • “A benchmark by which concepts, solutions, standards and systems can be assessed and measured.” Business Strategy IT Strategyand Planning PortfolioManagement ResourceManagement SolutionDelivery ServiceManagement AssetManagement

8. Structure of the Commandments • Fundamentals (3) • Surviving in a hostile world (2) • The need for trust (2) • Identity, management and federation (1) • Access to data (3)

9. Fundamentals 1. The scope and level of protection must be specific and appropriate to the asset at risk. • Business demands that security enables business agility and is cost effective. • Whereas boundary firewalls may continue to provide basic network protection, individual systems and data will need to be capable of protecting themselves. • In general, it’s easier to protect an asset the closer protection is provided.

10. Fundamentals 2. Security mechanisms must be pervasive, simple, scalable and easy to manage. • Unnecessary complexity is a threat to good security. • Coherent security principles are required which span all tiers of the architecture. • Security mechanisms must scale: • from small objects to large objects. • To be both simple and scalable, interoperable security “building blocks” need to be capable of being combined to provide the required security mechanisms.

11. Fundamentals 3. Assume context at your peril. • Security solutions designed for one environment may not be transferable to work in another: • thus it is important to understand the limitations of any security solution. • Problems, limitations and issues can come from a variety of sources, including: • Geographic • Legal • Technical • Acceptability of risk, etc.

12. Surviving in a hostile world 4. Devices and applications must communicate using open, secure protocols. • Security through obscurity is a flawed assumption • secure protocols demand open peer review to provide robust assessment and thus wide acceptance and use. • The security requirements of confidentiality, integrity and availability (reliability) should be assessed and built in to protocols as appropriate, not added on. • Encrypted encapsulation should only be used when appropriate and does not solve everything.

13. Surviving in a hostile world 5. All devices must be capable of maintaining their security policy on an untrusted network. • A “security policy” defines the rules with regard to the protection of the asset. • Rules must be complete with respect to an arbitrary context. • Any implementation must be capable of surviving on the raw Internet, e.g., will not break on any input.

14. The need for trust 6. All people, processes, technology must have declared and transparent levels of trust for any transaction to take place. • There must be clarity of expectation with all parties understanding the levels of trust. • Trust models must encompass people/organisations and devices/infrastructure. • Trust level may vary by location, transaction type, user role and transactional risk.

15. The need for trust 7. Mutual trust assurance levels must be determinable. • Devices and users must be capable of appropriate levels of (mutual) authentication for accessing systems and data. • Authentication and authorisation frameworks must support the trust model.

16. Identity, Management and Federation 8. Authentication, authorisation and accountability must interoperate/ exchange outside of your locus/ area of control. • People/systems must be able to manage permissions of resources they don't control. • There must be capability of trusting an organisation, which can authenticate individuals or groups, thus eliminating the need to create separate identities. • In principle, only one instance of person / system / identity may exist, but privacy necessitates the support for multiple instances, or once instance with multiple facets. • Systems must be able to pass on security credentials/assertions. • Multiple loci (areas) of control must be supported.

17. Finally, access to data 9. Access to data should be controlled by security attributes of the data itself. • Attributes can be held within the data (DRM/Metadata) or could be a separate system. • Access / security could be implemented by encryption. • Some data may have “public, non-confidential” attributes. • Access and access rights have a temporal component.

18. Finally, access to data 10. Data privacy (and security of any asset of sufficiently high value) requires a segregation of duties/privileges • Permissions, keys, privileges etc. must ultimately fall under independent control • or there will always be a weakest link at the top of the chain of trust. • Administrator access must also be subject to these controls.

19. Finally, access to data 11. By default, data must be appropriately secured both in storage and in transit. • Removing the default must be a conscious act. • High security should not be enforced for everything: • “appropriate” implies varying levels with potentially some data not secured at all.

20. Desired Future State Vendors Customers Standards and Solutions Consequences … is that it? Continuum Work Types Needs Principles Strategy White Papers Patterns Use Cases Guidelines Standards Solutions Jericho Forum Standards Groups

21. Cecil B. DeMille 1881-1959 Consequences…is that it? • We may formulate (a few) further Commandments … and refine what we have … based on • Your feedback (greatly encouraged) • Position papers (next level of detail) • Taxonomy work • Experience • Today’s roadmap session will discuss where we go from here What I have crossed out I didn't like. What I haven't crossed out I'm dissatisfied with.

22. Paper available from the Jericho Forum • The Jericho Forum “Commandments” are freely available from the Jericho Forum Website http://www.jerichoforum.org

23. Jericho Forum Papers • Steve WhitlockThe Jericho Forum Board

24. Jericho Forum Papers • 2-4 pages • Sections • Problem statement • Why do I care? • Recommendation / Solution • Background argument / rationale • Example

25. Published Papers • Commandments • Secure Protocols • Wireless • VOIP • Internet Filtering & Reporting • DRM • Endpoint Security • Architecture

26. Paper available from the Jericho Forum • The Jericho Forum “Commandments” are freely available from the Jericho Forum Website http://www.jerichoforum.org

27. “Commandments” - Rationale • Jericho Forum in a nutshell: “Your security perimeters are disappearing: what are you going to do about it?” • Need to express what / why / how to do it in high level terms (but allowing for detail) • Need to be able to draw distinctions between ‘good’ security (e.g. ‘principle of least privilege’) and ‘de-perimeterisation security’ (e.g. ‘end-to-end principle’)

28. Why should I care? • De-perimeterisation is a disruptive change • There is a huge variety of: • Starting points / business imperatives • Technology dependencies / evolution • Appetite for change / ability to mobilise • Extent of de-perimeterisation that makes business sense / ability to influence • So we need rules-of-thumb, not a ‘bible’ • “A benchmark by which concepts, solutions, standards and systems can be assessed and measured.”

29. Paper available from the Jericho Forum • The Jericho Forum Position Paper “The need for Inherently Secure Protocols” is freely available from the Jericho Forum website http://www.jerichoforum.org

30. Problem • In the real world nearly every enterprise; • Uses computers regularly connected to the Internet; Web connections, E-mail, IM etc. • Employing wireless communications internally • The majority of their users connecting to services outside the enterprise perimeter • In this de-perimeterised world the use of inherently secure protocols is essential to provide protection from the insecure data transport environment.

31. Why should I care? • The Internet is insecure, and always will be • It doesn’t matter what infrastructure you have, it is inherently insecure • However, enterprises now wish; • Direct application to application integration • To support just-in-time delivery • To continue to use the Internet as the basic transport medium. • Secure protocols should act as fundamental building blocks for secure distributed systems • Adaptable to the needs of applications • While adhering to requirements for security, trust and performance.

32. Protocol Security & Attributes • Protocols used should have the appropriate level of data security, and authentication • The use of a protective security wrapper (or shell) around an application protocol may be applicable; • However the use of an encrypted tunnel negates most inspection and protection and should be avoided in the long term.

33. Secure “out of the box” • An inherently secure protocol is; • Authenticated • Protected against unauthorised reading/writing • Has guaranteed integrity • For inherently secure protocols to be adopted then it is essential that; • Systems start being delivered preferably only supporting inherently secure protocols; or • With the inherently secure protocols as the default option

34. Good & Bad Protocols

35. Paper available from the Jericho Forum • The Jericho Forum Position Paper “Wireless in a de-perimeterised world” is freely available from the Jericho Forum website http://www.jerichoforum.org

36. Blinkenlights? Photo: Dorit Günter, Nadja Hannaske • Play <Pong> with mobile phone!

37. Corporate laptops Use 802.11i (WPA2) Secure authenticated connection to LAN Device + user credentials Simple? Servers LAN AD Radius Corporate Secure wireless connection to LAN

38. But also… Audio-visual controllers Wi-Fi phones Servers LAN AD Radius Corporate AV Not just laptops

39. Servers Internet LAN AD Radius Secure Insecure Guest Corporate AV Guest internet access too • Mixed traffic • Trusted or untrusted? • How segregated?

40. VPN Servers 7491 7491 Internet LAN AD Radius Secure Costbucks coffee Insecure Guest Corporate AV Laptops also used at home or in café

41. Servers Internet LAN AD QoS gate USB USB USB Secure application protocols Common authentication Inter-network roaming Costbucks coffee Guest Corporate AV Jericho visions

42. Wireless (Wi-Fi) • Companies should regard wireless security on the air-interface as a stop-gap measure until inherently secure protocols are widely available • The use of 802.1x integration to corporate authentication mechanisms should be the out-of the box default for all Wi-Fi infrastructure • Companies should adopt an “any-IP address, anytime, anywhere” (what Europeans refer to as a “Martini-model”) approach to remote and wireless connectivity. • Provision of full roaming mobility solutions that allow seamless transition between connection providers

43. Paper available from the Jericho Forum • The Jericho Forum Position Paper “VoIP in a de-perimeterised world” is freely available from the Jericho Forum website http://www.jerichoforum.org

44. The Business View of VoIP • It’s cheap? • Cost of phones • Cost of “support” • Impact on internal network bandwidth • It’s easy? • Can you rely on it? • Can you guarantee toll-bypass? • It’s sexy? • Desktop video

45. The IT View of VoIP • How do I manage bandwidth? • QoS, CoS • How can I support it? • More stretch on a shrinking resource • What happens if I lose the network? • I used to be able to trade on the phone • How can I manage expectations? • Lots of hype; lots of “sexy”, unused/unusable tricks • Can I make it secure??

46. The Reality of VoIP • Not all VoIPs are equal! • Internal VoIP • Restricted to your private address space • Equivalent to bandwidth diversion • External VoIP • Expensive, integrated into PBX systems • “Free” (external) VoIP (eg Skype) • Spreads (voice) data anywhere • Ignores network boundary • Uses proprietary protocols – at least for security

47. Flawed assumption that voice & data sharing same infrastructure is acceptable because internal network is secure (isn’t it?) Therefore little or no security built-in Internal VoIP Security entirely dependent on internal network Very poor authentication External VoIP Some proprietary security, even Skype Still poor authentication BUT, new insecurities The Security Problem

48. Recommended Solution/Response • STANDARDISATION! • Allow diversity of phones (software, hardware), infrastructure components, infrastructure management, etc • MATURITY of security! • All necessary functionality • Open secure protocol • Eg crypto • Eg IP stack protection

49. Secure “Out of the Box” • Challenge is secure VoIP without boundaries • Therefore… • All components must be secure out of box • Must be capable of withstanding attack • “Phones” must be remotely & securely maintained • Must have strong (flexible) mutual authentication • “Phones” must filter/ignore extraneous protocols • Protocol must allow for “phone” security mgt • Must allow for (flexible) data encryption • Must allow for IP stack identification & protection

50. Challenges to the industry • If inherently secure VoIP protocols are to become adopted as standards then they must be open and interoperable • The Jericho Forum believes that companies should pledge support for moving from proprietary VoIP protocols to fully open, royalty free, and documented standards • The secure VoIP protocol should be released under a suitable open source or GPL arrangement. • The Jericho Forum hopes that all companies will review its products and the protocols and move swiftly to replacing the use of inherently secure VoIP protocols. • End users should demand that VoIP protocols should be inherently secure • End users should demand that VoIP protocols used should be fully open