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

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

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 $$ ;-)

Some Members of Jericho

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.

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”.

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 6 th July 2007.”

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.

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.

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).

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.

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.

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.

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.”

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.

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?