The Jericho Forum’s Architecture for De-Perimeterised Security

1. The Jericho Forum’s Architecture forDe-Perimeterised Security Presentation at CACS 2007 Auckland Prof. Clark Thomborson 10th September 2007

2. What is the Jericho Forum? • The Jericho Forum is an international IT security thought-leadership group dedicated to • defining ways to deliver effective IT security solutions that will match the increasing business demands for secure IT operations in our open, Internet-driven, globally networked world. • Our members include multi-national corporate user organizations, major security vendors, solutions providers, and academics, working together to: • drive and influence development of new architectures, inter-workable technology solutions, and implementation approaches, for securing our de-perimeterizing world • support development of open standards that will underpin these technology solutions. • See http://www.jerichoforum.org/

3. Structural View • User members are large corporations (e.g. Boeing) and governmental agencies (e.g. UK Foreign & Commonwealth Office), who • own the Forum; • vote on the deliverables; and • run the Board of Managers. • Vendor members (e.g. Symantec) • have no votes; and • participate fully in discussions. • We now have 12 vendor members. We want more. • Academic members (e.g. me) • offer expertise in exchange for information of interest. (Note: academics trade in ideas, not $$ ;-)

4. Some Members of Jericho http://www.jerichoforum.org/

5. Jericho’s De-perimeterised Security • Observation: we drill holes through all our firewalls! • A corporate perimeter defines a quality-of-service (QoS) boundary, not a security boundary. • We are hardening our platforms, and our data objects, so that we can take advantage of the high connectivity and low cost of the internet. • We can make trustworthy connections on an untrusted network, if we have a way to identify trustworthy communication partners. • Our systems should use open standards, to allow interoperability, integration, and assurance.

6. Don’t we still need perimeters? • Of course! Security is not defined without a perimeter. • We put our valuables inside the perimeter. • We (try to) keep the “bad guys” out. • We (try to) allow the “good guys” in. • The Jericho Forum is focussed on defining what we want: a “collaboration-oriented architecture”. • We don’t care to argue about terminology, e.g. “de-perimeterisation” vs. “re-perimeterisation”.

7. Collaboration Oriented Architecture • According to Wikipedia (since early July 07), • “Collaboration Oriented Architecture is the ability to collaborate between systems that are based on the Jericho Forum principles or ‘Commandments’... • “The term Collaboration Oriented Architecture was defined and developed in a meeting of the Jericho Forum at a meeting held at HSBC on the 6th July 2007.”

8. The Jericho Commandments: Fundamentals (1-3) • The scope and level of protection must be specific and appropriate to the asset at risk. • Security mechanisms must be pervasive, simple, scalable, and easy to manage. • Assume context at your peril: security solutions designed for one environment may not be transferable. My analysis: • The first two commandments are “motherhood and apple pie” – nobody will argue against them, but we can’t take them for granted! • The third commandment reminds us that there will be more than one possible implementation of a system’s functional goals, depending on its security goals.

9. Surviving in a Hostile World • Devices and applications must communicate using open, secure protocols. • All devices must be capable of maintaining their security policy on an untrusted network. My analysis: • Using HTTPS (or AS2) is a better idea, for interoperability, than using a proprietary communications protocol. • Untrusted networks are cheap and omnipresent – let’s take advantage of this! • Admission control on a trusted network is very expensive, except in situations where new or changed devices are very rarely supposed to be admitted.

10. The Need for Trust • All people, processes, technology must have declared and transparent levels of trust for any transaction to take place. • Mutual trust assurance levels must be determinable. My analysis: • Static security requirements (for data) • Confidentiality, Integrity, Availability • Dynamic security requirements (for systems): • Authentication, Authorisation, Audit (the gold standard); • Identification, Trust assessment (for connections between systems, and between systems and users).

11. Identity, Management and Federation • Authentication, authorisation and accountability must interoperate out of your area of control. My analysis (in the context of content management): • Digital Rights Management (DRM) is confidentiality control for licensed end-users • Enterprise Content Management (ECM) is confidentiality and integrity control within an enterprise • Perhaps ... Inter-Enterprise Content Management (IECM) will provide confidentiality, integrity, and dynamic security control between enterprises. • I believe technology (even with open standards) won’t suffice, we’ll also need audits and contracts.

12. Access to Data • Access to data should be controlled by security attributes of the data itself. • Data privacy (and security of any asset of sufficiently high value) requires a segregation of duties/privileges. • By default, data must be appropriately secured when stored, in transit and in use. My analysis (in the context of content management) • IECM systems should have per-document metadata or licenses, and not rely on access-control lists. • Our workflow systems must be integrated with our IECM systems; our workplace roles are more important than our individual identities when making security decisions. • #11 is surprisingly hard to achieve on a contemporary laptop.

13. Jericho’s Position Papers • We have published 13 position papers (at last count). • A typical position paper is four pages long, with four sections: • defining a key problem in a technology, such as VoIP, • answering the question “why should I care ... what are the consequences if I don't?” • giving a recommendation or solution, and • providing a background or rationale.

14. Jericho’s Position Paper on EIP&C • Enterprise Information Protection & Control requirements: • Key escrow and key management; • User identity and the management of users outside your domain; • End-point security must be assessed before access is allowed; • Data should be classified, typically by the originator, including temporal conditions (destruction, release); • Auditing of rights information; segregation of duties. • “Current EIP&C solutions are proprietary, limiting their applications by enterprise domain, operating system family or to specific applications.”

15. Jericho’s Challenges for EIP&C • We want a standard client interface/software, • because it is undesirable and unlikely that any corporation can mandate that another company install and manage their preferred EIP&C solution. • We want a standard set of agreed EIP&C classifications. • We want an open, inherently secure protocol for consumers of EIP&C protected data to communicate with the server or enterprise which controls the data’s EIP&C attributes.

16. Our Vision • To enable business confidence for collaboration and commerce beyond the constraint of the corporate, government, academic, and home office perimeter, principally through: • Cross-organizational security processes and services • Products that conform to open security standards and profiles (collections of logically related standards that make up a useful functional entity) • Assurance processes that, when used in one organization, can be trusted by others. • Do you think our vision is feasible? Desirable? • Do you want to join the Jericho Forum? • jerichoforum-interest@opengroup.org • http://www.jerichoforum.org/