1. Jericho une approche alternative de la sécurité Bjorn Gronquist (CSO Capgemini) Lyon – 26 novembre 2009 XIVe Symposium de l’Architecture du 16 au 26 novembre 2009

2. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 1 Introduction  Why does traditional security guys say NO ? Because conventional security is wedded to an outdated industrial model of security.  Jericho Forum: User group that publicises de-perimeterisation and its consequences NOT a standards body Affiliated to the Open Group as a hosted forum Capgemini has board level representation

3. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 2 PART I: Jericho versus Conventional Security The Jericho Forum is a user forum created as a reaction to conventional security approaches To understand Jericho style security we must first understand what the Jericho Forum is reacting to That is the topic of this first presentation: Conventional Security and What’s Wrong with it

4. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 3 The Industrial Security Model  Assets are held within a Perimeter.  Users must enter the perimeter to access the assets.  The perimeter is guarded by a gatehouse  The gate house has a list of the people with access  Employees are the good guys; everyone else must be kept out  Changes to the perimeter, the gate house or the employees are rare  The workers go into the factory once per day

5. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 4 Examples MechanismPerimeterAssetPolicy LockBoxWhat’s in the box Who has the key Guard houseFenceThe site within the fence Who is on the security guard’s list FirewallPerimeterised computer network Information and applications attached to the network The packet filtering configurations on the firewall

6. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 5 Modern Business Trends  User Mobility Users aren’t in a perimeter  Business Agility Physical and organisational perimeters aren’t stable Business processes change constantly  SaaS and Cloud Computing Assets aren’t in a perimeter De-perimeterisation

7. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 6 Perimeterised Security hypothesis versus real world Assets inside the perimeter is guarded by a gatehouse Assets outside the perimeter aren’t protected by a gatehouse on the perimeter Users must enter the perimeter to access the assets. Users need to access assets from anywhere The gate house has a simple list of the people with access Access policies are rich and complex Employees are the good guys; everyone else must be kept out Suppliers and customers need access; employees constitute a potential threat Rare Changes to the perimeter, the gate house or the employees Mergers, de-mergers, joint ventures, shared services are the norm; legislation changes constantly The workers go into the factory once per dayWorkers access an asset once a minute Single business owner sets the access policy for its assets Many different parties have a stake in an information asset Processes are simple and repeatableProcesses are complex and unique

8. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 7 Perimeter based security is outdated  What you forget when you think in terms of perimeter: Laptops outside of the office, new devices (Iphone, USB keys etc…) Guests in you office Social networking activities Cooperation (IM, email) Software as a service Cloud computing  The work condition evolves The Intranet becomes the Internet The work station becomes the Web browser Business process becomes Collaboration

9. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 8 Consequences of the Mismatch  Security is costly Security maintenance is work intensive Business and technical change are complex Difficult to take advantage of new opportunities like cloud computing Difficult to provide access to customers, suppliers and contractors  Assets aren’t properly protected Security does not meet anymore social and legal requirements Lack of partner confidence Frequent security breaches (bypasses of security)

10. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 9 PART 2: Collaboration Oriented Architecture The Jericho Forum has proposed the Collaboration Oriented Architecture (COA) as its response to de-perimeterisation COA unites business, IT and risk management. It defines many new concepts. COA is the topic of this second presentation: Collaboration Oriented Architecture

11. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 10 The Collaboration Oriented Architecture (COA)  Collaborations between different people & services based on Trust Reputation Identity  Examples Surfing, Chatting, Shopping, etc.. Social networking, Emailing, Reporting, Purchasing, etc..  Privacy

12. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 11 The Collaboration Oriented Architecture (COA)  Principles: Collaboration is the basic unit of security Security based on “risk management” and shall be “transparent to users” Parties, Risks, Identities, Devices and Collaborations all have lifecycles that must be able to pass organisational boundaries transparently and securely

13. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 12 Trusted network Network Access Insiders theft Application vulnerabilities Compliance Residual risks Security Review Model.ppt Page 12 Firewall Content filtering VPN Internet & Partners Perimeter style security IPS

14. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 13 End Point Protection Trust monitor Risk assessment Identity federation Encrypted data transmission Deperimeterized network Page 13 Service Protection Cloud Security Jericho Style Security

15. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 14 Collaborations  The Collaboration generalises concepts of contract and organisation  It comprises Parties that co-operate for a common goal (these can be people, devices or collaborations) Rules governing their interaction (one or more contracts) A redress mechanism to handle non-performance by any party  A collaboration membership has a lifecycle Need Identified Start Potential Collaboration Identified Search Collaboration Agreed Negotiate Terminate FulfilmentTerminated

16. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 15 Trust  Collaborations often have a ‘relying party’ I pay now for my CD and I rely upon Amazon to deliver the CD later  Why are relying parties willing to rely? Because they trust the counterparty Because a redress mechanism is available  Trust means The trusted party has the necessary competence, skills and resources to collaborate The trusted party is well disposed towards the relying party It is in the trusted party’s best interests to collaborate

17. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 16 Reputation  Collaboration Parties want to reduce the risk of their collaborations by choosing good counterparties They need information about other parties before agreeing to collaborate with them  This information is called Reputation and comprises Certifications and Qualifications Criminal Record and Credit History Collaboration History References and Testimonials  Reputation A party’s reputation affects the collaborations it can enter into

18. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 17 The Trust Lifecycle Security Activities

19. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 18 Identity  A party’s identity comprises Reputation (used when agreeing collaborations) Agreed collaborations (used when fulfilling collaborations) These have different uses and different security requirements  Important security decisions Agreeing to collaborate in the basis of reputation Handling resource access requests, or provisioning, on the basis of identity (collaborations + reputation) Updating reputations on the basis of performance in collaborations

20. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 19 Examples  Buy a CD from Amazon.com A short term low risk collaboration  Search phase – Google or Amazon search  Negotiate phase – shopping card  Fulfilment – payment and delivery Reputation – amazon.com site certificate Contract – recorded internally by Amazon  Employment A long term medium risk collaboration  Search phase – monster.com, head-hunter  Negotiate phase – interviews  Fulfilment – A sequence of tasks directed by management, each of which is like a sub- collaboration Reputation – references, qualifications, word of mouth, appraisals, (linkedin.com) Contract – recorded in HR system, user directory

21. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 20 Conclusion: Challenges for COA  Collaboration contracts are recorded in different places: Procurement documentation User directories Financial accounts HR systems  Reputation is little understood at this time: Little automation Not widely recognised as a business process Often one very poorly

22. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 21 Thank You

23. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 22 - You experience - Thriving on Data - Sector as a Service - Process on the Fly - Invisible Infostructure - From Transaction to Interaction Technovision 2012 Clusters

24. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 23 About the Jericho Forum  A user group that publicises de-perimeterisation and its consequences NOT a standards body Affiliated to the Open Group as a hosted forum Capgemini has board level representation on the Forum and has contributed significantly to it.  The Jericho Forum advocates COA The Jericho Forum acknowledges de-perimeterisation

25. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 24 Jericho is based on 11 commandments The scope and level of protection should be specific & 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 Security mechanisms must be pervasive, simple, scalable & 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 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 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. Page 24

26. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 25 Jericho is based on 11 commandments 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. 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. 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 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 All people, processes, technology must have declared and transparent levels of trust for any transaction to take place Trust in this context is establishing understanding between contracting parties to conduct a transaction and the obligations this assigns on each party involved Trust models must encompass people/organizations and devices/infrastructure Trust level may vary by location, transaction type, user role and transactional risk Trust in this context is establishing understanding between contracting parties to conduct a transaction and the obligations this assigns on each party involved Trust models must encompass people/organizations and devices/infrastructure Trust level may vary by location, transaction type, user role and transactional risk Page 25

27. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 26 Jericho is based on 11 commandments 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 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 Authentication, authorization and accountability must interoperate / exchange outside of your locus / area of control People/systems must be able to manage permissions of resources and rights of users 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 People/systems must be able to manage permissions of resources and rights of users 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 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 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 Page 26

28. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 27 Jericho is based on 11 commandments 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 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 By default, data must be appropriately secured when stored, in transit and in use 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 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 Page 27

29. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 28 “The Forum is dedicated to the idea that success in today’s business environment is dependant upon the ability to collaborate and do business by enabling the secure flow of data over the Internet. But today’s business requirement for the flow of data between mobile workforces, customers, suppliers and business partners, has eroded the ability of traditional perimeter security solutions to protect our systems. To enable business to embrace the Internet while protecting valuable company information, new security models are needed to address this challenge.” “De-perimeterization has happened, is happening and is inevitable; central protection is decreasing in effectiveness” www.opengroup.org/jericho

30. XIVe Symposium de l’Architecture Du 16 au 26 novembre 2009 - Page - 29 Arial 24