Security Architecture Principles A Brief Introduction. Mark Battersby , Oslo

(1)

Security Architecture Principles

A Brief Introduction

Mark Battersby 2013-05-22, Oslo

(2)

| Sector, Alliance, Offering

Agenda

• About Me

• Enterprise Architecture

• Architecture Principles

• Our Philosophy

• Security Architecture Principles

• Security Architecture Principles, Cloud & SOA

(3)

Profile

 Significant experience of analysis and verification of business and technical requirements – including security audit, compliance, analysis and test of tools.

 Significant experience in many roles including, security architect, security adviser and security analyst.

 Architected and developed business critical solutions for demanding blue-chip clients

 Specialized within information security (identity and access management, information assurance, security standards and policies)

 Familiarity with information security standards, ISO 27000, COBIT, ISF Security Guidelines and Benchmarking, Security Audit, Governance, Risk and Compliance

 Exceptional communication and presentation skills based on a strong desire to learn and share knowledge, experience and skills with project members

Qualifications

 MSc. Information Security, RHUL (Royal Holloway, University of London)

 TOGAF 9 Certified Architect

 Member RHUL information security group

 Member British Computer Society

Recent Professional Experience

Ericsson 2012 - 2013 , Stockholm, Sweden

 Information Security and Operational Risk Manager. Security Advisor to management team

 Development of information security and operational risk policies, directives and controls.

 Implementation of information security and operational risk policies, directive and controls

 Delivery of risk and information security awareness programs within Ericsson

 Regular review and audit of information security and risk management procedures

Axfood, Stockholm, Sweden

 Analyst, Identity and Access Management

 Pre-study for identity and access management in a major SAP implementation

Dalkia, Stockholm, Sweden

• Security Architect, Identity and Access Management

• Hands-on support to the Oracle partner implementing an identity and access management system.

TeliaSonera, Stockholm, Sweden

 Lead Architect, Identity and Access Management, Corporate Security

 Business analysis, architecture and design of an identity and access management system for corporate security

Mark Battersby – Security Architect

(4)

Enterprise Architecture

Definition

Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution

(5)

Architecture Principles

Architecture Principles are essentially guidelines which

• Influence the architecture (in some way) • Address long term goals and strategies

• Describe the agenda or priority of the business • May be conflicting

• Change infrequently – if at all

Architecture Principles do not

• Define what needs to be done • Solve a specific problem

Guiding Principles are rules which

• Allow governance of architecture

• Are a way to determine and define which mechanisms shall be used when there are several conflicting requirements

(6)

Security Architecture Principles

(7)

Our philosophy

The easy way of doing things

should also be the secure way

of doing things

Security mechanisms should be

appropriate, minimal and

invisible to the users

Security choices should be

based on business need, risk

and Return On Security

Investment

Information should only be

present where it is necessary.

Know your asset and know your

needs to minimize exposure,

risk and security scope

Security is an

aspect of

everything

(8)

Security Principles

Security Principles define key design features of information security that should be applied when architecting a secure architecture (or framework, or infrastructure).

These features must:

 Be defined in plain language

 Use terms that have clear meaning within the context being used

(9)

Guiding Principles identify correct security mechanisms

9

Principles shall:

 Provide guidelines toward the long term goals of the business

 Describe priorities of the business

 Define the rules for architecture

 Be stable

Principles shall not:

 Describe the problem or topic

(10)

Security Principles in Context

 General Security Principles  SOA Security Principles  Cloud Security Principles

(11)

Information Centric Security (Jerico Forum).

Secure the business Secure the information carrier

Secure the information

Asset assessment Risk analysis

Policies

Stored In transit Used

Information centric security

• A reference model for

securing information in the enterprise

Jericho style security

• A reference model for implementing information centric security

• Is built upon the mobile workforce concept and an interconnected world

(12)

General Security Principles

Categories include  Fundamentals  Trust  Data Protection  Management  Interoperability

(13)

Security Principles - Fundamentals

 Policy Driven

– Security must be driven by policy  People, Process and Technology

– All people, processes and technology must have declared and transparrent levels of trust for any transaction to occur

 Openness

(14)

Security Principles - Fundamentals

 Security by Design

– Security should be designed as an integral part of the system architecture  Sharing

– Security solutions should include management controls to accommodate sharing  Defense in Depth

– Multiple levels of protection, especially if they use different mechanisms, should be used to provide effective defense in depth

(15)

Security Principles - Fundamentals

 Security is Model-driven

– Models are reflective of the operating environment, common models, and consistent formats for identity and trust, data, policy, applications, security information and events, and cryptographic keys.

 Simplicity

– Security mechanisms should be pervasive, simple, scalable, and easy to manage.  Protection against Insider and Outsider Attacks

– Security measures should maintain their intended effectiveness irrespective of the source credentials of a principal claiming access to a resource.

(16)

Security Principles - Trust

 Trust Assurance

– Mutual trust levels must be determinable  Weakest Link

(17)

Security Principles – Data Protection

 Security Context

– Validate the security context for which the solution is designed  Data Access Control

– Access to data should be controlled by security attributes of the data itself  Data Protection

(18)

Security Principles - Management

 Accountability

– Security solutions should include collection of audit information on system operations. – (See also the Accountability in Service-based Architectures principle.)

 Regulation/Compliance

– Security solutions should include mechanisms to configure and monitor systems for regulatory compliance.

 Privacy

(19)

Security Principles - Management

 Compartmentalization (Security Domains)

– Resources should be protected at separated levels appropriate to their value, confidentiality, integrity, and accountability classification.

 Separation of Management Services

– Security services for management, enforcement, and accountability should be delivered as separate functions through separate authorities.

 Separation of Duties

(20)

Security Principles - Interoperability

 Least Privilege

– A principal should have only the privileges required to carry out its specified task.  Agility and Extensibility

– Security solutions should include agility and management mechanisms to accommodate extensibility.

 Consumability

– Security solutions should include management mechanisms to accommodate consumability.

(21)

Security Architecture Principles – Other Sources

 ISO/IEC 27001

– ISO/IEC 27001:2005: Information Technology – Security Techniques – Information Security Management Systems – Requirements.

 NIST

– NIST Special Publication 800-14: Generally Accepted Principles & Practices for Securing Information Technology Systems;

– Reference http://csrc.nist.gov/publications/nistpubs/800-14/800-14.pdf

 Joint ISF, (ISC)2, ISACA

– Principles for Information Security Practitioners, 2010;

– http://www.isaca.org/Knowledge-Center/Standards/Pages/Security-Principles.aspx

 Jerico Forum

– Jerico Forum Commandments, 2006

• Design principles that must be observed when architecting systems for secure operation in de-perimeterized environments

– Jerico Forum Identity, Entitlement and Access Management (IdEA) Commandments, 2011

(22)

Security Architecture Principles – Cloud, SOA

Mark Battersby 2013-05-22, Oslo

(23)

Security Architecture Principles – Cloud and SOA



Weakest Link



Off-line backup



Policy based access to Services



Data Protection



Privacy



Multi-tenancy



Data Evacuation



Intellectual Property



Accountability in SOA

(24)

Security Architecture Principles - Cloud and SOA



Weakest Link

–

Adding to the Weakest Link principle, this principle has particular application to

Cloud and SOA.



Off-line Backup

–

It must be possible for Cloud tenants to make a back-up of their data on

another environment of their choice.



Policy based access to Services

–

Service consumption will be controlled by policy. Policies must be held

externally from applications.

(25)

Security Architecture Principles - Cloud and SOA

 Data Protection

– Data protection should allow compliance with corporate or regulatory compliance

standards and practices, implemented in a manner that supports the other principles for Cloud and SOA, such as policy-based access, federation, multi-tenancy, etc.

 Privacy

– Extending the Privacy principle, protection of private information must demonstrate compliance with the enterprise's requirements for such protection across all points providing each service.

 Multi-tenancy

– A Cloud Computing model must support tenant and solution isolation among multiple tenants of the Cloud.

(26)

Security Architecture Principles - Cloud and SOA

 Data Evacuation

– A user of Cloud Computing must be able to request its data be removed in its entirety from the Cloud on terminating use of the service and be assured that no data is left behind in an accessible state.

 Intellectual Property

– A Cloud Computing model must support the notion that a user’s intellectual assets

(capital/property) and individuals’ or organizations’ innovations are protected contractually and where possible also technically, and respected by its Cloud hosting providers and/or their associated supply chain, including residual knowledge and experience-based

(27)

Security Architecture Principles - Cloud and SOA

 Accountability in SOA

– Security design in SOA/Cloud architectures should include collection and provision of audit information on system operations.

(28)

Questions ?

(29)

More Information

29

Please contact:

• Mark Battersby

(30)

More Information

30

With around 140,000 people in 40 countries, Capgemini is one of the world’s foremost providers of consulting, technology and outsourcing services. The Group reported 2010 global revenues of EUR 8.7 billion.

Together with its clients, Capgemini creates and delivers business and technology solutions that fit their needs and drive the results they want.

A deeply multicultural organization,

Capgemini has developed its own way of working, the Collaborative Business ExperienceTM, and draws on Rightshore®, its worldwide delivery model. More information is available at

www.capgemini.com

Rightshore® is a trademark belonging to Capgemini

(31)