IT Audit & Identity Management Challenges in a De-perimeterisation Scenario

IT Audit & Identity Management Challenges in a De-perimeterisation Scenario Henry S. Teng, CISSP, CISM Enterprise Security Compliance OfficerPhilips International B.V. & Jericho Forum Board March 27, 2007 London, UK 2nd Annual Identity Management Summit 2007 By MIS Training

Agenda • De-perimeterisation primer • Challenges to Identity Management • Challenges to IT Audit

Once upon a time…. Perimeterised Protection

and we have to prepare for the future Business Demands Differently

The Reality of “Castles” It’s fundamentally acceptance that: • Most exploits will easily transit perimeter security • We let through e-mail • We let through web • We will need to let through VoIP • We let through encrypted traffic (SSL, SMTP-TLS, VPN) • We have multiple “partner” connections • Business demand fast inter-company connectivity

Why the Jericho Forum? • No one else was discussing the problem in January 2004 • Everyone was fixated on perimeter based designs • Somebody needed to point out the “Kings new clothes” to the world • Someone needed to start the discussion What’s in it for us? • We need Security Solutions that support de-perimeterisation – so we aim to stimulate a market for solutions tode-perimeterisation problems • We want these solutions to use open standards, to improve interoperability and integration, both within our own IT systems and with our business partners

The RSA Conference 2007 Confirms At the keynote speech in February, Craig Mundie, the chief research & strategy officer for Microsoft, told the attendees: "It is sort of like we have been in the medieval age of computer networking and access… we have to build more and more fortress-like protections…" "What we didn't really see coming yet is essentially the airplane and the air–to-surface missile and other things. The threat model is changing in fundamental ways.“ (Based on transcript from Microsoft PressPass at www.microsoft.com/presspass)

So what is its effect? • Your border is effectively a QoS Boundary • Protection has little/no benefit at the perimeter • It’s easier to protect data the closer we get to it • A hardened perimeter strategy is at odds with current and/or future business needs • A hardened perimeter strategy is un-sustainable.

So what is it actually? It’s a concept: • It’s how we solve the business needs for our businesses without a hardened perimeter, • It’s how businesses leverage new opportunities when there is no hardened perimeter, • It’s a set of solutions within a framework that we can pick and mix from, • It’s defence in depth, • It’s business-driven security solutions It is not a single solution – it’s a way of thinking . . .

The Jericho ForumCharter & Remit The Jericho Forum AIMS . . . • to drive and influence the discussion / change the mindset • to demonstrate how de-perimeterised solutions can work in the corporate space • to refine and distinguish between what are Jericho Forum architectural principals vs. good secure design • to build on the work in the published Visioning Document • to define key items aligned with messages that make them specifically part of the Jericho Forum solutions space • to clarify that there is not just one “Jericho Forum solution”The Jericho Forum IS NOT . . . • another standards body • a cartel – this is not about buying a single solution • here to compete with or dismantle existing “good security”.

Foreign & Commonwealth Office Cabinet Office Some of our members

“Commandments” - Rationale • Jericho Forum in a nutshell: “Your security perimeters are disappearing: what are you going to do about it?” • Need to express what / why / how to do it in high level terms (but allowing for detail) • Need to be able to draw distinctions between ‘good’ security (e.g. ‘principle of least privilege’) and ‘de-perimeterisation security’ (e.g. ‘end-to-end principle’)

Why should I care? • De-perimeterisation is a disruptive change • There is a huge variety of: • Starting points / business imperatives • Technology dependencies / evolution • Appetite for change / ability to mobilise • Extent of de-perimeterisation that makes business sense / ability to influence • So we need rules-of-thumb, not a ‘bible’ • “A benchmark by which concepts, solutions, standards and systems can be assessed and measured.”

Structure of the Commandments • Fundamentals (3) • Surviving in a hostile world (2) • The need for trust (2) • Identity, management and federation (1) • Access to data (3)

Fundamentals 1. The scope and level of protection must be specific and 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.

Fundamentals 2. Security mechanisms must be pervasive, simple, scalable and 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.

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

Surviving in a hostile world 4. 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.

Surviving in a hostile world 5. 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.

The need for trust 6. All people, processes, technology must have declared and transparent levels of trust for any transaction to take place. • There must be clarity of expectation with all parties understanding the levels of trust. • Trust models must encompass people/organisations and devices/infrastructure. • Trust level may vary by location, transaction type, user role and transactional risk.

The need for trust 7. 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.

Finally, access to data 9. 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.

Finally, access to data 10. 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.

Finally, access to data 11. By default, data must be appropriately secured both in storage and in transit. • 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.

Identity, Management and Federation 8. Authentication, authorisation and accountability must interoperate/ exchange outside of your locus/ area of control. • People/systems must be able to manage permissions of resources 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.

Position on Federated Identity Problem • Identity provider requires to be a privileged position. • User credentials are combined with user attributes, that would lead to privacy issues. Jericho Forum Response • No requirement for a privileged Identity Provider. • Support for different credentials and authentication technology referring to the same individual. • Clear distinction between credentials and attributes in use of data.

Position on Federated Identity (cont.) Challenges to the Industry • Create common schemas for the majority of transaction data attributes requested, including name, address and payment details, to remove the need for centralised attribute storage. • Mutual authentication should be used by default. • Peer-to-peer authentication should be permitted, without the need of a privileged identity provider. • The currently assumed role of an individual should be made explicit to systems. • Subject attributes should not be used as credentials. • Credentials and authorisation information should be able to be transferred between organisations using open protocols and standards, and be simple to manage the equivalence relationships. • It should be possible to support a multiplicity of credentials and technologies for an individual.

Proposal on IT Audit Position Paper • To understand and assess the strategic impact of the Jericho Forum de-perimeterization initiative to the principles of IT Audit from an industry standard perspective. • To understand and assess the tactical impact of the Jericho Forum de-perimeterization initiative to the specific practice of IT Audit from a security community perspective. • To prescribe risk-based solutions to minimize the strategic and tactical impacts to the IT Audit community including but not limited to best practice guidelines, checklists, and technical solutions.

Fundamental Questions to Ask • With a fundamental change of the security perimeter protection model, does this change require a strategic change of the prevalent IT Audit framework? • From an IT Audit practice perspective, can the tactical/operational control aspects of IT audit scale to meet the Jericho Forum challenges?

Approach in Assessment

Phase 1 - IT Audit Strategic Focus The primary focus of Phase 1 is to assess and document the impact of the Jericho Forum 11 Commandments against prevalent (IT) control frameworks: • Control Framework/Model Communities • Framework Taxonomy • CobiT, COSO, and ISO 17799 Mapping

What is CobiT? CobiT stands for the Control Objectives for Information and related Technology. • Issued and maintained by the Information Systems Audit and Control Association (ISACA). • Focuses on IT Governance processes to bridge the gaps between business risks, control needs, and technical issues. • Provides “good practice” from consensus of experts.

Why Choose CobiT? Business orientation is the main theme of CobiT. It offers a comprehensive guidance for management and business process owners by providing: • A Control Framework of 34 high-level control objectives, 215 recommended detailed controls and Maturity Models with KPI’s. • A standard and common language among IT Auditors. • Maintenance and update including SOX. CobiT V4.0 is the latest release. • Research shows that CobiT is sufficient to cover or relate to major control frameworks such as ISO 17799 and COSO.

The Jericho Forum Eleven Commandments

The CobiT Control Framework

Phase 2 - IT Audit Tactical Focus The primary focus of Phase 2 is to assess and document the impact of the Jericho Forum problem/position papers against the 215 CobiT detail control objectives in areas such as: • IT Audit Planning • IT Audit Scope • Review of Audit Assumptions • Considerations in Performing IT Audits

Changes for Considerations • Control points that were centralised and external to applications and systems will change (end points have shifted….). • Reliance and assumptions of controls over traditional internal components, such as a WAN or LAN, may no longer be relevant or appropriate. (audit scope changes) • A sampled assessment of decentralised components may not give a clear picture of the overall IT control environment. (partners spread spyware, business boundary and IT boundary, problems go easier, auditors to think about in business terms instead of IT constraints. Protection explicit) • The focus and importance of core IT systems may need to change – for example, increased reliance on Data Centre, client and application controls. • Additional foundation services (Identity, Audit, Monitoring) may need to be included in the scope of future audits.

Key Challenges • Expanding the corporate boundary of the network. • Thinking of the internal network as a semi public or public network. • Pushing more applications and systems into data centers that are Internet accessible. • Developing applications that are Internet enabled and take advantage of security controls such as transport layer security, authentication and authorisation controls • Relying more on endpoints in the network to protect themselves using patching, firewalling, anti-virus technologies. • Identifying users and devices that connect to business systems and applications. • Patching and managing devices that connect to corporate systems from remote and often untrusted Internet sources. • Providing users who may be employees, customers, business partners, 3rd party suppliers with access to business applications. • Providing a bridge between legacy systems and Internet accessible services. • Supporting a variety of remote access methods through wireless, dial-up, VPN, 3G etc.

Phase 3 Operational Focus on Gap Resolutions In this phase the gaps and impact identified in Phase 1 & 2 are addressed via: • Sharing among members of practical solutions for the short term. • Proposals and recommendations to IT audit standard bodies for updates, guidelines, and checklists. • RFI’s to the vendor community for technical solutions to seek improvements in the effectiveness and efficiency during the IT audit processes.

Papers available from the Jericho Forum • The Jericho Forum “Commandments” are freely available from the Jericho Forum Website • Plus ten more papers http://www.jerichoforum.org

Future Position Papers There are position papers in progress on: • Encryption & Encapsulation • Regulation, Compliance & Certification • Network Security & QoS • Audit & Management in a distributed environment • Data/Information Management

Shaping security for tomorrow’s world www.jerichoforum.org

IT Audit & Identity Management Challenges in a De-perimeterisation Scenario