Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
Software Architecture Chris F Carroll
Software Architecture for
Information Security
Part 1: expressing requirements
Software Architecture Chris F Carroll
✤ Definitions & 

Requirements I: Analysis
✤ Design
✤ Requirements II : Risk & Threa...
Software Architecture Chris F Carroll
Stating & Analysing 

Information Security Requirements 

using ISO 27000
Requirements
Threatsvs.
All requirements have edge cases but with security they expand into a
whole second way of seeing t...
Software Architecture for Security Chris F Carroll
How can we think
about security?
Let’s start at the beginning. To get s...
How Can We Think About Security? Chris F Carroll
✤ WHAT are we trying to secure?

✤ WHO are we securing for or from?

✤ WH...
Why use ISO 27000?
✓ ISO 27000 provides, if not a complete
domain model for security, then at least
a vocabulary.
✓ Our se...
Group Policy Statement Information Security Policy v10.1, 2018
“We strive to protect the group’s critical information asse...
How Can We Think About Security? Chris F Carroll
✤ WHAT are we trying to secure?

✤ WHO are we securing for or from?

✤ WH...
Chris F Carroll
WHAT do we want to secure?
Information Assets, typically:

1. Data Stores

2. Systems that let you do thin...
Chris F Carroll
WHAT do we want to secure?
Information Assets, typically:

1. Data Stores

2. Systems that let you do thin...
Chris F Carroll
WHAT do we want to secure?
Information Assets, typically:

1. Data Stores

2. Systems that let you do thin...
ISO 27000 Vocabulary for Secured Assets Chris F Carroll
Asset: For us as business to say what
needs securing

(Un)Authoris...
Relating Other Vocabulary to the Standard Chris F Carroll
How do other vocabularies map to/from
“Assets + Authorised Users...
Chris F Carroll
Access Control: “to ensure that access to
assets is authorised & restricted based on
business and security...
Relating Other Vocabulary to the Standard Chris F Carroll
Users,Groups, Roles

Identity, Principal, Claims
These (and more...
Relating Other Vocabulary to the Standard Chris F Carroll
Authenticating Identity is our usual
way to convince ourselves w...
Relating Other Vocabulary to the Standard Chris F Carroll
Confidentiality presumably implies

Access Control: Deny-Read

I...
Security : Just 3 Questions Chris F Carroll
✤ WHAT are we trying to secure?
➡ Assets: Data Stores & Systems
✤ WHO are we s...
Software Architecture Chris F Carroll
How can we use
this?
Security Requirements Chris F Carroll
HLD or Architecture Template
Express security requirements using the 3 Questions

1....
Security Requirements Chris F Carroll
HLD Security Requirements
1.1. Data Stores Accessed or Exposed by this Project
Data ...
Security Requirements Chris F Carroll
HLD Security Requirements
1.1. Data Stores Accessed or Exposed by this Project
Data ...
Security Requirements Chris F Carroll
PROPOSAL
User/Role/Principal
Authentication
Mechanism
Online Customer
OAuth2 provide...
Security Requirements Chris F Carroll
PROPOSAL
User/Role/Principal
Authentication
Mechanism
Online Customer
OAuth2 provide...
Security Requirements Chris F Carroll
PROPOSAL
Asset
Authorised
User
Confidentiality

(Read Access is
restricted to…)
Integ...
Security Requirements Chris F Carroll
HLD Template
Express security requirements using the 3 Questions

1. WHAT Assets mus...
Security Requirements Analysis Chris F Carroll
Asset
Id Assets Where is it?
Type of
Asset Who's Asset?
Required
Confidenti...
Design for Security Requirements Chris F Carroll
Confidentiality : per-customer confidentiality for an
online system implies...
Chris F Carroll
WHAT do we want to secure?
Information Assets, typically:

1. Data Stores

2. Systems that let you do thin...
Software Architecture Chris F Carroll
✓ Definitions & 

Requirements I : Analysis
✤ Design
✤ Requirements II : Threats & R...
Próxima SlideShare
Cargando en…5
×

What is Security, anyway? Software architecture for information security part 1 : Expressing requirements with iso27000 annotated

Software Architecture for Information Security
Part 1 : Expressing requirements using the vocabulary of ISO 27000.

Most of our attention in information security is given to threats. But our understanding of threats will be piecemeal & incomplete if we do not understand what threats threaten. We'll look at how to state and think about the core requirements, answering the question, “what is security anyway?” for the purpose of software systems.

  • Inicia sesión para ver los comentarios

  • Sé el primero en recomendar esto

What is Security, anyway? Software architecture for information security part 1 : Expressing requirements with iso27000 annotated

  1. 1. Software Architecture Chris F Carroll Software Architecture for Information Security Part 1: expressing requirements
  2. 2. Software Architecture Chris F Carroll ✤ Definitions & 
 Requirements I: Analysis ✤ Design ✤ Requirements II : Risk & Threats ✤ Implementation ✤ Verification ✤ Handover To deal with software security fully, we would go through the lifecycle. In this talk we’ll just look at the first bullet point.
  3. 3. Software Architecture Chris F Carroll Stating & Analysing 
 Information Security Requirements 
 using ISO 27000
  4. 4. Requirements Threatsvs. All requirements have edge cases but with security they expand into a whole second way of seeing the issue. Threats get all the news. But our understanding of threats remains piecemeal if we don’t understand the core requirements they are threatening. So we start here.
  5. 5. Software Architecture for Security Chris F Carroll How can we think about security? Let’s start at the beginning. To get security right, we want a framework for thinking about it: What are the questions we should ask and what concepts will help us to answer them?
  6. 6. How Can We Think About Security? Chris F Carroll ✤ WHAT are we trying to secure?
 ✤ WHO are we securing for or from?
 ✤ WHAT does security mean anyway? If we can answers these 3 questions then we have done most of the work of thinking about security. To help us answer them, we want some vocabulary or a framework.
  7. 7. Why use ISO 27000? ✓ ISO 27000 provides, if not a complete domain model for security, then at least a vocabulary. ✓ Our security policy and ISMS approach is based on the ISO 27000 series. At some point, our homegrown software has to dovetail with it. Chris F Carroll ISO 27000 series is a standards series for an information security management systems. It starts with a few pages of definitions. Which goes a long way to a framework for thinking about security. (actually you can get the same vocabulary from wikipedia or a software architecture textbook).
  8. 8. Group Policy Statement Information Security Policy v10.1, 2018 “We strive to protect the group’s critical information assets against all internal, external, deliberate or accidental threats throughout its lifecycle
 We protect against unauthorised access threatening the Confidentiality of our information and ensure that the Integrity and Availability of critical information is maintained.
 Our Information security policy is to ensure business continuity, minimising the risk of damage by preventing security incidents and reducing their potential impact. We are committed to continuous improvement, ongoing compliance with legislative and regulatory requirements and to ensuring our employees receive appropriate information security awareness training.” Leaving threats & risk aside for the moment, we could answer our 3 questions with just 5 key ideas: 
 Asset ; (Un)Authorised ; and Confidentiality, Integrity, Availability. Here’s an example attempt to think about security, in a security policy statement. The words in bold are drawn from ISO 27000.
  9. 9. How Can We Think About Security? Chris F Carroll ✤ WHAT are we trying to secure?
 ✤ WHO are we securing for or from?
 ✤ WHAT does security mean anyway? So now, let’s answer our 3 questions with this vocabulary
  10. 10. Chris F Carroll WHAT do we want to secure? Information Assets, typically: 1. Data Stores 2. Systems that let you do things
 WHO are we securing for/from? (Un)/Authorised users
 WHAT does security mean anyway? Confidentiality Integrity Availability Security : Just 3 Questions These are the 2 asset classes of most concern to a software team. So now, let’s answer our 3 questions with this vocabulary
  11. 11. Chris F Carroll WHAT do we want to secure? Information Assets, typically: 1. Data Stores 2. Systems that let you do things
 WHO are we securing for/from? (Un)/Authorised users
 WHAT does security mean anyway? Confidentiality Integrity Availability Security : Just 3 Questions We divide the world into two groups of people: The Authorised and 
 The Unauthorised.
  12. 12. Chris F Carroll WHAT do we want to secure? Information Assets, typically: 1. Data Stores 2. Systems that let you do things
 WHO are we securing for/from? (Un)/Authorised users
 WHAT does security mean anyway? Confidentiality Integrity Availability Security : Just 3 Questions And we get a grip on what security means with the “3 dimensions” defined by the standard, widely referred to as 
 The C.I.A.
  13. 13. ISO 27000 Vocabulary for Secured Assets Chris F Carroll Asset: For us as business to say what needs securing (Un)Authorised: We as business decide who is authorised Confidentiality : “not made available or disclosed to unauthorised individuals, entities, or processes” Integrity : “accuracy and completeness” Availability : “accessible and usable upon demand by an authorised entity”
  14. 14. Relating Other Vocabulary to the Standard Chris F Carroll How do other vocabularies map to/from “Assets + Authorised Users + C.I.A.?” Read-access threatens Confidentiality Write-access threatens Integrity Deny-Read protects Confidentiality by restricting Availability Deny-Write protects Integrity, restricting Availability Access Control addresses C.I.A. requirements
  15. 15. Chris F Carroll Access Control: “to ensure that access to assets is authorised & restricted based on business and security requirements” ISO 27000 Vocabulary for Secured Assets
  16. 16. Relating Other Vocabulary to the Standard Chris F Carroll Users,Groups, Roles Identity, Principal, Claims These (and more) are all used to define 
 Authorised User ISO standard dates from 1990s (BS7799) How do other vocabularies map to/from Assets + Authorised Users + C.I.A.?
  17. 17. Relating Other Vocabulary to the Standard Chris F Carroll Authenticating Identity is our usual way to convince ourselves we have an Authorised User How does a system know that a user is authorised? Authentication : “Provision of assurance that a claimed characteristic of an entity is correct”
  18. 18. Relating Other Vocabulary to the Standard Chris F Carroll Confidentiality presumably implies Access Control: Deny-Read Integrity presumably implies Access Control: Deny-Write Availability may imply Grant-Read Grant-Write Uptime, backups, connectivity, resilience to attack How does C.I.A map back to other vocabularies? Note the last bullet. Security includes both functional and non-functional requirements (NFRs).
  19. 19. Security : Just 3 Questions Chris F Carroll ✤ WHAT are we trying to secure? ➡ Assets: Data Stores & Systems ✤ WHO are we securing for & from? ➡ (Un)Authorised Users ✤ WHAT does security mean anyway? ➡ C.I.A.
 N.B. the need to prove & improve security may result in requirements for audit, accountability, monitoring, etc. Thinking about security: We answered our 3 questions using only a few key ideas, but this is enough to state and analyse requirements.
  20. 20. Software Architecture Chris F Carroll How can we use this?
  21. 21. Security Requirements Chris F Carroll HLD or Architecture Template Express security requirements using the 3 Questions 1. WHAT Assets must this system secure? List Assets Accessed or Exposed
 1.1 Data Stores 1.2 Other Systems 2. WHO Are we securing For/From? Identify Authorised Roles and Authentication Mechanisms 3. WHAT do we mean by Security? State C.I.A. Requirements Per Asset Per Authorised Identity PROPOSAL A typical software architecture document includes a placeholder for security requirements. We can use the 3 Questions to structure the statement of requirements
  22. 22. Security Requirements Chris F Carroll HLD Security Requirements 1.1. Data Stores Accessed or Exposed by this Project Data Store Category or Risk Level New Exposure? 1. Shiva DB Confidential
 GDPR Yes PROPOSAL System Accessed or Exposed? New Exposure? 1. Adobe Campaign Manager Accessed Yes 2. SMS & Email Accessed Yes 1.2. Other Systems Accessed or Exposed by this Project 1. Let’s start with, simply, a list of assets that our new project will, or may, expose or access.
  23. 23. Security Requirements Chris F Carroll HLD Security Requirements 1.1. Data Stores Accessed or Exposed by this Project Data Store Category or Risk Level New Exposure? 1. Shiva DB Confidential
 GDPR Yes PROPOSAL System Accessed or Exposed? New Exposure? 1. Adobe Campaign Manager Accessed Yes 2. SMS & Email Accessed Yes 1.2. Other Systems Accessed or Exposed by this Project We didn’t discuss RISK earlier. Some assets are more risky, or valuable, than others. For each asset, assess the risk of a breach of C.I.A. requirements.
  24. 24. Security Requirements Chris F Carroll PROPOSAL User/Role/Principal Authentication Mechanism Online Customer OAuth2 provider Auth0 CCA Permission X AD Login CCA Permission Y AD Login HLD Security Requirements 2. Authorised Users/Roles & Authentication Mechanisms 2. 
 Divide the world into authorised and unauthorised. We often use Roles or Groups to define this division, because managing for hundreds or thousands of individuals is just too burdensome and error prone
  25. 25. Security Requirements Chris F Carroll PROPOSAL User/Role/Principal Authentication Mechanism Online Customer OAuth2 provider Auth0 CCA Permission X AD Login CCA Permission Y AD Login HLD Security Requirements 2. Authorised Users/Roles & Authentication Mechanisms If there is a more than one identity or login mechanism, then it helps to list them
  26. 26. Security Requirements Chris F Carroll PROPOSAL Asset Authorised User Confidentiality (Read Access is restricted to…) Integrity
 (Operations
 restricted to…) Customer DB Authenticated Customer Read access to own data only Permissions detailed below… Adobe Campaign Manager Service Account NONE needed Permitted Operations below… Email & SMS Service Account NONE needed Permitted Operations below… HLD Security Requirements 3. List CIA Requirements Per Asset Per Authorised User 3. Finally the detail of permissions: 
 User A is authorised to perform operation X on data Y Coming back to the System Assets, we are concerned about the risk raised by connectivity. The more we can restrict the connections—the interfaces—the more simple and easy to do the security
  27. 27. Security Requirements Chris F Carroll HLD Template Express security requirements using the 3 Questions 1. WHAT Assets must this system secure? List Assets Accessed or Exposed
 1.1 Data Stores 1.2 Other Systems 2. WHO Are we securing For/From? Identify Authorised Roles and Authentication Mechanisms 3. WHAT do we mean by Security? State C.I.A. Requirements Per Asset Per Authorised Identity PROPOSAL
  28. 28. Security Requirements Analysis Chris F Carroll Asset Id Assets Where is it? Type of Asset Who's Asset? Required Confidentiality Level Required Availability & Integrity Level 1 LB code and scripts BitBucket, Dev Machines, Private NuGet Our labour LB Low Medium 2 AWS Dev AWS Dev Our labour LB Low Medium 3 AWS Live Infrastructure Design & Runtime AWS Live: ECS EC2 Operations LB Low Business Process Critical 4 All Customer's Business Data AWS Live: ECS EC2 DB Customers' Data Customers Business Critical Business Process Critical 5 All Customer's Customers Personal Data AWS Live: ECS EC2 DB Logs Personal Data Customers' Customers Business & Regulatory Critical Business Process Critical 6 Single Customer's Business Data AWS Live: ECS EC2 DB Customer's Data Customers Business Critical Business Process Critical 7 Single Customer's Customers Personal Data AWS Live: ECS EC2 DB Logs Personal Data Customer's Customers Business & Regulatory Critical Business Process Critical Asset List for a cloud-hosted multi-tenant service More complex example
  29. 29. Design for Security Requirements Chris F Carroll Confidentiality : per-customer confidentiality for an online system implies we must design row-level security and be able to verify it is implemented correctly Integrity : If all write access goes through a single tightly controlled interface, we can prove that no unexpected modifications are possible Auth (login, lockout, password reset): Buy or Build? Design Decisions, Tactics, Implementation Rules
 follow on from Security Requirements
  30. 30. Chris F Carroll WHAT do we want to secure? Information Assets, typically: 1. Data Stores 2. Systems that let you do things
 WHO are we securing for/from? (Un)/Authorised users
 WHAT does security mean anyway? Confidentiality Integrity Availability Security : Just 3 Questions
  31. 31. Software Architecture Chris F Carroll ✓ Definitions & 
 Requirements I : Analysis ✤ Design ✤ Requirements II : Threats & Risks ✤ Implementation ✤ Verification ✤ Handover

×