Jericho une approche alternative de la s - PowerPoint PPT Presentation

About This Presentation
Title:

Jericho une approche alternative de la s

Description:

Difficult to provide access to customers, suppliers and contractors ... to provide basic network protection, individual systems and data will need to be ... – PowerPoint PPT presentation

Number of Views:91
Avg rating:3.0/5.0
Slides: 31
Provided by: architects
Category:

less

Transcript and Presenter's Notes

Title: Jericho une approche alternative de la s


1
Jericho une approche alternative de la
sécuritéBjorn Gronquist (CSO Capgemini)Lyon
26 novembre 2009
  • XIVe Symposium de lArchitecture
  • du 16 au 26 novembre 2009

2
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
PART I Jericho versus Conventional Security
4
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
Examples
Mechanism Perimeter Asset Policy
Lock Box Whats in the box Who has the key
Guard house Fence The site within the fence Who is on the security guards list
Firewall Perimeterised computer network Information and applications attached to the network The packet filtering configurations on the firewall
6
Modern Business Trends
  • User Mobility
  • Users arent in a perimeter
  • Business Agility
  • Physical and organisational perimeters arent
    stable
  • Business processes change constantly
  • SaaS and Cloud Computing
  • Assets arent in a perimeter

De-perimeterisation
7
Perimeterised Security hypothesis versus real
world
Assets inside the perimeter is guarded by a gatehouse Assets outside the perimeter arent 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 day Workers 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 repeatable Processes are complex and unique
8
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
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 arent properly protected
  • Security does not meet anymore social and legal
    requirements
  • Lack of partner confidence
  • Frequent security breaches (bypasses of security)

10
PART 2 Collaboration Oriented Architecture
11
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

Right level of security
12
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

Change of paradigm
13
Perimeter style security
Trusted network
Internet Partners
IPS
Firewall Content filtering VPN
Residual risks

Insiders theft Application vulnerabilities Complia
nce
Network Access
Security Review Model.ppt
Page 12
14
Jericho Style Security
Service Protection
Deperimeterized network
Cloud Security
Encrypted data transmission
End Point Protection
Identity federation
Trust monitor
Risk assessment
Page 13
15
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

16
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 partys best interests to
    collaborate

17
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 partys reputation affects the collaborations
    it can enter into

18
The Trust Lifecycle
Trust based security
Security Activities
19
Identity
  • A partys 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
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
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
Thank You
23
Technovision 2012 Clusters
24
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
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, its 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

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

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

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

Page 25
27
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

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

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

Page 26
28
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

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

Page 27
29
The Forum is dedicated to the idea that success
in todays business environment is dependant upon
the ability to collaborate and do business by
enabling the secure flow of data over the
Internet. But todays 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
Arial 24
Write a Comment
User Comments (0)
About PowerShow.com