What is Security, anyway? Software architecture for information security part 1 : Expressing requirements with iso27000 annotated
•
1 gefällt mir•224 views
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.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie What is Security, anyway? Software architecture for information security part 1 : Expressing requirements with iso27000 annotated
Ähnlich wie What is Security, anyway? Software architecture for information security part 1 : Expressing requirements with iso27000 annotated (20)
Mehr von Chris F Carroll
Mehr von Chris F Carroll (6)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
What is Security, anyway? Software architecture for information security part 1 : Expressing requirements with iso27000 annotated
- 1. Software Architecture Chris F Carroll Software Architecture for Information Security Part 1: expressing requirements
- 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. Software Architecture Chris F Carroll Stating & Analysing Information Security Requirements using ISO 27000
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Software Architecture Chris F Carroll How can we use this?
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Software Architecture Chris F Carroll ✓ Definitions & Requirements I : Analysis ✤ Design ✤ Requirements II : Threats & Risks ✤ Implementation ✤ Verification ✤ Handover