Jericho’s Architecture for De-Perimeterised Security

1. Jericho’s Architecture forDe-Perimeterised Security Presentation at ISACA/IIA Wellington Prof. Clark Thomborson 27th July 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.opengroup.org/jericho/

3. Structural View • User members are large corporations and some governmental agencies, who • own the Forum; • vote on the deliverables; and • run the Board of Managers. • Vendor members • have no votes; and • participate fully in discussions. • We now have 12 vendor members. We want more. • Academic members • 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 we do. Security can’t be defined without a perimeter. • We put our valuables inside the perimeter. • We try to keep the “bad guys” out. • We allow the “good guys” in. • So... de-perimeterisation could be renamed re-perimeterisation... • Hmm... why not focus on the positive? • We could define what we want, rather than try to describe the process of change... • We want... a collaboration-oriented architecture!

7. Collaboration Oriented Architecture • According to Wikipedia, • 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, in the context of ECM: • The first two commandments are appropriate design goals for any secure system, including my vapourware browser-based ECM. • The third commandment reminds us that there will be more than one implementation of ECM, with differing levels of hardness. We’ll need help with our bridges between ECMs!

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. Application / analysis: • Using HTTPS (or AS2) is a better idea, for interoperability, than using a proprietary ECM system without a standardised bridging protocol. • Untrusted networks are cheap and omnipresent – let’s take advantage of this! • Trusted networks are very expensive, and will prevent us from making type-2 and type-3 bridges.

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. • These state “dynamic security” requirements for bridge creation. • Decision support, for bridge-builders, will take the form of an interoperable reputation management system which gives us relevant information on individuals and organisations (and of their computers and certificates). • We also want a trust management system to record our trusting decisions, and to help us re-evaluate our posture when new information arises. • The certificate store in our web browser is a rudimentary trust management system. (Do you know how to use it?) • These also state requirements on the use of an established bridge. • For example, a company-confidential data object should not be transmitted over a bridge to an individual/organisation which is not trusted to respect confidentiality.

11. Identity, Management and Federation • Authentication, authorisation and accountability must interoperate out of your area of control. • My vapourware ECM keeps track of “bridges” but doesn’t attempt to restrict their use. • What document-level control can be exerted, at reasonable cost? • Intracorporate workflow systems are affordable and appropriate, when large workforces (e.g. bureaucracies) handle repetitive data-processing tasks. These are type-1 bridges. • Intercorporate workflow systems are very expensive and inflexible, implying that remote control (= strong DRM) across type-2 and type-3 bridges is infeasible. • I think we must insist on periodic ECM-compliance audits of our bridging partners, if we want to detect and respond to possible violations of our remotely-enforced confidentiality policies.

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. Analysis / Application • ECM systems should use document metadata to describe access rights, not separate licenses or access-control lists. • Our computers don’t (yet) give us much assistance in managing our segregated data: this is a type-0 bridge, between two personae of the same individual! • ECM systems should encrypt confidential documents, and they should digitally sign all documents (for authenticity); these crypto-operations should be done as close as possible to the point of use.

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.opengroup.org/jericho/