├── .gitignore ├── .prettierrc ├── .markdownlint.json ├── notes ├── 04-Secure-Software-Implementation-Programming │ ├── 03-Secure-Software-Coding-Operations.md │ ├── 01-Common-Software-Vulnerabilities-and-Countermeasures.md │ └── 02-Defensive-Coding-Practices.md ├── 05-Secure-Software-Testing │ ├── 02-Security-Testing.md │ └── 01-Security-Quality-Assurance-Testing.md ├── 07-Software-Deployment-Operations-Maintenance │ ├── 01-Secure-Software-Installation-and-Deployment.md │ └── 02-Secure-Software-Operations-and-Maintenance.md ├── 02-Secure-Software-Requirements │ ├── 03-Requirements.md │ ├── 01-Policy-Decomposition.md │ └── 02-Data-Classification-and-Categorization.md ├── 03-Secure-Software-Design │ ├── 01-Design-Processes.md │ ├── 02-Design-Considerations.md │ ├── 03-Securing-Commonly-Used-Architecture.md │ └── 04-Technologies.md ├── 08-Supply-Chain-Software-Acquisition │ └── 01-Supply-Chain-and-Software-Acquisition.md ├── 06-Secure-Lifecycle-Management │ └── 01-Secure-Lifecycle-Management.md ├── 01-Secure-Software-Concepts │ ├── 02-Risk-Management.md │ ├── 04-Software-Development-Methodologies.md │ ├── 01-General-Security-Concepts.md │ └── 03-Security-Policies-and-Regulations.md ├── 09-Terms │ └── Terms.md └── 10-Outline │ └── Outline.md ├── .github ├── FUNDING.yml ├── dependabot.yml └── workflows │ ├── quality-checks.yml │ └── deploy-mkdocs.yml ├── .prettierignore ├── .vscode └── settings.json ├── need to review.md ├── package.json ├── LICENSE ├── mkdocs.yml └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | node_modules 2 | -------------------------------------------------------------------------------- /.prettierrc: -------------------------------------------------------------------------------- 1 | { 2 | "tabWidth": 2, 3 | "useTabs": false 4 | } 5 | -------------------------------------------------------------------------------- /.markdownlint.json: -------------------------------------------------------------------------------- 1 | { 2 | "default": true, 3 | "MD013": false 4 | } 5 | -------------------------------------------------------------------------------- /notes/04-Secure-Software-Implementation-Programming/03-Secure-Software-Coding-Operations.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /.github/FUNDING.yml: -------------------------------------------------------------------------------- 1 | # These are supported funding model platforms 2 | 3 | github: joeyhage 4 | -------------------------------------------------------------------------------- /.prettierignore: -------------------------------------------------------------------------------- 1 | # Ignore artifacts: 2 | .github 3 | 4 | # Ignore specific file types 5 | *.json 6 | *.yml 7 | 8 | # Ignore specific files 9 | README.md -------------------------------------------------------------------------------- /.github/dependabot.yml: -------------------------------------------------------------------------------- 1 | version: 2 2 | updates: 3 | - package-ecosystem: "npm" 4 | directory: "/" 5 | schedule: 6 | interval: "weekly" 7 | versioning-strategy: lockfile-only 8 | - package-ecosystem: "github-actions" 9 | directory: "/" 10 | schedule: 11 | interval: "weekly" 12 | -------------------------------------------------------------------------------- /.vscode/settings.json: -------------------------------------------------------------------------------- 1 | { 2 | "cSpell.words": [ 3 | "anonymization", 4 | "discoverability", 5 | "exfiltration", 6 | "exploitability", 7 | "lifecyle", 8 | "mitigations", 9 | "nonrepudiation", 10 | "prequalification", 11 | "reputational" 12 | ] 13 | } -------------------------------------------------------------------------------- /.github/workflows/quality-checks.yml: -------------------------------------------------------------------------------- 1 | name: Quality checks 2 | 3 | on: 4 | push: 5 | paths-ignore: 6 | - '**.yml' 7 | workflow_dispatch: 8 | 9 | jobs: 10 | lint: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - name: Checkout 14 | uses: actions/checkout@v3 15 | - name: Setup node 16 | uses: actions/setup-node@v3.4.1 17 | with: 18 | node-version: "14.x" 19 | - name: Install dependencies 20 | run: npm ci 21 | - name: Prettier 22 | run: npm run format 23 | - name: Ensure consistency 24 | run: npm run lint 25 | -------------------------------------------------------------------------------- /.github/workflows/deploy-mkdocs.yml: -------------------------------------------------------------------------------- 1 | name: deploy-mkdocs site 2 | 3 | on: 4 | push: 5 | branches: [main] 6 | paths-ignore: 7 | - '**.yml' 8 | workflow_dispatch: 9 | 10 | jobs: 11 | deploy: 12 | runs-on: ubuntu-latest 13 | steps: 14 | - uses: actions/checkout@v3 15 | - uses: actions/setup-python@v4 16 | with: 17 | python-version: 3.x 18 | - run: pip install mkdocs-material mkdocs-gen-files mdx_truly_sane_lists 19 | - name: Copy Readme 20 | run: | 21 | cp README.md notes/ 22 | - name: Remove notes prefix from README links. 23 | run: | 24 | sed -ire "s;./notes/;;g" notes/README.md 25 | - run: mkdocs gh-deploy --force 26 | -------------------------------------------------------------------------------- /need to review.md: -------------------------------------------------------------------------------- 1 | - authorization to operate 2 | - management decision given by senior official to authorize operation of an information system and explicitly accept risk 3 | - linker (software) 4 | - combines one or more files (often generated by compiler) into a single executable 5 | - stack vs heap vs buffer 6 | - stack: static allocation of memory 7 | - heap: dynamic allocation of memory (memory leaks can occur if memory is not de-allocated) 8 | - buffer: reference to space in memory for moving data 9 | 10 | ## TODO 11 | 12 | - security controls 13 | - recovery time objective 14 | - risk response 15 | - real user monitoring vs synthetic monitoring 16 | - software qualification planning 17 | - cumulative failure profile 18 | - Common Attack Pattern Enumeration and Classification (CAPEC) vs Attack pattern 19 | - compiler switches -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "csslp-in-bullet-points", 3 | "description": "Certified Secure Software Lifecycle Professional summary in bullet points", 4 | "private": true, 5 | "scripts": { 6 | "lint": "npm run lint:md && npm run lint:relative-urls && npm run lint:consistency", 7 | "lint:md": "markdownlint notes/**/*.md --ignore node_modules", 8 | "lint:relative-urls": "remark notes/**/*.md --frail --use remark-validate-links", 9 | "lint:external-urls": "remark notes/**/*.md --frail --use remark-lint-no-dead-urls", 10 | "lint:consistency": "remark notes/**/*.md --frail --use remark-preset-lint-consistent", 11 | "format": "prettier --write ." 12 | }, 13 | "devDependencies": { 14 | "markdownlint-cli": "^0.28.1", 15 | "prettier": "^2.4.1", 16 | "remark-cli": "^10.0.0", 17 | "remark-lint-no-dead-urls": "^1.1.0", 18 | "remark-preset-lint-consistent": "^5.1.0", 19 | "remark-validate-links": "^11.0.1" 20 | } 21 | } 22 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2024 Joey Hage 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /notes/05-Secure-Software-Testing/02-Security-Testing.md: -------------------------------------------------------------------------------- 1 | # Security Testing 2 | 3 | ## Scanning 4 | 5 | Passive in nature 6 | 7 | Example: OS fingerprinting 8 | 9 | ### Attack Surface Analyzer 10 | 11 | Microsoft tool to analyze how Windows is impacted when app is installed 12 | 13 | ## Pen Testing 14 | 15 | - Active testing 16 | - purpose: provide details to dev team so root cause can be fixed 17 | 18 | Steps: 19 | 20 | 1. Recon (discovery, enumeration) 21 | 2. attack and exploitation 22 | 3. removal of evidence 23 | 4. reporting 24 | 25 | ### Fuzzing 26 | 27 | - brute-force, large number of inputs 28 | - network protocols, file protocols, web protocols 29 | - most browser errors are found via fuzzing 30 | - block-box, white-box, or grey-box 31 | - tests input validation vulns (e.g. XSS, injection) 32 | - both generation-based and mutation-based are used and have different advantages 33 | 34 | ## Simulation Testing 35 | 36 | - test in a pre-prod env 37 | - all aspects (config, firewall, OS, load/performance, etc) 38 | 39 | ## Testing for Failure 40 | 41 | - most testing is testing for failure - also important to test for incorrect values 42 | 43 | ## Crypto Validation 44 | 45 | - crypto random numbers are essential - best from crypto libraries 46 | 47 | ### FIPS 140-2 48 | 49 | - Federal Information Processing Standards 50 | - selection of approved algorithms and implementation for federal gov 51 | 52 | ## Regression Testing 53 | 54 | - more important as software gets older 55 | - one of most time consuming parts of software patches 56 | -------------------------------------------------------------------------------- /notes/04-Secure-Software-Implementation-Programming/01-Common-Software-Vulnerabilities-and-Countermeasures.md: -------------------------------------------------------------------------------- 1 | # Common Software Vulnerabilities and Countermeasures 2 | 3 | - screening code for disallowed functions is best performed by static testing 4 | 5 | ## CWE (Common Weakness Enumerations)/SANS Top 25 Vuln Categories 6 | 7 | - hasn't been updated since 2011 but still relevant 8 | 9 | ## OWASP Vuln Categories 10 | 11 | - dedicated to web applications 12 | 13 | ### Common Vulns and Countermeasures 14 | 15 | #### Injection Attacks 16 | 17 | - SQL Injection 18 | - safest method is stored procedure 19 | - OS Command Injection 20 | - Integer overflow/wraparound 21 | - path traversal 22 | - XSS 23 | - CSRF 24 | - LDAP 25 | - XML 26 | 27 | #### Cryptography 28 | 29 | - pay attention to algorithms and key length 30 | 31 | #### Input Validation 32 | 33 | - **buffer overflow** 34 | - estimated that nearly half of historical exploits stem from buffer overflow 35 | 36 | ## Embedded Systems 37 | 38 | - generally targeted for information disclosure or DoS 39 | 40 | ## Side Channel Attack 41 | 42 | - comes from cryptographic world - attack against implementation, not algorithm 43 | - **use byproduct of a system** 44 | 45 | Types: 46 | 47 | - timing attacks and power attacks 48 | - analyze power/time used to make determination about what is happening 49 | - data remanence attacks 50 | - cooling RAM to access data after power turned off 51 | - electromagnetic attacks/acoustic attacks 52 | - reproduce what is on the screen or was typed on a keyboard 53 | -------------------------------------------------------------------------------- /notes/04-Secure-Software-Implementation-Programming/02-Defensive-Coding-Practices.md: -------------------------------------------------------------------------------- 1 | # Defensive Coding Practices 2 | 3 | ## Declarative vs Programmatic (imperative) Security 4 | 5 | - early design decision 6 | - Declarative 7 | - define the what 8 | - Security is defined in the deployment, not the code itself 9 | - Managed by ops team, not dev team 10 | - more flexible security 11 | - Imperative 12 | - embedded into code 13 | - less flexible/portable/reusable but allows for greater granularity 14 | 15 | ### Bootstrapping 16 | 17 | - startup process when computer/program starts 18 | 19 | ### Cryptographic Agility 20 | 21 | - allow for changes in crypto function (e.g. algorithm) without changing code 22 | - also assists with international cryptography reqs 23 | - early design decision 24 | - **important to use secure sessions** 25 | 26 | ### Handling Configuration Parameters 27 | 28 | - securing config files is an important design decision 29 | 30 | ## Memory Management 31 | 32 | - shared responsibility between app and OS 33 | - managed code applications (.NET, Java) handle memory management 34 | 35 | ### Type-safe Practice 36 | 37 | - type safety is linked to memory safety: cannot access arbitrary locations of memory 38 | 39 | ### Locality 40 | 41 | - when a program references memory, other references are generally predictable and in close proximity 42 | - several memory attacks take advantage of locality 43 | 44 | ## Error Handling 45 | 46 | ### Exception Management 47 | 48 | - if left to the OS to handle, privilege escalation and other issues can occur 49 | 50 | ## Interface Coding 51 | 52 | - need appropriate AuthN and AuthZ 53 | - audit externally exposed, privileged operations 54 | 55 | ## Primary Mitigations 56 | 57 | - standard best practice mitigations: 58 | - lock down env 59 | - establish/maintain control of inputs 60 | - establish/maintain control of outputs 61 | - assume external components can be undermined 62 | - assume code can be read by anyone 63 | - use libraries and frameworks that avoid introducing weaknesses 64 | - use industry-accepted security features 65 | - integrate security into the entire SDLC 66 | - use mix of methods to find and prevent weaknesses 67 | 68 | ### Defensive Coding 69 | 70 | Foundational: 71 | 72 | - attack surface reduction 73 | - understand common coding vulns 74 | - implement standard mitigations 75 | 76 | Other: 77 | 78 | - code analysis 79 | - code review 80 | - versioning 81 | - crypto agility 82 | - memory mgmt 83 | - exception handling 84 | - interface coding 85 | - managed code 86 | 87 | Exam tips: 88 | 89 | - controlling concurrency (access to shared objects/race conditions) 90 | - tokenization for sensitive data 91 | 92 | ## Learning from Past Mistakes 93 | 94 | - security team should regularly update security reqs while considering errors from other companies 95 | -------------------------------------------------------------------------------- /notes/07-Software-Deployment-Operations-Maintenance/01-Secure-Software-Installation-and-Deployment.md: -------------------------------------------------------------------------------- 1 | # Secure Software Installation and Deployment 2 | 3 | ## Installation 4 | 5 | - SDLC is broken into two phases: development and sustainment 6 | - Sustainment includes: installation, deployment, operations, maintenance 7 | 8 | ### Installation V&V 9 | 10 | - Use MITRE's Common Weakness Enumeration (CWE) to evaluate code 11 | 12 | ### Planning for Operational Use 13 | 14 | #### Bootstrapping 15 | 16 | - set of ops that properly launch function and ensure continuing correctness 17 | - 📝 aka booting - e.g. PC power on self-test (POST) 18 | - integrity is mandatory 19 | - implement error detection and correction 20 | 21 | - 📝 version control: labeling software releases so end user knows what they are using 22 | 23 | ## Configuration Management 24 | 25 | - 📝 exercise rational control over changes to software 26 | 27 | ### Organizing the Configuration Management Process 28 | 29 | Three separate roles 30 | 31 | 1. **customer role**: maintenance of product after release 32 | 2. **supplier role**: managing configuration prior to release 33 | 1. writes configuration management plan in conjunction with customer org 34 | 3. **subcontractor role**: if product developed through supply chain 35 | 36 | ### Configuration Management Plan 37 | 38 | - should specify change management, baseline management, and verification management roles 39 | - versioning, backup, check-in/check-out processes, change control 40 | 41 | ### Configuration Management Process 42 | 43 | - **purpose**: establish and maintain integrity of software items 44 | 45 | - 📝 common way of tracking changes is through a configuration management database (CMDB) 46 | - also called configuration management system (CMS) 47 | - CMS is required for ISO/IEC 15408 (common criteria) accreditation 48 | 49 | #### Process implementation 50 | 51 | - create a fully documented plan for the entire lifecycle of the configuration management process 52 | 53 | #### Configuration identification 54 | 55 | - identify software items included in baselines 56 | - create formal documentation with baseline version designations for each software item 57 | 58 | #### Configuration control 59 | 60 | - change management 61 | - need authorization before changes are incorporated into baseline 62 | - required for auditing 63 | 64 | #### Configuration status accounting 65 | 66 | - status and history for all controlled software items, including baselines 67 | 68 | #### Configuration evaluation 69 | 70 | - certify correctness of change after change is complete 71 | - use statement of work (SOW) to verify 72 | 73 | #### Release management and delivery 74 | 75 | Product Baseline Repositories: 76 | 77 | 1. Controlled: current baseline, strictly controlled 78 | 2. Dynamic: un-trusted baselines being developed by programmers 79 | 3. Archive: past baselines, collective memory of the IT function 80 | -------------------------------------------------------------------------------- /notes/02-Secure-Software-Requirements/03-Requirements.md: -------------------------------------------------------------------------------- 1 | # Requirements 2 | 3 | ## 📝 Functional Requirements 4 | 5 | - business reqs 6 | - IT reqs (e.g. database, environment, DR/BCP) 7 | - org reqs (e.g. coding standards, maintainability) 8 | - security reqs 9 | 10 | ### Role and User Definitions 11 | 12 | - which user groups are allowed access, and to what functionality 13 | - part of the use-case definition 14 | - users = subjects 15 | 16 | ### Objects 17 | 18 | - ensures members of dev team can use common set of objects and control appropriately 19 | 20 | ### Activities/Actions 21 | 22 | - Each object in a system should have all possible activities/actions defined + documented 23 | 24 | ### Subject-Object-Activity Matrix 25 | 26 | - 📝 helps establish relationships between users and objects 27 | - creates list of allowable actions and another list of denied actions 28 | 29 | ### Use cases 30 | 31 | - a specific example of an intended behavior of the system, usually for complex/confusing/ambiguous situations 32 | - not intended for all subject-object interactions 33 | - not a substitute for documenting specific reqs 34 | - 📝 graphical format that shows intended behavior (ellipses) for actors (stick figures) 35 | - 📝 best for business reqs that are poorly defined 36 | 37 | ### Abuse cases (inside and outside adversaries) 38 | 39 | - form of use case but for the specifically prohibited 40 | 41 | #### SAFECode 42 | 43 | - development and distribution use cases - free, published PDF 44 | 45 | ### Sequencing and Timing Issues 46 | 47 | - race conditions, infinite loops 48 | - Means system is vulnerable to a Time of Check/Time of Use (TOC/TOU) attack 49 | - 📝 system does not use the value right after it checks the value, allowing for unauthorized manipulation 50 | - 📝 To avoid race conditions, first identify race window and then design so processes are not called concurrently (mutual exclusion) 51 | - 📝 infinite loops: caused by complex conditional logic with unhandled situations - all conditions in a nested loop should be handled in a positive fashion 52 | 53 | ### Secure Coding Standards 54 | 55 | - Secure SDLC includes controlling processes and making repeatable 56 | - Adopt secure development frameworks as part of SDLC 57 | - 📝 each function should practice complete error mitigation 58 | - logging standards for what, where, when 59 | 60 | ## Operational Requirements 61 | 62 | - enterprise systems need to interact with and function alongside many other systems 63 | - complete SDLC solution: secure by design, secure by default, secure in deployment 64 | - default configuration should be secure 65 | 66 | ### Deployment environment 67 | 68 | - software is deployed to env that best suits its maintainability, data access, and access to needed services 69 | - follow corporate standards for seamless inter-connectivity 70 | 71 | ## Requirements Traceability Matrix (RTM) 72 | 73 | - 📝 track and manage reqs and implementation details 74 | - document relationships b/w security reqs, controls, and test/verify efforts 75 | - predefined reqs for infra, security, data sources, etc for dev teams 76 | 77 | ## Connecting the dots 78 | 79 | - easiest reqs are the features asked for 80 | - also need to document implied reqs 81 | - if the dev team should do something, needs to be listed in project reqs 82 | -------------------------------------------------------------------------------- /mkdocs.yml: -------------------------------------------------------------------------------- 1 | site_name: CSSLP-IN-BULLET-POINTS 2 | 3 | nav: 4 | - 'Home': 'README.md' 5 | - 'Secure Software Concepts': 6 | - 'General Security Concepts': '01-Secure-Software-Concepts/01-General-Security-Concepts.md' 7 | - 'Risk Management': '01-Secure-Software-Concepts/02-Risk-Management.md' 8 | - 'Security Policies and Regulations': '01-Secure-Software-Concepts/03-Security-Policies-and-Regulations.md' 9 | - 'Software Development Methodologies': '01-Secure-Software-Concepts/04-Software-Development-Methodologies.md' 10 | - 'Secure Software Requirements': 11 | - 'Policy Decomposition': '02-Secure-Software-Requirements/01-Policy-Decomposition.md' 12 | - 'Data Classification and Categorization': '02-Secure-Software-Requirements/02-Data-Classification-and-Categorization.md' 13 | - 'Requirements': '02-Secure-Software-Requirements/03-Requirements.md' 14 | - 'Secure Software Design': 15 | - 'Design Processes': '03-Secure-Software-Design/01-Design-Processes.md' 16 | - 'Design Considerations': '03-Secure-Software-Design/02-Design-Considerations.md' 17 | - 'Securing Commonly Used Architecture': '03-Secure-Software-Design/03-Securing-Commonly-Used-Architecture.md' 18 | - 'Technologies': '03-Secure-Software-Design/04-Technologies.md' 19 | - 'Secure Software Implementation/Programming': 20 | - 'Common Software Vulnerabilities and Countermeasures': '04-Secure-Software-Implementation-Programming/01-Common-Software-Vulnerabilities-and-Countermeasures.md' 21 | - 'Defensive Coding Practices': '04-Secure-Software-Implementation-Programming/02-Defensive-Coding-Practices.md' 22 | - 'Secure Software Coding Operations': '04-Secure-Software-Implementation-Programming/03-Secure-Software-Coding-Operations.md' 23 | - 'Secure Software Testing': 24 | - 'Security Quality Assurance Testing': '05-Secure-Software-Testing/01-Security-Quality-Assurance-Testing.md' 25 | - 'Security Testing': '05-Secure-Software-Testing/02-Security-Testing.md' 26 | - 'Secure Lifecycle Management': 27 | - 'General Security Concepts': '06-Secure-Lifecycle-Management/01-Secure-Lifecycle-Management.md' 28 | - 'Software Deployment, Operations, and Maintenance': 29 | - 'Secure Software Installation and Deployment': '07-Software-Deployment-Operations-Maintenance/01-Secure-Software-Installation-and-Deployment.md' 30 | - 'Secure Software Operations and Maintenance': '07-Software-Deployment-Operations-Maintenance/02-Secure-Software-Operations-and-Maintenance.md' 31 | - 'Supply Chain and Software Acquisition': 32 | - 'Supply Chain and Software Acquisition': '08-Supply-Chain-Software-Acquisition/01-Supply-Chain-and-Software-Acquisition.md' 33 | - 'Terms': '09-Terms/Terms.md' 34 | - 'Outline': '10-Outline/Outline.md' 35 | 36 | theme: 37 | name: material 38 | language: "en" 39 | palette: 40 | # Light mode 41 | - media: "(prefers-color-scheme: light)" 42 | scheme: default 43 | primary: blue 44 | accent: indigo 45 | toggle: 46 | icon: material/toggle-switch-off-outline 47 | name: Switch to dark mode 48 | 49 | # Dark mode 50 | - media: "(prefers-color-scheme: dark)" 51 | scheme: slate 52 | primary: blue 53 | accent: deep purple 54 | toggle: 55 | icon: material/toggle-switch 56 | name: Switch to light mode 57 | 58 | font: 59 | text: Barlow 60 | code: Roboto Mono 61 | 62 | docs_dir: notes 63 | 64 | markdown_extensions: 65 | - mdx_truly_sane_lists 66 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Certified Secure Software Lifecycle Professional in bullet points 2 | 3 | [![Quality checks status](https://github.com/joeyhage/csslp-notes/workflows/Quality%20checks/badge.svg)](https://github.com/joeyhage/csslp-notes/actions) 4 | 5 | - This repo contains study notes for Certified Secure Software Lifecycle Professional (CSSLP) exam. 6 | - Good luck & enjoy studying! ☕ 7 | - Contributions of any kind are welcome! 8 | 9 | ## Symbols 10 | 11 | - There are some symbols used throughout the documentation: (TODO) 12 | 13 | | Symbol | Description | 14 | | :----: | -------------------------------------------------- | 15 | | 💡 | Best practice or practical tips | 16 | | ❗ | An important limitation, challenge or an exception | 17 | | 📝 | Common exam area | 18 | 19 | ## Content 20 | 21 | 22 | 1. Secure Software Concepts 23 | 1. [General Security Concepts](./notes/01-Secure-Software-Concepts/01-General-Security-Concepts.md) 24 | 2. [Risk Management](./notes/01-Secure-Software-Concepts/02-Risk-Management.md) 25 | 3. [Security Policies and Regulations](./notes/01-Secure-Software-Concepts/03-Security-Policies-and-Regulations.md) 26 | 4. [Software Development Methodologies](./notes/01-Secure-Software-Concepts/04-Software-Development-Methodologies.md) 27 | 2. Secure Software Requirements 28 | 1. [Policy Decomposition](./notes/02-Secure-Software-Requirements/01-Policy-Decomposition.md) 29 | 2. [Data Classification and Categorization](./notes/02-Secure-Software-Requirements/02-Data-Classification-and-Categorization.md) 30 | 3. [Requirements](./notes/02-Secure-Software-Requirements/03-Requirements.md) 31 | 3. Secure Software Design 32 | 1. [Design Processes](./notes/03-Secure-Software-Design/01-Design-Processes.md) 33 | 2. [Design Considerations](./notes/03-Secure-Software-Design/02-Design-Considerations.md) 34 | 3. [Securing Commonly Used Architecture](./notes/03-Secure-Software-Design/03-Securing-Commonly-Used-Architecture.md) 35 | 4. [Technologies](./notes/03-Secure-Software-Design/04-Technologies.md) 36 | 4. Secure Software Implementation/Programming 37 | 1. [Common Software Vulnerabilities and Countermeasures](./notes/04-Secure-Software-Implementation-Programming/01-Common-Software-Vulnerabilities-and-Countermeasures.md) 38 | 2. [Defensive Coding Practices](./notes/04-Secure-Software-Implementation-Programming/02-Defensive-Coding-Practices.md) 39 | 3. [Secure Software Coding Operations](./notes/04-Secure-Software-Implementation-Programming/03-Secure-Software-Coding-Operations.md) 40 | 5. Secure Software Testing 41 | 1. [Security Quality Assurance Testing](./notes/05-Secure-Software-Testing/01-Security-Quality-Assurance-Testing.md) 42 | 2. [Security Testing](./notes/05-Secure-Software-Testing/02-Security-Testing.md) 43 | 6. Secure Lifecycle Management 44 | 1. [General Security Concepts](./notes/06-Secure-Lifecycle-Management/01-Secure-Lifecycle-Management.md) 45 | 7. Software Deployment, Operations, and Maintenance 46 | 1. [Secure Software Installation and Deployment](./notes/07-Software-Deployment-Operations-Maintenance/01-Secure-Software-Installation-and-Deployment.md) 47 | 2. [Secure Software Operations and Maintenance](./notes/07-Software-Deployment-Operations-Maintenance/02-Secure-Software-Operations-and-Maintenance.md) 48 | 8. Supply Chain and Software Acquisition 49 | 1. [Supply Chain and Software Acquisition](./notes/08-Supply-Chain-Software-Acquisition/01-Supply-Chain-and-Software-Acquisition.md) 50 | 9. [Terms](./notes/09-Terms/Terms.md) 51 | 10. [Outline](./notes/10-Outline/Outline.md) 52 | 53 | [↑](#content) 54 | -------------------------------------------------------------------------------- /notes/03-Secure-Software-Design/01-Design-Processes.md: -------------------------------------------------------------------------------- 1 | # Design Processes 2 | 3 | ## Attack Surface Evaluation 4 | 5 | - includes code, input fields, protocols, interfaces, files, and services 6 | - higher attack surface != bad code, it's just a measure of how many things can be attacked 7 | - turning off unused/unneeded features will minimize attack surface 8 | 9 | ### Attack Surface Management 10 | 11 | - measure # of ways it can be accessed 12 | - root cause of old/prev vulns can help fix them, prevent future, and determine attack surface 13 | - elements are not necessarily vulns, but hackers will attempt to compromise 14 | - cannot compare between software 15 | 16 | ### Attack Surface Minimization 17 | 18 | - turning off unnecessary elements (off by default) 19 | - only on when needed (certain users/times) 20 | - least privilege 21 | - document minimization throughout dev process 22 | - help lower defaults at deployment 23 | - allow customer to make decisions about options 24 | 25 | ## Threat Modeling 26 | 27 | - **team effort** 28 | - identify and document threats 29 | - describe mitigations 30 | 31 | ### Threat Model Development 32 | 33 | #### Identify Security Objectives 34 | 35 | - security AND privacy 36 | - business rationale for obtaining/storing data 37 | - dev team should not decide if/how to protect data - won't have visibility/breadth to know all threats 38 | 39 | #### System Decomposition 40 | 41 | - model system design using security reqs/objectives (data flow diagram is best) 42 | - include all processes, data stores, data flows 43 | - call out trust boundaries (where privilege changes) 44 | - for larger systems, break down DFD into scenario-based pieces 45 | - list/describe assumptions and dependencies 46 | 47 | #### Threat Identification 48 | 49 | - use STRIDE to create threat model 50 | 51 | | Threat | Security Property | 52 | | ---------------------- | ----------------- | 53 | | Spoofing | Authentication | 54 | | Tampering | Integrity | 55 | | Repudiation | Non-repudiation | 56 | | Information Disclosure | Confidentiality | 57 | | Denial of Service | Availability | 58 | | Elevation of Privilege | Authorization | 59 | 60 | #### Mitigation Analysis 61 | 62 | ##### Four types (in order of best to worst) 63 | 64 | 1. redesign to eliminate (generally early in SDL) 65 | 2. apply standard mitigation (e.g. ACL) 66 | 3. invent mitigation 67 | 4. accept vuln 68 | 69 | - attack tree model: help one understand threat 70 | - also need to prioritize threats 71 | - DREAD (damage potential, reproducibility, exploitability, affected users, discoverability) - 0 to 10 72 | - can be mapped to probability impact model (reproducibility + exploitability + discoverability) and (damage potential + affected users) 73 | 74 | #### Threat Model Validation 75 | 76 | - validate threat model at each SDL gate 77 | - do threats describe the attack and impact in detail relevant to app? 78 | - are mitigations associated with a threat and described in detail relevant to app? 79 | - dependencies 80 | - security functions of deps 81 | - assumptions documented 82 | 83 | ## Control Identification and Prioritization 84 | 85 | - prioritize enterprise security controls - it is more efficient (eliminates duplicate efforts) 86 | - use security of existing protocols (HTTPS, SSH) 87 | 88 | ## Risk Assessment for Code Reuse 89 | 90 | - using old code/libraries should be scrutinized just like new code 91 | 92 | ## Documentation 93 | 94 | - threat modeling and attack surface minimization docs can be very valuable if kept up to date 95 | 96 | ## Design and Architecture Technical Review 97 | 98 | - is the SDL achieving the desired objectives? 99 | -------------------------------------------------------------------------------- /notes/05-Secure-Software-Testing/01-Security-Quality-Assurance-Testing.md: -------------------------------------------------------------------------------- 1 | # Security Quality Assurance Testing 2 | 3 | quality = fitness for use according to requirements 4 | 5 | ## Standards for Software Quality Assurance 6 | 7 | ### ISO 9216 8 | 9 | - primary focuses: functionality, reliability, usability 10 | - other: efficiency, maintainability, portability 11 | 12 | ### SSE-CMM 13 | 14 | - **systems security engineering capability maturity model (aka ISO/IEC 21827)** 15 | - de facto standard for evaluating security engineering capability in an org 16 | 17 | ### OSSTMM 18 | 19 | - **Open Source Security Testing Methodology Manual** 20 | - peer-reviewed, scientific methodology 21 | 22 | #### five sections 23 | 24 | 1. data networks 25 | 2. telecommunications 26 | 3. wireless 27 | 4. human (e.g. social engineering, security awareness training) 28 | 5. physical security 29 | 30 | - training classes exist 31 | - methodology can assist in auditing 32 | 33 | ## Testing Methodology 34 | 35 | **Test harness**: means of documenting software, tools, test data, expected output, and configurations 36 | 37 | - break testing into test suites for reuse 38 | 39 | ## Functional Testing 40 | 41 | - assess functionality as expected by end user 42 | 43 | ### Steps 44 | 45 | 1. Identify functions (reqs) 46 | 2. create test data 47 | 3. determine expected output 48 | 4. execute tests corresponding to functional reqs 49 | 5. compare actual and expected 50 | 51 | ### Functional Testing Areas 52 | 53 | - reliability 54 | - logic 55 | - performance 56 | - scalability 57 | 58 | ### Unit Testing 59 | 60 | - functional logic 61 | - understandable code 62 | - reasonable vuln control and mitigation 63 | - **done early by dev team before dev phase is over** 64 | 65 | ### Integration/Systems Testing 66 | 67 | - includes secure and proper data transfer between components in a system 68 | 69 | ### Performance Testing 70 | 71 | - **load testing**: performance under normal conditions 72 | - **stress testing**: performance under overload conditions 73 | - **Recoverability**: app's ability to restore itself to expected functionality after security is breached/bypassed 74 | 75 | ### Regression Testing 76 | 77 | ## Security Testing 78 | 79 | ### White-Box testing 80 | 81 | - full knowledge of code and components 82 | - done early in dev cycle 83 | - focus on structure of software and use/misuse 84 | - high false positives 85 | 86 | ### Black-Box testing 87 | 88 | - common for system-level tests and pen testing 89 | - focus on behavior of app 90 | - high false positives 91 | 92 | ### Grey-Box Testing 93 | 94 | - not total access to source code but understanding of inner workings 95 | - rare outside of internal testing 96 | 97 | ## Environment 98 | 99 | - interoperability of all components including: 100 | - credentials 101 | - permissions 102 | - access tokens 103 | - data movement across trust boundaries 104 | - etc 105 | 106 | ## Bug Tracking 107 | 108 | - four types (same as options associated with risk): 109 | - removal of defect 110 | - mitigation 111 | - transfer of responsibility 112 | - ignore 113 | - track bugs so they eventually get addressed 114 | - logging bugs also provides metric of code quality 115 | - defect categories: 116 | - bugs (coding errors) 117 | - flaws (design error) 118 | - behavioral anomalies (how app operates) 119 | - errors/faults (outcome-based from other sources) 120 | - vulns (things that can be manipulated to misuse system) 121 | 122 | ### Defects 123 | 124 | - create defect database to track past and present issues 125 | - help understand what not to do/what not to repeat 126 | - provide testers with suggestions when looking for defects 127 | 128 | ### Bug Bar 129 | 130 | - set minimum level of quality for security at beginning of project 131 | 132 | ## Attack Surface Validation 133 | 134 | - document actual attack surface through SDLC 135 | 136 | ## Test Data Lifecyle Management 137 | 138 | - anonymization of production data iss very challenging and requires planning 139 | -------------------------------------------------------------------------------- /notes/02-Secure-Software-Requirements/01-Policy-Decomposition.md: -------------------------------------------------------------------------------- 1 | # Policy Decomposition 2 | 3 | ## NIST Computer Security Policies 📝 4 | 5 | 1. **program policies:** foundational for infosec program 6 | 2. **issue-specific policies:** specific issues such as PII or data retention 7 | 3. **system-specific policies:** technical directives such as firewall rules 8 | 9 | Regulations and government directives are also sources of security requirements 10 | 11 | ## Confidentiality, Integrity, and Availability Requirements 12 | 13 | ### Confidentiality 14 | 15 | - Who is authorized to see what data 16 | - mechanism to enforce 17 | - business requirements with respect to data collection, transfer, storage, and use 18 | 19 | ### Integrity 20 | 21 | - who is authorized to alter what data 22 | - mechanism to detect errors and enforce 23 | - business requirements with respect to data collection, transfer, storage, and use 24 | 25 | ### Availability 26 | 27 | - available to authorized users when needed 28 | - deny unauthorized/illegitimate access 29 | - prevent DoS 30 | 31 | ## Authentication, Authorization, and Auditing Requirements 32 | 33 | ### Identification and Authentication 34 | 35 | Identity Requirements: 36 | 37 | - identity mechanism 38 | - mgmt of identities, incl. reaffirmations 39 | 40 | Authentication Requirements: 41 | 42 | - method of authentication 43 | - strength of authentication 44 | 45 | 📝 Three general authentication factors 46 | 47 | 1. Something you know 48 | 2. Something you have 49 | 3. Something you are 50 | 51 | - 📝 Most authentication is one party authenticating the other (bank auth. account holder) 52 | - 📝 Sometime mutual authentication is used (both parties authenticating each other simultaneously) to prevent MITM attacks 53 | 54 | ### Access Control Mechanisms 55 | 56 | #### Mandatory access control MAC 57 | 58 | - Much more restrictive 59 | - Access determined by security classification 60 | - Each subject and object has a label, operating system determines if access is granted 61 | - also implements "need to know" - just because a subject has appropriate clearance, does not mean they will be able to access 62 | 63 | #### Discretionary access control DAC 64 | 65 | - owner of object determines access levels 66 | - ACLs (access control lists) 67 | 68 | #### Role-based access control RBAC 69 | 70 | - doesn't use ACLs, uses roles (like AD groups) 71 | - users are assigned to roles and roles are assigned access 72 | 73 | #### Rule-based access control RBAC 74 | 75 | - Uses ACLs but adds rules into ACLs 76 | - MAC can use rule-based for implementation 77 | - rules can be things like dates/times access is allowed 78 | - users are not allowed to change rules 79 | 80 | #### Attribute-based access control (ABAC) 81 | 82 | - attributes/specific elements of the data/object are used to determine access 83 | - e.g. if a patient has a certain attribute (is receiving certain treatment), that determines which doctors/staff can access 84 | 85 | ### Auditing 86 | 87 | #### risk based issues 88 | 89 | 📝 audit related risk: 90 | 91 | 1. **inherent risk**: inherent error rate before controls 92 | 2. **detection risk**: audit will not detect it 93 | 3. **control risk**: controls will not detect or prevent in a timely fashion 94 | 95 | #### Organizational characteristics 96 | 97 | Examples: 98 | 99 | - organizational history 100 | - business env 101 | - supervisory issues 102 | 103 | **organizational security elements:** 104 | 105 | - roles and responsibilities 106 | - separation of duties 107 | - training and qualifications 108 | - change mgmt 109 | - control mgmt 110 | 111 | ## Internal security reqs 112 | 113 | Items used by the system to protect data and communications, for example: 114 | 115 | - protect audit logs 116 | - manage data loss prevention elements 117 | - monitor internal system traffic 118 | - monitor internal controls 119 | - protect configuration files 120 | 121 | ## External security reqs 122 | 123 | statutory and regulatory regulations, contractual obligations, for example: 124 | 125 | - use security controls to manage external connections 126 | - manage external connections and authentication 127 | - content filtering and proxies to protect against web-based threats 128 | -------------------------------------------------------------------------------- /notes/02-Secure-Software-Requirements/02-Data-Classification-and-Categorization.md: -------------------------------------------------------------------------------- 1 | # Data Classification and Categorization 2 | 3 | ## Data Classification 4 | 5 | types of classification: 6 | 7 | - state 8 | - use 9 | - importance 10 | 11 | **classification is for risk management** - reduce costs associated with protecting data 12 | 13 | - match level of protection and cost with value of asset 14 | 15 | ### Data States 16 | 17 | - at rest 18 | - being created 19 | - in transit 20 | - being changed/deleted 21 | 22 | data storage location should be considered as well 23 | 24 | ### Data usage 25 | 26 | - determining how it is used can help determine how it should be shared (or not) 27 | 28 | Usage classifications 29 | 30 | - **Internal** - created, computed, stored (in memory) within application 31 | - **Input** - read into system and possibly stored 32 | - **Output** - written to output destination 33 | 34 | Sensitivity categories 35 | 36 | - **Security-sensitive** - subset of data, very valuable to attacker 37 | - **PII** 38 | - **Hidden** - concealed using obfuscation to protect from unauthorized disclosure 39 | 40 | ### Data Risk Impact 41 | 42 | - 📝 labeled according to risk if lost (high, medium, low) 43 | - will differ from firm to firm 44 | - 📝 impact considerations include cost, operation impact, people impact, customer impact 45 | 46 | ## Data ownership 47 | 48 | - data is not owned by a person, it is owned by the enterprise 49 | - data is assigned to people for stewardship/ownership for practical reasons 50 | - **ownership is business driven** 51 | 52 | ### Owner 53 | 54 | - acts in the interests of the enterprise 55 | - determines who has what access 56 | - owner != custodian (e.g. CFO owns accounting records but DBA can make direct changes) 57 | - 📝 data owners define data classification, authorized users, access criteria, and security controls 58 | 59 | ### Custodian 60 | 61 | - ensure processes safely transport, manipulate, and store data 62 | - ensure data management processes (set by owner) are followed 63 | - 📝 perform backups, data retention, disposal 64 | - 📝 manage anything else (e.g. security controls) defined by owner 65 | - custodians may not need read access 66 | 67 | ## Labeling 68 | 69 | ### Sensitivity 70 | 71 | - built around business purpose 72 | 73 | ### Impact 74 | 75 | - wider concern than sensitivity 76 | - includes loss, disclosure, and alteration 77 | - three levels (high, medium or moderate, low) - each level should be clearly defined 78 | - 📝 NIST FIPS 199 and SP 800-18 provide framework for classifying based on CIA 79 | 80 | #### Clearly Defining levels 81 | 82 | - high: set high enough that a small number of data elements are included 83 | - financial limits and customer impact vary, each company needs to decide for itself 84 | 85 | ## Types of data 86 | 87 | ### Structured 88 | 89 | - has a defined structure that can be parsed, sorted, searched 90 | - 📝 is not determined by where it is stored, but how 91 | - 📝 look for relationships between data elements 92 | 93 | examples: 94 | 95 | - tables in a database 96 | - formatted file structures 97 | - XML 98 | - JSON 99 | - certain text files like log files 100 | 101 | ### Unstructured 102 | 103 | - not easily parsed/searched 104 | - more difficult to modify outside originating application (word docs, pdfs) 105 | - majority of data is unstructured 106 | 107 | ## Data lifecycle 108 | 109 | - cost of storing data is still a resource issue despite lower costs 110 | - must be managed from backup, business continuity, disaster recovery perspective 111 | 112 | ### Generation 113 | 114 | if data is going to be persistent, need to label, classify, protect 115 | 116 | ### Retention 117 | 118 | if retained, must have metadata defined such as: 119 | 120 | - data owner 121 | - purpose of storing 122 | - level of protection 123 | - length of storage (retention policy) 124 | 125 | protection must also consider how to protect backups and copies for DR 126 | 127 | **System logs**: are considered important from a legal/compliance perspective, often have sensitive info that needs to be protected 128 | 129 | ### Disposal 130 | 131 | primary purposes of disposal: 132 | 133 | 1. conserve resources 134 | 2. limit liabilities 135 | 136 | 📝 Length of storage is determined by: 137 | 138 | 1. business purpose 139 | 2. compliance 140 | 141 | Legal hold data is not subject to normal disposal procedures 142 | -------------------------------------------------------------------------------- /notes/03-Secure-Software-Design/02-Design-Considerations.md: -------------------------------------------------------------------------------- 1 | # Design Considerations 2 | 3 | ## Application of Methods to Address Core Security Concepts 4 | 5 | ### Confidentiality, Integrity, and Availability 6 | 7 | - need to be considered/added during design phase 8 | - Examples of tools: 9 | - Confidentiality -> encryption 10 | - Integrity -> hashing 11 | - Availability -> recovery 12 | 13 | #### Confidentiality 14 | 15 | - data at rest usually encrypted differently than data in transit 16 | - data needed to be confidential in use (encryption key), requires specific attention 17 | - after elements needing to be kept confidential are determined, next need to determine authorized parties 18 | 19 | #### Integrity 20 | 21 | - controls update and delete 22 | - first aspect is applying controls (e.g. ACLs) 23 | - second aspect (just as important) is determining if data _has_ been altered 24 | - digests should be stored and transmitted separately 25 | 26 | #### Availability 27 | 28 | - system is available to _authorized_ users when appropriate 29 | - many options including backups, data replication, fail-overs 30 | - just need to determine the need and write a requirement 31 | 32 | ### Authentication, Authorization, and Auditing 33 | 34 | - generally, best to integrate with the existing enterprise environment and/or operating system 35 | 36 | #### Authentication 37 | 38 | - if incorrect, everything else is wrong 39 | - determine level of confidence needed 40 | - use OS methods when possible, otherwise follow design patterns 41 | 42 | #### Authorization 43 | 44 | - use OS methods when possible, otherwise follow design patterns 45 | 46 | #### Accounting (Audit) 47 | 48 | - logging activity 49 | - during design, determine what should be logged and when 50 | - include error trapping and log what devs need to debug problem 51 | - if sensitive data is logged, encryption is needed 52 | - don't log data like PII or paths/filenames 53 | 54 | ## Secure Design Principles 55 | 56 | - security designer uses information from attack surface analysis and threat model 57 | 58 | ### Good Enough Security 59 | 60 | - security should match risk associated with potential vulnerability 61 | 62 | ### Least Privilege 63 | 64 | - natural set of defenses when unexpected things happen 65 | 66 | ### Separation of Duties 67 | 68 | - useful when multiple conditions must be met 69 | 70 | ### Defense in Depth 71 | 72 | - multiple overlapping defenses, dissimilar in nature (e.g. encryption and ACLs) 73 | - one of the oldest security principles 74 | - wider range of threats more efficiently 75 | - **Every piece of software can be compromised/bypassed in some way** 76 | 77 | ### Fail Safe 78 | 79 | - what happens when an element fails? 80 | - degrade gracefully and return to normal through the shortest path 81 | 82 | ### Economy of Mechanism 83 | 84 | - Smaller and simpler = easier to secure 85 | - Extensibility and reuse improve stability 86 | - simple to troubleshoot, expand, use, and administer 87 | 88 | ### Complete Mediation 89 | 90 | - perform authorization checks for sensitive operations 91 | - don't assume a subject has permission 92 | 93 | ### Open Design 94 | 95 | - open communication 96 | - accessible and understandable designs 97 | 98 | ### Least Common Mechanism 99 | 100 | - reusing existing components can create pathways between users/processes 101 | - determine balance between reuse and separation 102 | 103 | ### Psychological Acceptability 104 | 105 | - users are key to system and security 106 | - if security obstructs the user and user disagrees, user will find a workaround 107 | - ensure abnormal system behavior is comprehensible to the user (i.e. don't say, "contact your sysadmin") 108 | 109 | ### Weakest Link 110 | 111 | - analyze local and system views of an application 112 | - prevent local errors from becoming system failures 113 | 114 | ### Leverage Existing Components 115 | 116 | - reduces costs and simplifies programs but failures have larger footprints 117 | - legacy code and 3rd party code still need security reviews 118 | 119 | ### Single Point of Failure 120 | 121 | - single failure should not result in a system failure 122 | 123 | ## Inter-connectivity 124 | 125 | ### Session Management 126 | 127 | - prevent unauthorized party taking control of authorized communication 128 | - cross-party disclosure should not occur 129 | 130 | ### Exception Management 131 | 132 | - communicate error to user and log information 133 | 134 | ### Configuration Management 135 | 136 | - secure configuration files/elements 137 | 138 | ## Interfaces 139 | 140 | - determine method and level of integration with enterprise resources 141 | - in-band vs out-of-band management of application 142 | - creating separate management interface vs sending information to enterprise management system 143 | -------------------------------------------------------------------------------- /notes/03-Secure-Software-Design/03-Securing-Commonly-Used-Architecture.md: -------------------------------------------------------------------------------- 1 | # Securing Commonly Used Architecture 2 | 3 | ## Distributed Computing 4 | 5 | - affordable, smaller, powerful computing solutions led to more distributed computing architecture 6 | 7 | ### Client Server 8 | 9 | - server: processing and storage for numerous users 10 | - client (thin or thick/fat): single user, fat clients do most of processing themselves 11 | - multiple machines for processing increases need for security 12 | - "n-tier" model (n = # of application levels doing work) 13 | - user level, presentation level, business level, data access level, database level 14 | - cloud computing is an extreme case of client server. n-tier model can be implemented in different cloud models (SaaS, PaaS, IaaS) 15 | 16 | ### Peer-to-peer 17 | 18 | - file sharing and communication based systems 19 | 20 | ### Message Queuing 21 | 22 | - helps manage throughput and guarantee delivery 23 | - can also help with logging, security, and point to multi-point 24 | 25 | ## Service-Oriented Architecture (SOA) 26 | 27 | - distributed with specific characteristics 28 | - platform neutrality 29 | - interoperability 30 | - modularity and reusability 31 | - abstracted business functionality 32 | - contract-based interfaces 33 | - discoverability 34 | - several technologies like WS 35 | - most SOA uses XML 36 | - SOAP and REST and two common protocols for messaging in the ESB (enterprise service bus) 37 | 38 | ### Enterprise Service Bus 39 | 40 | - monitors and controls message routing 41 | - centralized architecture for communication between producers and consumers 42 | - can translate/transform communications 43 | - can convert between protocols (REST, JAVA, SOAP, etc) 44 | - handle defined events 45 | - perform message queuing and data flow mapping 46 | 47 | ### Web Services 48 | 49 | - machine readable description of the interface - web services description language (WSDL) 50 | 51 | #### REST 52 | 53 | - stateless manner 54 | 55 | #### JSON 56 | 57 | #### Universal Description, Discovery, and Integration (UDDI) 58 | 59 | - universal, platform-independent 60 | - dynamically discover and invoke web services 61 | - XML, protocol based registry that services can list themselves on worldwide 62 | - never widely adopted, generally only found inside orgs 63 | 64 | ## Rich Internet Applications (RIAs) 65 | 66 | - application with characteristics of a desktop application delivered over the internet (Facebook, many websites today) 67 | 68 | ### Client-Side Exploits/Threats 69 | 70 | - !! **input validation** !! 71 | 72 | ### Remote Code Execution 73 | 74 | - consequence of architectural decision that there is no distinction between code and data 75 | 76 | ## Pervasive/Ubiquitous Computing 77 | 78 | - IOT - seldom have security capabilities 79 | - each element/device of the system needs to be self-sufficient and self-reliant for security, safety, and stability 80 | 81 | ### Wireless 82 | 83 | - developers need to take responsibility for security of transmitted data - not expect the network to be secure 84 | 85 | ### Location-Based 86 | 87 | - A user's location can be abused 88 | - not all sensitive data is easily identified as sensitive - need to consider how it could be abused 89 | 90 | ### Constant Connectivity 91 | 92 | ### Radio Frequency Identification (RFID) 93 | 94 | - mostly used for contactless inventory 95 | - range from few meters to hundreds of meters (active, battery powered transponders) 96 | - radio frequency use has regulatory reqs (differs by country) 97 | 98 | ### Near-Field Communication (NFC) 99 | 100 | - RF over very short distances (few inches) 101 | - no setup for the user 102 | - sometimes used to initiate/bootstrap higher bandwidth transfers 103 | 104 | ### Sensor Networks 105 | 106 | - physical and environmental (rainfall, weather, communication efficiency, etc) 107 | - individual elements are called nodes 108 | - architecture depends on communication technology and objectives of network 109 | 110 | ## Mobile Applications 111 | 112 | - built with consideration of native constraints of the device 113 | - mobile apps can generally access a lot of information stored on the device 114 | 115 | ## Integration with Existing Architectures 116 | 117 | - modern enterprise will never have one form of architecture 118 | - cross-integration allows data reuse and increases utility of enterprise architecture 119 | 120 | ## Cloud Architectures 121 | 122 | term is new, concept has been in use for decades 123 | 124 | - on-demand self-service 125 | - broad network access 126 | - resource pooling 127 | - rapid elasticity 128 | - measured service 129 | 130 | ### Four cloud deployment models 131 | 132 | 1. Private cloud (one entity) 133 | 2. Public cloud 134 | 3. Community cloud (membership defined by shared concerns/use cases) 135 | 4. hybrid cloud (combination that remains separate but has common technology) 136 | 137 | ### SaaS 138 | 139 | - need to plan for and consider vendor use/storage of client data 140 | 141 | ### PaaS 142 | 143 | - can include SaaS and IaaS elements 144 | - as scale increases, so does operational savings 145 | 146 | ### IaaS 147 | -------------------------------------------------------------------------------- /notes/08-Supply-Chain-Software-Acquisition/01-Supply-Chain-and-Software-Acquisition.md: -------------------------------------------------------------------------------- 1 | # Supply Chain and Software Acquisition 2 | 3 | - avg four levels in supply chain 4 | 5 | ## Supplier risk assessment 6 | 7 | - **purpose**: identify and maintain appropriate set of risk controls within supply chain 8 | - 📝 **contents**: specific threats to org's supply chain, likelihood of occurrence, impact if realized 9 | 10 | ### Supply chain threat categories 11 | 12 | 1. installation of malicious logic in hardware/software 13 | 2. installation of counterfeit hardware/software 14 | 3. failure/disruption in production/distribution of critical product/service 15 | 4. reliance on malicious/unqualified service provider for technical service 16 | 5. installation of unintentional vulns in software/hardware 17 | 18 | ### Risk assessment for code reuse 19 | 20 | - reuse is more cost effective and ensures higher quality 21 | - however, failures have a bigger footprint (leveraging existing components) 22 | - define when reuse is safe and legitimate 23 | 24 | #### Creating a practical reuse plan 25 | 26 | - terms of use and negotiated liability for loss/damage should be stated in contracts 27 | - **Strategic planning activity** 28 | - part of risk mgmt plan 29 | - define types of reuse and plans for reuse 30 | - will reuse include open-source or other code/products/services? 31 | 32 | ### Intellectual property 33 | 34 | - true value of IP is abstract - strictly in the eye of the beholder 35 | - difficult for legal system to assign value to creativity and beyond material investment/time spent 36 | 37 | #### Copyrights 38 | 39 | - gives creator right to determine who can use and conditions for use 40 | - can apply to source code 41 | - time limited 42 | - **Regulations** 43 | - Computer Software Rental Amendments Act of 1990: rental, lease, lending without authorization is forbidden 44 | - Copyright Law: distribution of copies w/o authorization is illegal 45 | 46 | #### Patents 47 | 48 | - novel inventions 49 | - not a secret 50 | - time limited 51 | 52 | #### Trademarks 53 | 54 | - protect image, phrase, name, branding 55 | - doesn't usually apply to code, but to program names/elements 56 | 57 | #### Trade secrets 58 | 59 | - difficult to employ because code can be reverse engineered 60 | 61 | #### Licensing 62 | 63 | - used to protect IP 64 | - agreement between owner (licensor) and user (licensee) for payment (fee/royalty) 65 | 66 | #### Code escrow 67 | 68 | - form of protection for the customer 69 | - copy of code is given to a neutral third party (escrow agent) 70 | - access to code is only given under specific circumstances (business failure of supplier, termination of product line) 71 | 72 | ### Legal Compliance 73 | 74 | - failure to comply can result in legal, financial, reputational, criminal consequences 75 | - issue is not ensuring controls exist but rather supplying objective evidence of compliance to legal/regulatory entities 76 | 77 | ### Supplier prequalification 78 | 79 | - product assurance 80 | - suppliers need to prove they are capable of developing/integrating a secure product 81 | - what is the supplier's history with similar projects? 82 | - what is their documented ability to adopt good software engineering practices? 83 | - do they employ trustworthy subcontractors? 84 | 85 | #### Assuring a black box: COTS 86 | 87 | - need mutually agreed upon approach between customer/supplier to determine which vendors can be trusted in a supply chain 88 | - customer needs to determine precise form of each supplier's dev process 89 | - which trusted third-party should provide the prequalification? 90 | 91 | #### ISO 15408: The Common Criteria 92 | 93 | - National Information Assurance Program (NIAP) in the US is a third-party registry system 94 | - built around common criteria 95 | 96 | ##### Benefits 97 | 98 | 1. acquisition community has objective, independent assurance of trust 99 | 2. supplier can gauge own capability and improve 100 | 101 | ## Supplier Sourcing 102 | 103 | - consider what subcontracts will and won't be allowed to do 104 | - consider foreign influence (orgs/nation-states not friendly to US) 105 | - rank bids on risk vs return score 106 | 107 | Security Tradeoffs 108 | 109 | - strategic improvement vs maintenance 110 | - changes/modernization can increase security risk 111 | - high vs low risk 112 | - high risk is not necessarily bad - just needs to be managed and balanced 113 | - org can only take on so much risk at one time 114 | - impact of one supplier on another 115 | - every new supplier will likely affect and/or be affected by current supply chain 116 | - opportunity costs 117 | - large current investment could delay better, future opportunities 118 | 119 | ### Managed services 120 | 121 | - involve continuous customer-supplier interaction 122 | - need to be continuously checked 123 | 124 | ### Service level agreements 125 | 126 | - legal binding agreement regarding required level of performance 127 | - rules of SLAs: 128 | - describe product/service functions in sufficient detail 129 | - clear means of determining if level of performance was met 130 | - normally addresses: 131 | - usage 132 | - ownership 133 | - warranty 134 | - licensing rights 135 | - etc 136 | 137 | ## Software Development and Testing 138 | 139 | - security testing controls evaluate technical, process, and resource/operational risks 140 | 141 | ## Software Delivery, Operations, and Maintenance 142 | 143 | - software authenticity requires controls to ensure non-repudiation of origin 144 | 145 | ## Supplier Transitioning 146 | -------------------------------------------------------------------------------- /notes/06-Secure-Lifecycle-Management/01-Secure-Lifecycle-Management.md: -------------------------------------------------------------------------------- 1 | # Secure Lifecycle Management 2 | 3 | ## Introduction to Acceptance 4 | 5 | ### Software Qualification (Acceptance) Testing 6 | 7 | - customer determines if software meets acceptance criteria 8 | - assess contract, standard, and legal reqs under both normal and abnormal conditions 9 | - **cumulative failure profile** 10 | - plot cumulative failures vs suitable time base 11 | - most appropriately applied during acceptance phase 12 | - negative slope indicates increasing reliability 13 | 14 | ### Qualification Testing Plan 15 | 16 | - scope, approach, resources, schedule 17 | - design and execution of tests is normally defined in the contract 18 | - **goal**: smallest # of test cases to sufficiently affirm quality and security of product 19 | 20 | #### Testing plan components 21 | 22 | 1. required features to test 23 | 2. requisite load limits 24 | 3. number/types of stress tests 25 | 4. risk mitigation and security tests 26 | 5. required performance levels 27 | 6. interfaces to be tested 28 | 7. test cases to address 29 | 1. who generates test designs/cases/procedures? 30 | 2. who executes the tests? 31 | 3. who builds/maintains test bed? 32 | 4. who manages config? 33 | 5. what are criteria for stopping testing? 34 | 6. what are criteria for restarting testing? 35 | 7. when will code be under change control/freeze? 36 | 8. which tests will be under config mgmt? 37 | 9. what level will anomaly reports be written for? 38 | 39 | ### Qualification Testing Hierarchy 40 | 41 | - activities at acceptance level: 42 | - design traceability anlsys 43 | - design evaluation 44 | - design interface anlsys 45 | - test plan generation 46 | - test design generation 47 | - evaluate documentation of each unit 48 | 49 | ## Pre-release Activities 50 | 51 | - total product assurance is not necessarily achievable due to complex and dynamic nature of software 52 | 53 | ### Implementing Pre-release testing process 54 | 55 | - software test plan describes objectives, scope, approach, and focus 56 | - helps people outside testing group understand why and how 57 | - detailed enough to be useful but not so much that those outside group cannot understand 58 | 59 | ### Completion Criteria 60 | 61 | - progress milestones are used as evidence of readiness for delivery 62 | - tangible outcome or action 63 | - criteria can be decomposed into metrics 64 | - ISO 9126 65 | - functionality 66 | - reliability 67 | - usability 68 | - efficiency 69 | - maintainability 70 | - portability 71 | 72 | ### Risk Acceptance 73 | 74 | - properties to consider to stay secure within acceptable limits: 75 | - implicit/explicit safety reqs 76 | - implicit/explicit security reqs 77 | - degree of complexity 78 | - performance factors 79 | - reliability factors 80 | 81 | Evaluation process should answer two questions 82 | 83 | 1. what is level of certainty of risk (likelihood)? 84 | 2. what is anticipated impact (loss)? 85 | 86 | - risk assessment requires detailed knowledge of risks and consequences of software. Included in threat model which is created as part of SDLC 87 | - **threat picture/situational assessment:** targeted risk assessments that only apply to known vulns at a specific time 88 | 89 | ## Post-release Activities 90 | 91 | - typically not done by dev team 92 | - best described as config mgmt 93 | - first, perform complete audit of installed config 94 | 95 | ### Validation and Verification 96 | 97 | - also apply to all stages of software lifecycle 98 | - activities are documented in the software validation and verification plan (SVVP) 99 | - **validation**: are we building the correct product? (i.e. meets user reqs) 100 | - **verification** are we building the product correctly? (i.e. proper software construction) 101 | - the SVVP should specify administrative reqs for: 102 | - anomaly resolution and reporting 103 | - exception/deviation policy 104 | - baseline and config control procs 105 | - standards practices and conventions adopted for guidance 106 | - form of relevant docs, including plans, procs, cases, and results 107 | 108 | #### Management V&V 109 | 110 | - examine plans, schedules, reqs, methods for assessing suitability 111 | - supports decisions about corrective actions, allocation of resources, and project scoping 112 | - support mgmt personnel who are responsible for system 113 | - discover and report variations from plans/procs 114 | - may involve the following mgmt roles: 115 | - decision maker 116 | - review leader 117 | - review recorder 118 | - mgmt staff 119 | - tech staff 120 | - customer/user rep 121 | 122 | #### Technical V&V 123 | 124 | - eval product, reqs/design docs, code/test/user docs/manuals/release notes, build/install procs 125 | - does product conform to specs? adhere to regs, standards, and plans? correctly implemented/changed? 126 | - support customer's/supplier's technical/mgmt personnel 127 | - discover/report defects and anomalies 128 | - may involve following mgmt roles: 129 | - decision maker 130 | - review leader 131 | - review recorder 132 | - tech staff/tech managers 133 | - customer/user tech staff 134 | - should be scheduled as part of initial project planning 135 | - ad hoc reviews may also be scheduled 136 | 137 | ### Independent Testing 138 | 139 | - carried out by disinterested third party so customer and supplier trust integrity 140 | - often called IV&V (audit) 141 | - ensure customer/supplier have no influence over findings of testers 142 | - items that may be audited: 143 | - plans 144 | - contracts 145 | - complaints 146 | - procs 147 | - reports/docs 148 | - source code 149 | - deliverables 150 | - conducted by single person (lead auditor) 151 | - audit usually not initiated by producer 152 | - closing meeting report includes: 153 | - prelim conclusions 154 | - problems 155 | - recommendations for remediation 156 | - once closing report is accepted, final report itemizes: 157 | - purpose and scope 158 | - name of audited org 159 | - software audited 160 | - applicable regs/standards 161 | - audit eval criteria 162 | - observation list classifying anomalies as major/minor 163 | - timing of audit follow-up activities 164 | -------------------------------------------------------------------------------- /notes/01-Secure-Software-Concepts/02-Risk-Management.md: -------------------------------------------------------------------------------- 1 | # Risk Management 2 | 3 | - **assess the impact if an adverse event were to happen decide what could be done to control that impact as deemed necessary** 4 | 5 | Well formed risk statement includes: 6 | 7 | 1. asset 8 | 2. threat 9 | 3. vulnerability 10 | 4. mitigation 11 | 5. impact 12 | 6. probability 13 | 14 | ## Risk 15 | 16 | Systematic risk 17 | 18 | - fire, theft, software bugs - mitigated through diversification 19 | - predictable under stable circumstances 20 | Unsystematic risk 21 | - recession, epidemics, protocol design errors 22 | - come from sources that are difficult to predict 23 | 24 | ### Business risk 25 | 26 | - operation of a business as a business 27 | 28 | Examples: 29 | 30 | - Treasury management (financial risk) 31 | - holdings in bonds, futures, currencies, etc 32 | - Revenue management 33 | - Contract management 34 | - Fraud 35 | - deliberate deception 36 | - Regulatory 37 | - Business continuity 38 | - Technology 39 | 40 | ### Technology risk 41 | 42 | - technology used in development process as well as software functionality 43 | 44 | Examples: 45 | 46 | - Security - protective attributes 47 | - Privacy - attributes that define access/sharing 48 | - Project risk management 49 | - Change management 50 | 51 | ### Risk controls 52 | 53 | - 📝 best method for managing risk in software 54 | - 📝 Understanding environment and risk and applying controls should be owned by development team 55 | 56 | Three classes: 57 | 58 | 1. Administrative 59 | 2. Technical 60 | 3. Physical 61 | 62 | For each class, there are four types of controls 63 | 64 | 1. Preventative 65 | 2. Detective 66 | 3. Corrective 67 | 4. Compensating 68 | 69 | #### Preventative 70 | 71 | - primary control 72 | - proactive 73 | - best mitigation 74 | - **goal**: stop attack 75 | 76 | Examples: 77 | 78 | - separation of duties 79 | - adequate documentation 80 | - physical control over assets 81 | - authorization mechanisms 82 | 83 | #### Detective 84 | 85 | - reactive 86 | - **goal**: detect presence of attack 87 | 88 | Examples: 89 | 90 | - logs 91 | - audits 92 | - inventories 93 | 94 | #### Corrective 95 | 96 | - after a vulnerability is exploited 97 | - **goal**: reduce total impact 98 | 99 | #### Compensating 100 | 101 | - when primary controls fail 102 | - reactive 103 | - defense in depth 104 | 105 | Example: separation of duties is a preventitve control to prevent fraud, financial review of reports is an after the fact compensating control 106 | 107 | #### Controls framework 108 | 109 | - managing risk as part of a complete system 110 | 111 | ## Qualitative 112 | 113 | - **Subjectively determine impact of an event - involves experts and group consensus** 114 | 115 | Two aspects: impact and probability 116 | 117 | ### Qualitative matrix 118 | 119 | #### Failure mode effects analysis (FMEA) 120 | 121 | - assess failures and effects on the system 122 | - for each issue, elements are defined 123 | - severity of risk is defined (1-10) 124 | - probability (1-10) 125 | - detectability (1-10) 126 | - calculate product (over 200 / 1000 worth looking at) 127 | 128 | ## Quantitative 129 | 130 | - **Objectively determine impact of an event - involves use of metrics and models** 131 | 132 | - use historical loss and trends to predict future loss 133 | - highly dependent on historical loss data 134 | - assuming constant risk rate is not an agreed upon concept 135 | 136 | key info: 137 | 138 | - important to come to consensus on values being used 139 | - use consistent values 140 | - models can never replace judgement and experience, but can enhance decision making 141 | 142 | ### Single loss expectancy (SLE) 143 | 144 | 📝 SLE = asset value \* (exposure factor or duration) 145 | 146 | ### Annualized rate of occurrence (ARO) 147 | 148 | 📝 ARO = number of events / number of years covered 149 | 150 | ### Annualized loss expectancy (ALE) 151 | 152 | 📝 ALE = SLE \* ARO 153 | 154 | ## Residual Risk Model 155 | 156 | - Absolute security is not achievable 157 | 158 | Example: 159 | 160 | - potential loss of $100k 161 | - firewall blocks 95% 162 | - IDS (intrustion detection system) is 80% effective 163 | - IRT (incident response team) is 50% effective 164 | - 100k \* 95% + (5k \* 80% \* 50%) = 97k with 3k residual 165 | 166 | ### ROI 167 | 168 | - 📝 ROI % = (avoided loss - control cost) / control cost \* 100 169 | - 📝 ROI time = avoided annual loss / annual control cost 170 | 171 | ## Governance, Risk, and Compliance 172 | 173 | - **Governance**: sum of exective actions that manage risk 174 | - need to comply with laws and regulations, so GRC terms are used synonomously 175 | - **Compliance**: activities associated with external requirements (contractual, policy, strategic, industry, regulations, laws) 176 | - **Conformance**: activities associated with internal requirements (org policies/standards) 177 | - Compliance gets priority over conformance 178 | - many reasons, primary being penalties 179 | 180 | ### Legal 181 | 182 | Two key legal issues with significant risk 183 | 184 | 1. intellectual property 185 | 1. legal action provides some protection but not against unknown criminals 186 | 2. data breach 187 | 188 | ### Standards 189 | 190 | - established norms 191 | - **goal**: define rules to ensure specified level of quality 192 | 193 | ## Risk Management Models 194 | 195 | ### General Risk Management Model 196 | 197 | 1. Asset identification 198 | 1. includes classification 199 | 2. Threat assessment 200 | 1. threats and vulnerabilities for each asset 201 | 2. likelihood of occurrence 202 | 3. Impact determination and quantification 203 | 1. Tangible: financial loss, physical damage 204 | 2. Intangible: reputation 205 | 4. Control design and evaluation 206 | 1. Decide which controls to implement 207 | 5. Residual Risk Management 208 | 1. Identify additional controls needed to reduce residual risk 209 | 210 | ### Software Engineering Institute Model 211 | 212 | 1. Identify - list potential risks 213 | 2. Analyze - impact, probability - classify and prioritize risks 214 | 3. Plan - Decide actions to take and implement mitigation 215 | 4. Track - Monitor and review risks and mitigations 216 | 5. Control - make corrections as needed 217 | -------------------------------------------------------------------------------- /notes/07-Software-Deployment-Operations-Maintenance/02-Secure-Software-Operations-and-Maintenance.md: -------------------------------------------------------------------------------- 1 | # Secure Software Operations and Maintenance 2 | 3 | - **Sustainment**: post-coding operations and maintenance 4 | - ISO 12207:2017 (software lifecycle processes) includes five processes 5 | - two of the five are operations and maintenance 6 | - better to combine operations and maintenance into one process 7 | 8 | ## Secure Software Operations 9 | 10 | - operate software in intended environment 11 | - one of the most expensive items in budget of an IT org 12 | 13 | ### Operations Process Implementation 14 | 15 | 1. monitor and assure effective everyday use 16 | 2. document and track problem reports and requests for change 17 | 18 | #### Connecting operation to change 19 | 20 | - operations reports issues or requests for change to the configuration management team and product stakeholders 21 | 22 | #### Planning for secure operation 23 | 24 | - secure sustainment of a product within a particular environment 25 | 26 | #### Operational monitoring and control 27 | 28 | - operations function is responsible for routine testing 29 | - developer may need to operate new product concurrently with previous version for a specified period to ensure it conforms to requirements 30 | 31 | #### Customer support 32 | 33 | - operations provides advice and product support to customers as needed 34 | - can also include scheduled training 35 | - each request and actions taken should be recorded as part of config mgmt process 36 | 37 | #### Ensuring service operation 38 | 39 | - demonstrate compliance with defined criteria/SLA 40 | - should identify and monitor potential risks in performance 41 | 42 | ## Software Maintenance Process 43 | 44 | - provide cost-effective modifications and support for all software in org's portfolio 45 | - ad hoc services for org's stakeholders 46 | 47 | 📝 study security aspects of all maintenance activities 48 | 49 | ### Monitoring 50 | 51 | - monitor system within target environment 52 | - respond to incidents 53 | - maintain trust among stakeholders that system is secure and operating correctly 54 | - need to prioritize review of systems since it may be impossible to monitor everything completely 55 | - professionals on review team should have a sustainment focus while also have technical aptitude to participate in design/code reviews 56 | - also need to interpret existing test results to ensure they adhere to test plans 57 | - software needs to expose alerts/logs in order to be monitored 58 | 59 | ### Incident management 60 | 61 | - can be caused by anything from user errors to hacking/malicious activity 62 | - reacting to unforeseen events add extra challenges because mitigation steps have not been planned in advance 63 | 64 | #### Monitoring and incident identification 65 | 66 | - initiated when a _potentially_ harmful event occurs 67 | - purpose of incident identification: distinguish between vulnerability in code, exploit of software, and user error 68 | - purpose of incident monitoring: identify as quickly as possible 69 | - can include tests, reviews, audits of logs, automated incident mgmt systems, dynamic testing tools, code scanners 70 | 71 | #### Incident reporting and management control 72 | 73 | - report incident type and assessed impact to incident manager 74 | - routine code defects should be reported as well as intentional things like trapdoors 75 | - incident response team: trained specialists (like fire dept) that follow a process to ensure the best possible response 76 | - also limit additional damage and study circumstances to prevent future occurrence 77 | 78 | #### Anticipating potential incidents 79 | 80 | - incidents are either potential or active 81 | - Potential incidents: defects that don't appear to have a present threat, unforeseen flaws, security vulnerabilities in OS/vendor software (e.g. Microsoft) 82 | 83 | #### Responding to active incidents 84 | 85 | - incident response team handles and supervises patch/change to target system 86 | - incident response process should be strategically planned and have flexibility in execution 87 | 88 | #### Establishing a structured response 89 | 90 | - essential to develop procedures for precise steps to be taken for passive and active incidents 91 | - include who is authorized to initiate incident response and how much authority is required to direct a response 92 | 93 | #### Ensure enough resources 94 | 95 | - deploy appropriate response and not overreact 96 | - start with a subset of resources and then decide if it needs to be escalated 97 | 98 | #### Managing the incident response team 99 | 100 | - team should include: 101 | - experienced team manager 102 | - expert software analysts/programmers 103 | - cybersecurity and computer crime specialists 104 | - sometimes, legal/government/public affairs experts 105 | 106 | ### Problem management 107 | 108 | - Type: corrective, improvement, preventative, adaptive action that might be required 109 | - Scope: modification size, cost, time 110 | - Criticality: impact of change on performance, safety, security of org 111 | 112 | ### Change management 113 | 114 | - primary purpose: protect enterprise from risk associated with changing functioning systems 115 | 116 | #### Patching 117 | 118 | - can be labeled as patches, hot-fixes, quick fix engineering (QFE) 119 | - what does patch repair and is it necessary to do so in prod? 120 | - patches are often bundled together in service packs or included in release schedule 121 | 122 | ### Backup, recovery, archiving 123 | 124 | - important to backup software and data so it can be restored 125 | - use encryption to protect backups 126 | - retention cycle: complete set of backups needed to restore data 127 | - needs to be stored within retention period 128 | 129 | ## Secure DevOps 130 | 131 | - frequent, smaller changes are faster to implement, faster to test, faster to correct 132 | - high level of automation 133 | 134 | ## Secure Software Disposal 135 | 136 | - old systems retain information even after disposed of 137 | - need to ensure information is secured 138 | - software/system can only be retired at request of owner 139 | - 📝 end-of-life policies should include criteria, notice of hardware/software being discontinued/replaced, duration of support for tech difficulties from date of sale and how long after EOL is published 140 | -------------------------------------------------------------------------------- /notes/09-Terms/Terms.md: -------------------------------------------------------------------------------- 1 | # Terms 2 | 3 | ## Secure Design Tenets 4 | 5 | ### Good Enough Security 6 | 7 | Appropriate level of security for any given system. 8 | 9 | ### Least Privilege 10 | 11 | Programs and users (subjects) should only have the bare minimum rights and privileges to perform current task 12 | 13 | ### Separation of Duties 14 | 15 | More than one person needs to be involved for any given task so no single person can abuse the system 16 | 17 | ### Defense in Depth 18 | 19 | A.k.a. layered security or diversity defense. 20 | 21 | Software should have multiple layers of defenses that are dissimilar in nature. ❗ True goal of security is to make the cost/time/effort of exploiting a system more than it is worth to an adversary. 22 | 23 | ### Fail-safe 24 | 25 | When a system fails, it should fail to a safe state. E.g. explicit deny 26 | 27 | ### Economy of Mechanism 28 | 29 | Greater system or software complexity generally results in worse security. Troubleshooting issues gets more difficult the more complex something is. This also includes turning off/disabling protocols and services that are not needed. 30 | 31 | ### Complete Mediation 32 | 33 | When a subject is authorized, verification should occur every time access to an object is requested. 34 | 35 | ### Open Design 36 | 37 | ❗ Security by obscurity does not provide actual security! 38 | 39 | ### Least Common Mechanism 40 | 41 | Multiple, different processes that share common mechanisms can lead to inadvertent sharing of information. Better to keep processes completely separate. 42 | 43 | ### Leverage Existing Components 44 | 45 | Reuse components so the attack surface of a system is reduced. ❗ This often results in a larger footprint when errors occur. 46 | 47 | ### Psychological Acceptability 48 | 49 | When securing a system or software, the controls should not obstruct the user and ease-of-use enough that the user is motivated to circumvent the controls. 50 | 51 | ### Weakest Link 52 | 53 | This is the common point of failure for all systems. A system is only as strong as its weakest link. 54 | 55 | ### Single Point of Failure 56 | 57 | An entire system should not fail if a single aspect fails. 58 | 59 | ## Access Control Models 60 | 61 | ### Mandatory Access Control 62 | 63 | Restrict access based on sensitivity of the information in the object and whether the subject is authorized to access information with that level of sensitivity. 64 | 65 | ### Discretionary Access Control 66 | 67 | The owner of an object specifies which subjects have access and what level of access each subject has. 68 | ❗ It is optional (discretionary) and requires owner to define access for all objects under its control. 69 | 70 | ### Role-based Access Control 71 | 72 | A user is assigned to any number of potentially overlapping roles. Roles are then assigned access. 73 | 74 | ### Rule-based Access Control 75 | 76 | Building rules into ACLs. Examples include time-of-day or network restrictions. 77 | 78 | ### Attribute-based Access Control 79 | 80 | Grant access based on attributes associated with the subject. 81 | 82 | ### Simple Security Rule 83 | 84 | Subjects can only read objects they are authorized to read. 85 | 86 | ## Risk Management Terms 87 | 88 | ### Risk 89 | 90 | Possibility of suffering harm/loss 91 | 92 | ### Inherent risk 93 | 94 | product of likelihood and impact prior to implementing controls 95 | 96 | ### Residual risk 97 | 98 | Remaining risk after control is utilized. Residual risk is owned by the entity 99 | 100 | ### Total risk 101 | 102 | Sum of all risks associated with an asset, process, or even a business 103 | 104 | ### Risk management 105 | 106 | Decision-making process of identifying threats and vulnerabilities, potential impacts, determining costs to mitigate, and deciding what actions are cost-effective 107 | 108 | ### Risk assessment (risk analysis) 109 | 110 | - Analyze environment to identify threats and vulnerabilities and mitigating actions to determine impact of an event 111 | - include specific threats, risk/impact for each threat, relationship between assets 112 | 113 | ### Asset 114 | 115 | Any resource or information an org needs to conduct business 116 | 117 | ### Vulnerability 118 | 119 | Any characteristic of an asset that can be exploited by a threat to cause harm 120 | 121 | ### Attack 122 | 123 | Attempting to perform undesired or unauthorized activities via a vulnerability 124 | 125 | ### Impact 126 | 127 | Resulting loss when a threat exploits a vulnerability 128 | 129 | ### Threat 130 | 131 | Any circumstance or event with the potential to cause harm to an asset 132 | 133 | ### Mitigate 134 | 135 | An action taken to reduce the likelihood of a threat occurring 136 | 137 | ### Control (a.k.a. countermeasure or safeguard) 138 | 139 | A measure taken to detect, prevent, or mitigate the risk associated with a threat. 140 | 141 | ### Qualitative risk assessment 142 | 143 | Subjectively determine impact of an event - involves experts and group consensus 144 | 145 | ## Quantitative Terms 146 | 147 | ### Quantitative risk assessment 148 | 149 | Objectively determine impact of an event - involves use of metrics and models 150 | 151 | ### Single loss expectancy (SLE) 152 | 153 | monetary loss or impact of each occurrence of a threat 154 | 155 | ### Exposure factor 156 | 157 | measure of magnitude of loss of an asset, used to calculate SLE 158 | 159 | ### Annualized rate of occurrence (ARO) 160 | 161 | how many times expected to occur annually 162 | 163 | ### Annualized loss expectancy (ALE) 164 | 165 | how much an event is expected to cost per year 166 | 167 | ## Supply Chain Terms 168 | 169 | ### COTS 170 | 171 | commercial off the shelf 172 | 173 | ### ICT 174 | 175 | information and communications technology 176 | 177 | ### TOE 178 | 179 | target of evaluation 180 | 181 | ## Secure Software Testing 182 | 183 | ### Entropy 184 | 185 | randomness collected by an OS or application for use in cryptography. High entropy results in a random number being generated with more randomness (e.g. not related to date/time) 186 | 187 | ## Secure Software Lifecycle Management 188 | 189 | ### Cumulative failure profile 190 | 191 | graphical method used to predict reliability, estimate additional testing time, identify modules/subsystems that require additional testing 192 | 193 | ## Secure Software Supply Chain Terms 194 | 195 | ### Provenance 196 | 197 | origin and license of third-party components used in software -------------------------------------------------------------------------------- /notes/01-Secure-Software-Concepts/04-Software-Development-Methodologies.md: -------------------------------------------------------------------------------- 1 | # Software Development Methodologies 2 | 3 | ## Secure Development Lifecycle (SDL) 4 | 5 | - add process checks to development process to include necessary security elements 6 | 7 | ### Principles 8 | 9 | - SMART - Specific, Measurable, Attainable, Realistic, Time bound 10 | 11 | ### Security vs Quality 12 | 13 | - quality = fitness for use or absence of defects 14 | - high quality != secure but low quality with lots of defects will have security issues from basic mistakes 15 | 16 | ### Security Features != Secure Software 17 | 18 | - encryption, authentication, and other security features can improve usability 19 | - secure software development is different: ensure all elements of software operate securely 20 | - adding security features may make software more marketable but secure software means it does what it was designed to do and only what it was designed to do 21 | 22 | ## Secure Development Lifecycle Components 23 | 24 | ### Software Team Awareness and Education 25 | 26 | - Basic knowledge 27 | - all should have 28 | - Advanced topics 29 | - only certain people need 30 | 31 | ### Gates and Security Reqs 32 | 33 | - eventually, if conducted in a firm and uniform manner, security is included as part of the normal business process 34 | 35 | ### Bug tracking 36 | 37 | - sometimes, bugs can be exploited and result in a potential security bug 38 | - 📝 DREAD (1-10 scale) 39 | - Risk = Impact \* Probability 40 | - Impact = Damage (in terms of CIA) and Affected Users (quantity) 41 | - Probability = Reproducibility (difficulty/scriptable?), Exploitability (attack difficulty), discoverability (difficulty to find) 42 | - detailed scoring is subjective and unreliable due to context/point of view 43 | - better to use a defined set of severities (critical, important/high, moderate/medium, low) 44 | - Bug bar - level at which a bug must be fixed in the current release 45 | - bugs are fixed based on risk, not ease of closure 46 | 47 | ### Threat modeling 48 | 49 | - basically an ARA 50 | - best performed during design phase 51 | - focused on how data moves through app 52 | - Threat model needs to include: app as a whole, security/privacy features, features that have security/privacy implications when they fail, features that cross trust boundaries 53 | - 📝 STRIDE (spoofing, tampering, repudiation, info disclosure, DoS, elevation of privilege) 54 | - Threat trees - graphical representation of what needs to exist for a threat to be realized (uses logical AND/OR) 55 | 56 | ### Fuzzing 57 | 58 | - random input 59 | - scan for buffer overflows, system crashes, etc 60 | - structured input 61 | - scan for injection vulns, XSS, input specific (arithmetic overflow, XXE, etc) 62 | - mutation 63 | - use sample data 64 | - input generation 65 | - based on models of system 66 | 67 | ### Security Reviews 68 | 69 | - audit process to verify functioning as desired 70 | - use at key places (between stages in SDL) 71 | - purpose: **NOT to test for security**, but to ensure steps are being done properly 72 | 73 | ### Mitigations 74 | 75 | Standard Techniques: 76 | 77 | 1. Do nothing 78 | 2. Warn user 79 | 3. Remove problem 80 | 4. Fix problem 81 | 82 | ## Software Development Models 83 | 84 | ### Waterfall 85 | 86 | - based on manufacturing design - each step completed before next step 87 | - linear, sequential, no repeating 88 | - useful for small pieces (incorporated into spiral/agile methods) 89 | - non-workable in practice 90 | 91 | ### Spiral 92 | 93 | - iterative, steps can be repeated iteratively 94 | - things are built incrementally 95 | - suited for large projects (may have several interconnected spirals) 96 | - smaller-scale version can be seen in some agile methods 97 | 98 | ### Prototype 99 | 100 | - based on manufacturing 101 | - throwaway - gain information on subset 102 | - evolutionary - build system through testing and adding features through accretion 103 | - vertical prototype - add more functionality (add back-end/database to front-end) 104 | - horizontal prototype - framework/infrastructure - adds features to one layer (build out entire front-end) 105 | - commonly used for software because it is modular 106 | - limits resources to test major elements and reduce risk 107 | - can be used in spiral/agile 108 | 109 | ## Microsoft Security Development Lifecycle 110 | 111 | - Goal: produce software that is secure, not software that performs security or has specific security features 112 | - Reduce # of security vulns 113 | - reduce severity of security vulns that remain 114 | - 2004 SD3+C 115 | - Secure by Design 116 | - Secure by Default 117 | - Secure in Deployment 118 | - Communications 119 | 120 | ### Secure by Design 121 | 122 | - review detailed designs 123 | - develop mitigations for all identified threats 124 | - consider legacy code and protocols 125 | - deprecate elements that are no longer secure 126 | 127 | #### Privacy by design 128 | 129 | - end-user control: enable end-user to make informed decisions about data collected, stored, shared 130 | - only collect and retain required info 131 | - use encryption to mitigate data loss issues 132 | - modular fashion in case it needs to be changed 133 | - proper crypto libraries/functions 134 | - proper key protection/rotation 135 | 136 | ### By Default 137 | 138 | - default config is as secure as possible 139 | - default config with privacy in mind 140 | - limit features turned on by default 141 | - if less than 80% will use, turn off by default 142 | - software should only operate with elevated rights when required 143 | - minimize attack surface by default 144 | - notify user if default config changes 145 | - limit services/daemons running by default 146 | 147 | ### In Deployment 148 | 149 | - one of last major touchpoints where config/settings are routinely modified 150 | - develop prescriptive deployment guides 151 | - How 152 | - Implications 153 | - options available to user 154 | - patching/upgrades should be built into deployment and give users control 155 | 156 | ### Communications 157 | 158 | - efficient channels between security response and dev teams 159 | - channel where dev team is connected to info sources like end-user issues/reports 160 | - communicate security changes to end-users 161 | - media/trade outlets to customers/prospective customers 162 | - White papers/technical documentation can improve effectiveness of security effort by reducing concerns/issues from customers (transparency) 163 | - Open communication = increased cooperative/coordinated efforts 164 | - Open communication != increased risk 165 | 166 | ## Microsoft SDL Components 167 | 168 | - started in 2002 169 | 170 | ### Training 171 | 172 | - targeted security training for all 173 | - training hour requirements 174 | - includes: 175 | - core training - prereq, basic knowledge 176 | - specialized modules for specific roles 177 | - new developments/practices in industry 178 | - may become part of core if becomes mainstream 179 | 180 | ### Requirements 181 | 182 | - establish security and privacy reqs for software 183 | - create quality gates and bug bars 184 | - develop security/privacy risk assessments 185 | 186 | ### Design 187 | 188 | - risk and privacy analyses 189 | - mitigated by design 190 | - attack surface reduction techniques 191 | - threat modeling for known and potential threats 192 | 193 | ### Implementation 194 | 195 | - approved languages, functions, libraries 196 | - remove deprecated functions 197 | - recode legacy code 198 | - static program checkers to maintain code standards 199 | 200 | ### Verification 201 | 202 | - known and potential vulns 203 | - review attack surface: does it match design 204 | - fuzz testing against inputs 205 | 206 | ### Release 207 | 208 | - prepare for potential issues coming in 209 | - prepare incident response plan 210 | - confirm all security elements completed and documented 211 | 212 | ### Response 213 | 214 | - collect error reports and handle per incident response plan 215 | - current release bug fixes through patches 216 | - future releases: mitigation 217 | -------------------------------------------------------------------------------- /notes/03-Secure-Software-Design/04-Technologies.md: -------------------------------------------------------------------------------- 1 | # Technologies 2 | 3 | ## Authentication and Identity Management 4 | 5 | ### Identity Management (IDM) and Identity and Access Management (IAM) 6 | 7 | - policies, processes, technologies used to manage identity info 8 | - provisioning, mgmt, and deprovisioning of identities 9 | - a foundational element is protecting the secret yet making it usable 10 | - **audited annually under SOX section 404** 11 | 12 | ### Authentication 13 | 14 | - typically authentication system is the underlying operating system aspect, not a third party application 15 | - integrates with AuthZ system once successful 16 | - Federated ID systems allow connection to systems through known system (Facebook, Microsoft, etc) 17 | - Relying party (RP) and Identity Provider (IdP) 18 | 19 | ## Credential Management 20 | 21 | - all activities should be logged 22 | 23 | ### X.509 Credentials 24 | 25 | - manipulating certificates used to transfer asymmetric keys 26 | - IETF PKIX (public key infrastructure X.509) 27 | 28 | ### Single Sign-On 29 | 30 | - two most popular are Kerberos (LDAP domain) and SAML - OpenID is also a proven protocol for SSO 31 | - primary objective of SSO is convenience 32 | 33 | ## Flow Control (Proxies, Firewalls, Middleware) 34 | 35 | ### Firewalls 36 | 37 | - network level firewall (stateless) - think VPC/intranet 38 | - next-generation firewalls (often stateful and look at multiple packets) - more granularity 39 | - firewalls operate on a packet level 40 | - can be stateless or stateful 41 | - limited by network architecture (e.g. if numerous paths for traffic to flow, difficult or even impossible to place firewalls) 42 | 43 | ### Proxies 44 | 45 | - security device like a firewall, but can also have a wide range of capabilities 46 | - can include caching for performance 47 | - can work at the protocol level (HTTP) whereas firewalls only know IP, TCP, UDP 48 | 49 | ### Application Firewalls 50 | 51 | - firewall proxy 52 | - PCI Data Security Standard req: web apps either need a WAF or code reviews 53 | - most can work on ingress and egress traffic 54 | 55 | ### Queuing Technology 56 | 57 | - synchronous or asynchronous 58 | - guaranteed transport or best effort (TCP and UDP, respectively) 59 | 60 | ## Logging 61 | 62 | - challenges: what to log, how to store 63 | - must meet compliance criteria (HIPAA, SOX, PCI DSS, EOC) 64 | 65 | ### Syslog 66 | 67 | - IETF approved protocol 68 | - UNIX format for sending logs across network 69 | 70 | ## Data Loss Prevention 71 | 72 | - protect against exfiltration of data 73 | - look for specific traffic (size, destination, data elements, etc) 74 | - attackers often use encryption to make it difficult to view what data is being stolen 75 | 76 | ## Virtualization 77 | 78 | - reduced cost of servers by consolidating 79 | - improved efficiencies from administrative ease 80 | - portability and isolation 81 | - operational agility (e.g. scaling in the cloud) 82 | 83 | ## Digital Rights Management 84 | 85 | - technology used to protect intellectual property 86 | - copy protection, usage rights, authenticity, integrity 87 | 88 | ### three entities in DRM 89 | 90 | 1. users 91 | 2. contents 92 | 3. rights 93 | 94 | - DRM uses Rights Expression Language (REL) - XML, machine readable 95 | - not perfect, still has issues balancing protection and usability 96 | 97 | ## Trusted Computing 98 | 99 | - ensure computer behaves consistently as expected 100 | 101 | ### TCB (trusted computing base) 102 | 103 | - focused mainly on privilege escalation 104 | - each element should require authorization to receive an increase in privilege 105 | 106 | ### TPM (trusted platform module) 107 | 108 | - hardware implementation of cryptographic functions on motherboard 109 | - level of security deeper than OS and virtually tamper-proof 110 | - controversy: could secure machine from owner or regulate permitted software 111 | 112 | ### Malware 113 | 114 | - software with malicious intent 115 | - can be designed so that it is not observable by the user and is virtually undetectable 116 | - malware requires a vuln in a software system 117 | 118 | ### Code Signing 119 | 120 | - digital signature 121 | - verify author, integrity, etc 122 | - mature technology 123 | 124 | ## Database Security 125 | 126 | - capabilities include those below as well as 127 | - stored procedures - access to specific elements based on rules 128 | - backup and replication 129 | 130 | ### Encryption 131 | 132 | - using DBMS functions or external tools 133 | - primary keys cannot be obfuscated/encrypted - don't use PII/PHI as keys 134 | - things to consider for encryption strategy 135 | - level of risk classification for data 136 | - usage pattern of data and protection in transit and use 137 | - risk classification for specific elements of data - does it differ? 138 | - how encryption is used across enterprise 139 | - what encryption options are available to dev team? 140 | - members of dev team need to know which data elements have regulations around encryption 141 | 142 | ### Triggers 143 | 144 | - trigger scripts based on database activity 145 | 146 | ### Views 147 | 148 | - type of data structure to give different access based on subject 149 | 150 | ## Programming Language Environment 151 | 152 | - language used for development is rarely what is used on the target computer (compilers, interpreters, or both affect this) 153 | 154 | ### Compilers 155 | 156 | - faster execution 157 | 158 | #### two sub-processes 159 | 160 | 1. **compiling**: convert source code into processor-specific codes 161 | 2. **linking**: connect libraries, dependency files, resources 162 | 1. static linking: increased executable size, everything is copied into it 163 | 2. dynamic linking: place names and locations of dependencies which are resolved at runtime 164 | 1. creates risk for hijacked dependent programs 165 | 166 | ### Interpreters 167 | 168 | - intermediary program to execute source code on target machine 169 | - slower execution but fast change between revisions (no compiling/linking) 170 | - converted into executable line by line at runtime 171 | 172 | ### Hybrid 173 | 174 | - compiled into intermediary stage to be interpreted at runtime 175 | 176 | #### CLR (.NET) 177 | 178 | - application can be built with multiple languages and compiled with just-in-time compiler 179 | - CLR adds garbage collection, type safety, index checking, sandboxing, more 180 | 181 | #### JVM 182 | 183 | - Java is compiled into byte code 184 | - JRE contains JVM and standard libs 185 | 186 | ### Compiler Switches 187 | 188 | - manage memory, stack protection, exception handling, etc 189 | - security team should define compiler switch options for use in SDLC 190 | 191 | ### Sandboxing 192 | 193 | - isolate code from direct contact with target system 194 | - execute un-trusted code, code from guests, unverified programs 195 | - operate like a VM 196 | - protection depends on level of isolation and mediation 197 | 198 | ### Managed vs Un-managed code 199 | 200 | #### Managed 201 | 202 | - executed in a intermediate system that has controls (Java, .NET) 203 | 204 | #### Un-managed 205 | 206 | - executed directly on target 207 | - compiled for specific system 208 | - significant performance advantages but things like memory, type safety, garbage collection, need to be managed by developer 209 | - un-managed is more prone to risks 210 | 211 | ## OS 212 | 213 | - functional interface between applications and hardware 214 | - real-time and embedded systems are simpler and leaner 215 | 216 | ## Embedded Systems 217 | 218 | - hardware and software are coupled for a specific purpose 219 | - PCs and servers are general purpose 220 | - examples: watches, audio/video players, vehicles, etc 221 | 222 | ### Control Systems 223 | 224 | - a type of embedded system for automated control of equipment 225 | - many names - SCADA, Industrial Control Systems, Operational Technology 226 | 227 | ### Firmware 228 | 229 | - software code held in a device 230 | - wired in software so it is difficult to update or change 231 | - in many cases, is never updated or changed 232 | - held in nonvolatile memory, read-only memory, erasable programmable read only memory, or flash memory 233 | - firmware holds operational code base 234 | - in computers, firmware is the first step in startup process (BIOS - basic input output system) 235 | - BIOS is the interface between OS and hardware 236 | - most computer makers replaced BIOS with more advanced version (UEFI - unified extensible firmware interface) around 2010 237 | -------------------------------------------------------------------------------- /notes/10-Outline/Outline.md: -------------------------------------------------------------------------------- 1 | # Exam Outline Review 2 | 3 | ## 1. Secure Software Concepts 4 | 5 | ### 1.1 Core Concepts 6 | 7 | - **Confidentiality** 8 | - Covert channel: communication path that is intentionally hidden. Leaves almost no trace. Receiver has to be actively listening for message 9 | - Overt channel: communication path that is not hidden. Leaves evidence behind but receiver doesn't have to be listening for message 10 | - Side channel: unintentional communication. Think power consumption changes to get information about encryption used 11 | - **Integrity** 12 | - Also includes stability and reliability for authorized subjects 13 | - **Availability** 14 | - **Authentication** 15 | - **Authorization** 16 | - **Accountability** 17 | - **Nonrepudiation** 18 | 19 | ### 1.2 Security Design Principles 20 | 21 | - **Least Privilege** 22 | - **Separation of duties** 23 | - **Defense in depth** 24 | - **Resiliency** 25 | - fail safe, fail secure, no single point of failure 26 | - **Economy of mechanism** 27 | - less complexity is better 28 | - eliminate nonessential services and protocols 29 | - **Complete mediation** 30 | - authorization cannot by bypassed 31 | - authorization checked every time subject requests access to an object 32 | - **Open design** 33 | - security of a system is independent of the design (don't rely on security by obscurity) 34 | - Kerckhoffs's principle: security of a cryptosystem is reliant on choice of keys, not algorithm 35 | - **Least common mechanism** 36 | - isolation to protect against sharing of information 37 | - **Psychological acceptability** 38 | - **Component reuse** 39 | - **Diversity of defense** 40 | - layers of defense should be diverse 41 | - **Safeguard** 42 | - _Proactive_ controls to protect assets 43 | - controls can be physical, administrative, or technical 44 | - **Countermeasure** 45 | - _Reactive_ controls to protect assets 46 | - controls can be physical, administrative, or technical 47 | 48 | ## 2. Secure Software Requirements 49 | 50 | ### 2.1 Define Software Security Requirements 51 | 52 | - **Functional** 53 | - business requirements 54 | - use cases 55 | - user stories 56 | - **Non-functional** 57 | - operational 58 | - deployment 59 | - systemic qualities 60 | 61 | ### 2.2 Identify and Analyze Compliance Requirements 62 | 63 | - **FISMA** 64 | - an agency-wide information security program is required for federal agencies 65 | - **Sarbanes-Oxley** 66 | - internal control measures for financial accounting 67 | - **Gramm-Leach-Bliley** 68 | - protection of PFI (Personal Financial Information) 69 | - protects against falsely pretending to obtain PFI 70 | - **HIPAA and HITECH** 71 | - **Payment Card Industry Data Security Standard (PCI DSS)** 72 | 73 | ### 2.3 Identify and Analyze Data Classification Requirements 74 | 75 | - **Data ownership** 76 | - **Labeling** 77 | - sensitivity and impact 78 | - primarily driven by cost 79 | - **Types of data** 80 | - structured, unstructured 81 | - categories: security sensitive, PII, hidden 82 | - **Data life-cycle** 83 | - if persistent, data needs to be classified, labeled, assigned retention policy 84 | - retention policies include backups, DR sites, legal holds 85 | - legal hold data is excluded from normal disposal procedures 86 | 87 | ### 2.4 Identify and Analyze Privacy Requirements 88 | 89 | - **Data anonymization** 90 | - **User consent** 91 | - **Disposition** 92 | - right to be forgotten 93 | - **Data retention** 94 | - **Cross borders** 95 | 96 | ### 2.5 Develop Misuse and Abuse Cases 97 | 98 | - **Use cases** 99 | - helpful for clarifying complex/confusing/ambiguous situations 100 | - not intended for all subject-object relationships 101 | 102 | ### 2.6 Develop Security Requirement Traceability Matrix (STRM) 103 | 104 | - document relationships between security requirements, controls, and test/verification efforts 105 | 106 | ### 2.7 Ensure Security Requirements Flow Down to Suppliers/Providers 107 | 108 | ## 3. Secure Software Architecture and Design 109 | 110 | ### 3.1 Perform Threat Modeling 111 | 112 | - **Understand common threats** 113 | - **Attack surface evaluation** 114 | - **Threat intelligence** 115 | 116 | ### 3.2 Define the Security Architecture 117 | 118 | - **Security control identification and prioritization** 119 | - **Distributed computing** 120 | - **Service-oriented architecture** 121 | - **Rich internet applications** 122 | - **Pervasive/ubiquitous computing** 123 | - IOT 124 | - RFID 125 | - NFC 126 | - **Embedded** 127 | - Field-programmable gate array (FPGA) security features 128 | - **Cloud architecture** 129 | - **Mobile applications** 130 | - **Hardware platform concerns** 131 | - **Cognitive computing** 132 | - machine learning, AI 133 | - **Control systems** 134 | 135 | ### 3.3 Performing Secure Interface Design 136 | 137 | - **Security management interfaces, out-of-band management, log interfaces** 138 | - **Upstream/downstream dependencies** 139 | - **Protocol design choices** 140 | 141 | ### 3.4 Performing Architectural Risk Assessment 142 | 143 | ### 3.5 Model (Non-Functional) Security Properties and Constraints 144 | 145 | ### 3.6 Model and Classify Data 146 | 147 | ### 3.7 Evaluate and Select Reusable Secure Design 148 | 149 | - **Credential management** 150 | - **Flow control** 151 | - proxies, firewalls, protocols, queueing 152 | - **Data loss prevention** 153 | - **Virtualization** 154 | - **Trusted computing** 155 | - **Database security** 156 | - **Programming language environment** 157 | - **Operating system controls and services** 158 | - **Secure backup and restoration planning** 159 | - **Secure dat retention, retrieval, and destruction** 160 | 161 | ### 3.8 Perform Security Architecture and Design Review 162 | 163 | ### 3.9 Define Secure Operational Architecture 164 | 165 | ### 3.10 Use Secure Architecture and Design Principles, Patterns, and Tools 166 | 167 | ## 4. Secure Software Implementation 168 | 169 | ### 4.1 Adhere to Relevant Secure Coding Practices 170 | 171 | - **Declarative vs imperative (programmatic) security** 172 | - **Concurrency** 173 | - **Output sanitization** 174 | - **Error and exception handling** 175 | - **Input validation** 176 | - **Secure logging & auditing** 177 | - **Session management** 178 | - **Trusted/Untrusted APIs and libraries** 179 | - **Type safety** 180 | - **Resource management** 181 | - **Secure configuration management** 182 | - **Tokenizing** 183 | - **Isolation** 184 | - **Cryptography** 185 | - **Access control** 186 | - **Processor micro-architecture security extensions** 187 | 188 | ### 4.2 Analyze Code for Security Risks 189 | 190 | - **Secure code reuse** 191 | - **Vulnerability databases/lists** 192 | - **Static application security testing** 193 | - **Dynamic application security testing** 194 | - **Manual code review** 195 | - **Look for malicious code** 196 | - **Interactive application security testing** 197 | 198 | ### 4.3 Implement Security Controls 199 | 200 | ### 4.4 Address Security Risks 201 | 202 | - **Risk response** 203 | 204 | ### 4.5 Securely Reuse Third-Party Code or Libraries 205 | 206 | ### 4.6 Securely Integrate Components 207 | 208 | - **Systems-of-systems integration** 209 | 210 | ### 4.7 Apply Security During the Build Process 211 | 212 | - **Anti-tampering techniques** 213 | - **Compiler switches** 214 | - **Address compiler warnings** 215 | 216 | ## 5. Secure Software Testing 217 | 218 | ### 5.1 Develop Security Test Cases 219 | 220 | - **Attack surface validation** 221 | - **Penetration tests** 222 | - **Fuzzing** 223 | - **Scanning** 224 | - **Simulation** 225 | - **Failure** 226 | - break testing 227 | - fault injection: introducing faults to see how software behaves. Test error handling code paths 228 | - **Cryptographic validation** 229 | - **Regression tests** 230 | - **Integration tests** 231 | - **Continuous** 232 | - synthetic transactions: write code to mimic user behavior using a browser 233 | - real-user monitoring: collect data based on actual user data (e.g. Google Analytics) 234 | 235 | ### 5.2 Develop Security Testing Strategy and Plan 236 | 237 | - **functional security testing** 238 | - **nonfunctional security testing** 239 | - reliability 240 | - performance 241 | - scalability 242 | - **testing techniques** 243 | - white box 244 | - black box 245 | - **environment** 246 | - **standards** 247 | - ISO 248 | - Open Source Security Testing Methodology Manual (OSSTMM) 249 | - Software Engineering Institute (SEI) 250 | - **crowd sourcing** 251 | - bug bounty 252 | 253 | ### 5.3 Verify and Validate Documentation 254 | 255 | ### 5.4 Identify Undocumented Functionality 256 | 257 | ### 5.5 Analyze Security Implications of Test Results 258 | 259 | ### 5.6 Classify and Track Security Errors 260 | 261 | - **Bug tracking** 262 | - **Risk scoring** 263 | - CVSS 264 | 265 | ### 5.7 Secure Test Data 266 | 267 | - **Generate test data** 268 | - **Reuse of production data** 269 | 270 | ### 5.8 Perform verification and validation testing 271 | 272 | ## 6. Secure Software Lifecycle Management 273 | 274 | ### 6.1 Secure configuration and version control 275 | 276 | ### 6.2 Define strategy and roadmap 277 | 278 | ### 6.3 Manage security within a software development methodology 279 | 280 | ### 6.4 Identify security standards and frameworks 281 | 282 | ### 6.5 Define and develop security documentation 283 | 284 | ### 6.6 Develop security metrics 285 | 286 | ### 6.7 Decommision software 287 | 288 | - **End of life policies** 289 | - **Data disposition** 290 | 291 | ### 6.8 Report security status 292 | 293 | ### 6.9 Incorporate integrated risk management (IRM) 294 | 295 | ### 6.10 Promote security culture in software development 296 | 297 | ### 6.11 Implement continuous improvement 298 | 299 | ## 7. Secure Software Deployment, Operations, and Maintenance 300 | 301 | ### 7.1 Perform operational risk analysis 302 | 303 | - **Deployment environment** 304 | - **Personnel training** 305 | - **Safety criticality** 306 | - **System integration** 307 | 308 | ### 7.2 Release software securely 309 | 310 | - **Secure continuous integration and continuous delivery pipeline** 311 | - **Secure software tool chain** 312 | - **Build artifact verification** 313 | 314 | ### 7.3 315 | 316 | - **Credentials** 317 | - **Secrets** 318 | - **Keys/certificates** 319 | - **Configurations** 320 | 321 | ### 7.4 Ensure secure installation 322 | 323 | - **Bootstrapping** 324 | - **Least privilege** 325 | - **Environment hardening** 326 | - **Secure activation** 327 | - **Security policy implementation** 328 | - **Secrets injection** 329 | 330 | ### 7.5 Perform post-deployment security testing 331 | 332 | ### 7.6 Obtain security approval to operate 333 | 334 | ### 7.7 Perform information security continuous monitoring (ISCM) 335 | 336 | - **Collect and analyze observable data** 337 | - **Threat intel** 338 | - **Intrusion detection/response** 339 | - **Secure configuration** 340 | - **Regulation changes** 341 | 342 | ### 7.8 Support incident response 343 | 344 | - **Root cause analysis** 345 | - **Incident triage** 346 | - **Forensics** 347 | 348 | ### 7.9 Perform patch management 349 | 350 | ### 7.10 Perform vulnerability management 351 | 352 | ### 7.11 Runtime protection 353 | 354 | ### 7.12 Support continuity of operations 355 | 356 | - **Backup, archiving, retention** 357 | - **Disaster recovery** 358 | - **Resiliency** 359 | 360 | ### 7.13 Integrate service level objectives and service level agreements 361 | 362 | ## 8. Secure Software Supply Chain 363 | 364 | ### 8.1 Implement software supply chain risk management 365 | 366 | - **Identify** 367 | - **Assess** 368 | - **Respond** 369 | - **Monitor** 370 | 371 | ### 8.2 Analyze security of third-party software 372 | 373 | ### 8.3 Verify pedigree and provenance 374 | 375 | - **Secure transfer** 376 | - **System sharing/interconnections** 377 | - **Code repository security** 378 | - **Build environment security** 379 | - **Cryptographically-hashed, digitally-signed components** 380 | - **Right to audit** 381 | 382 | ### 8.4 Ensure supplier security requirements in teh acquisition process 383 | 384 | ### 8.5 Support contractual requirements 385 | -------------------------------------------------------------------------------- /notes/01-Secure-Software-Concepts/01-General-Security-Concepts.md: -------------------------------------------------------------------------------- 1 | # General Security Concepts 2 | 3 | ## Concepts 4 | 5 | ### Security Basics 6 | 7 | 📝 Determining and applying the appropriate balance of confidentiality, integrity, and availability (CIA) 8 | 9 | Although different, they are not necessarily contradictory - but they all require resources (money) and so the balance should be determined early on in the design process 10 | 11 | #### Confidentiality 12 | 13 | - **Prevent disclosure of information to unauthorized parties** 14 | - Numerous methods for keeping data confidential: e.g. access controls, encryption 15 | - **Access Controls**: Preferred for data in use and at rest 16 | - **Encryption**: Data at rest and in transit 17 | 18 | #### Integrity 19 | 20 | - **Protect data from unauthorized alteration** 21 | - e.g. Read-only, Read-and-write, write-only, delete access, etc 22 | - Integrity contributes to a system's **stability** and **reliability** as well as the **authenticity** of data 23 | 24 | #### Availability 25 | 26 | - Availability needed is determined by criticality of data and purpose in the overall system 27 | 28 | #### Authentication 29 | 30 | - **Determining the _identity_ of a user. A user is authenticated before their authorization can be determined.** 31 | - To verify identity, a user can provide: 32 | 33 | - Something you know - e.g. username/password (not very reliable) 34 | - Something you have - e.g. token 35 | - Something about you (something you are) e.g. biometrics 36 | - ❗ Requires extra hardware, lacks specificity 37 | 38 | - New categories 39 | 40 | - what users do (dynamic biometrics such as typing patterns, gait) 41 | - where a user is (physical location) 42 | 43 | - ATMs use combination of something you know (PIN) and something you have (card) so if the card is lost, someone cannot authenticate as you 44 | 45 | #### Authorization 46 | 47 | - **Applies predetermined access levels to the user** 48 | 49 | 1. Three elements are used 50 | 1. Requestor (subject) - already known due to authentication system 51 | 2. Object 52 | 1. file, program, data, other resource 53 | 3. Type/level of access to be granted 54 | 1. Read, write, create, delete, right to grant access rights to other objects 55 | 56 | #### Accounting (Auditing) 57 | 58 | - **Accounting is a means of measuring activity, auditing is the verification of what actual happened and allows management to observe in a nonpartisan manner** 59 | - Accounting can be done in IT systems by logging crucial activity as it occurs 60 | - Accounting is needed when activity of specific data elements is crucial enough that it may be audited at a later date and time 61 | 62 | - Security level auditing can be performed at several levels: 63 | 64 | - analysis of logging function 65 | - verification of existence and operation of specific controls 66 | - etc 67 | 68 | - Auditing takes resources to create, store, and review. Typically defaulted to minimal level so system operator must determine correct level based on system criticality. 69 | - **System criticality** is determined by information criticality associated with information manipulated/stored with the system 70 | 71 | #### Non-repudiation 72 | 73 | - **Preventing a subject from denying a previous action with an object** 74 | - When authentication, authorization, and auditing are properly configured, non-repudiation is ensured 75 | - **Security requirements must specify the subjects, objects, and events for which non-repudiation is desired** 76 | 77 | ### System Tenets 78 | 79 | #### Session Management 80 | 81 | - **Design and implementation of controls to ensure that communication channels are secured from unauthorized access and disruption** 82 | - TCP (Transmission Control Protocol) 83 | - sequential numbering of packets and retransmission for missing packets 84 | - Prevents unauthorized packets and session hijacking 85 | - Has overhead 86 | - UDP (User Datagram Protocol) 87 | - connection-less/session-less 88 | 89 | #### Exception Management 90 | 91 | - All exceptions must be detected and handled 92 | - System should not fail in an insecure state 93 | - Exception should not be leaked 94 | 95 | #### Configuration Management 96 | 97 | - Configuration should be protected from unauthorized changes 98 | - e.g. separation of duties between production/non-prod personnel 99 | 100 | ### Secure Design Tenets 101 | 102 | #### Good Enough Security 103 | 104 | - Don't spend $10,000 to protect a $20 bill 105 | - Trade-offs exist between security and other aspects 106 | 107 | #### Least Privilege 108 | 109 | - If a subject may require different levels of security for different tasks, better to switch security levels with specific tasks than run all the time at higher privilege 110 | 111 | #### Separation of Duties 112 | 113 | - No single individual can abuse the system 114 | 115 | #### Defense in Depth 116 | 117 | - i.e. layered security/defense and diversity defense 118 | - Multiple, overlapping defenses 119 | - No system is 100% secure - **true goal of security is to make cost of compromising greater in time/effort/resources than it is worth** 120 | - Diversity of defense - layers should be dissimilar in nature 121 | 122 | #### Fail-safe 123 | 124 | - **When a system experiences a failure, it should fail to a safe state** 125 | - Example: explicit deny 126 | - CIA need to be appropriately maintained - availability causes the greatest design difficulties 127 | 128 | #### Economy of Mechanism 129 | 130 | - Higher complexity generally results in less security due to lack of understanding and more attack vectors 131 | - Root cause analysis, especially for potential security issues, is much more difficult in complex systems 132 | - **Rule of thumb**: eliminate all nonessential services and protocols 133 | 134 | #### Complete Mediation 135 | 136 | - **Authorization is never circumvented, even with repeated access** 137 | - Example: security kernel 138 | 139 | #### Open Design 140 | 141 | - Don't rely on security by obscurity 142 | - Example: modern cryptography relies on the secrecy of the key, not secrecy of the algorithm 143 | 144 | #### Least Common Mechanism 145 | 146 | - **Prevent inadvertent sharing of information by using separate processes when possible** 147 | 148 | #### Psychological Acceptability 149 | 150 | - Users will try to get around security if it is seen as an obstacle 151 | 152 | #### Weakest Link 153 | 154 | - Adding to the security of a system is most effective when applied to the weakest link 155 | 156 | #### Leveraging Existing Components 157 | 158 | - Pros: increase efficiency and security 159 | - Cons: monoculture environment (failures have a larger footprint) 160 | 161 | #### Single Point of Failure 162 | 163 | No one single piece should be able to cause the whole system to fail 164 | 165 | ## Security Models 166 | 167 | - Three key elements: people, processes, and technology 168 | - Controls using 2-3 elements are more effective 169 | 170 | ### Access Control Models 171 | 172 | #### ACL - access control list 173 | 174 | #### MAC - mandatory access control 175 | 176 | - rarely used 177 | - originated in military 178 | - **restrict based on information sensitivity and clearance to access that information** 179 | - system designers have to determine object/subject relationships before they can be used 180 | 181 | #### DAC - discretionary access control 182 | 183 | - most common 184 | - originated in military 185 | - **restrict based on identity of subjects/groups they belong to** 186 | - If a subject has permission, it is capable of passing that permission onto any other subject 187 | - ACLs are the most common mechanism used to implement this control 188 | - **Strength**: simplicity 189 | - **Weakness**: security is optional, owner has to define access for potentially a plethora of objects 190 | 191 | #### RBAC - role-based access control 192 | 193 | pretty common for active directory 194 | 195 | #### RBAC - rule-based access control 196 | 197 | - much less common than role-based 198 | - Use ACLs that have rules baked in such as only allow access during a certain time-of-day 199 | 200 | #### Access control matrix model 201 | 202 | - strength: simplicity 203 | - weakness: difficult to implement due to no constraints, doesn't scale well 204 | 205 | #### ABAC - attribute-based access control 206 | 207 | - Example: doctor getting one set of access for a specific patient vs a different patient 208 | - Represented via eXtensible Access Control Markup Language (XACML) 209 | - also works for policy-based access control 210 | 211 | #### Bell-LaPadula Confidentiality Model 212 | 213 | 1. Two principles 214 | 1. Simple Security Rule - in order to see something, you have to be authorized 215 | 1. Used to preserve confidentiality - e.g. subject with medium clearance can't ready information with high sensitivity, only medium sensitivity 216 | 2. No-read-up 217 | 2. \* property (star property) 218 | 1. No-write-down 219 | 2. Subjects can only write to an object if the object has equal or higher classification - e.g. medium clearance can only write to medium sensitivity and above 220 | 221 | #### Take-Grant Model 222 | 223 | - Uses graph theory based on mathematical representation of controls 224 | - Can be used to definitively determine rights 225 | - Not typically used to implement access control but rather to analyze implementations 226 | 227 | ### Multilevel Security Model 228 | 229 | - **Separate groups have labels, groups act as containers, can be hierarchical** 230 | 231 | ### Integrity Models 232 | 233 | - Depending on type of information, can be just as important or more important than confidentiality. e.g. stock prices (public but integrity is crucial) 234 | 235 | #### Biba Integrity Model 236 | 237 | - Preserves information integrity 238 | - Integrity levels separate permissions 239 | - Low water mark policy, i.e. no-write-up rule 240 | - lower integrity subjects can't write up to higher integrity subjects 241 | - Integrity level of a subject is lowered if it acts on a subject with lower integrity 242 | 243 | #### Clark-Wilson security model 244 | 245 | - Uses transactions 246 | - Two levels: 247 | - Constrained data items (CDI) 248 | - Subject to integrity controls 249 | - Unconstrained data items (UDI) 250 | - Two types of processes: 251 | - Integrity verification processes (IVPs) 252 | - Ensure CDI data meets constraints 253 | - Transformation processes (TPs) 254 | - Change state of data from one to another 255 | - Data can only be changed by trusted TPs, not users 256 | 257 | Example: 258 | 259 | - A bank account balance is a CDI since integrity is important 260 | - TP is the only way changes can be made 261 | - IVP ensures balance is correct 262 | 263 | ### Information Flow Models 264 | 265 | #### Brewer-Nash Model (Chinese Wall) 266 | 267 | - Technology employed to prevent access 268 | - People trained not to compromise information 269 | - Policies/processes put in place to ensure technology/people are properly used 270 | 271 | #### Data Flow Diagrams (DFDs) 272 | 273 | - Main security issue is protecting information when stored, in transit, and being processed 274 | - Multiple levels - Level 0 (high level), level 1, level 2 (lowest level) 275 | 276 | #### Use Case Model 277 | 278 | - Functional perspective - how the system uses data 279 | 280 | - Use cases for normal and abnormal use 281 | - **Very important to security to understand use cases and misuse cases** 282 | 283 | #### Assurance Models 284 | 285 | - **Software assurance - level of confidence that software is free from intentional and accidental vulnerabilities, software functions as intended** 286 | 287 | #### Operational model of security 288 | 289 | Three methods of managing security: 290 | 291 | 1. prevention - access control, firewall, encryption 292 | 2. detection - audit logs, intrusion detection, honeypots 293 | 3. response - backups, incident response teams, forensics 294 | 295 | #### NIST CSF 296 | 297 | Standards, guidelines, best practices 298 | 299 | 5 main categories: 300 | 301 | 1. Identify 302 | 2. Protect 303 | 3. Detect 304 | 4. Respond 305 | 5. Recover 306 | 307 | ## Adversaries 308 | 309 | Includes mother nature :) 310 | 311 | ### Adversary Type 312 | 313 | - **Based on skill level** 314 | 315 | 1. Script Kiddie - 80-85% of adversaries 316 | 2. Hacker - explorer - 15-20% **key adversary due to skill/motivation** 317 | 1. Cracker - hacker with malicious intent 318 | 3. Elite - 1-3% 319 | 1. completely underground 320 | 321 | ### Adversary Groups 322 | 323 | #### Skill and capability 324 | 325 | 1. Unstructured threat - little or no resources, no specific motivation, typically only an annoyance 326 | 2. Structured threat - specific mission, time and resources 327 | 3. Highly structured threat - organized crime, crimeware 328 | 4. Nation-state threat 329 | 1. Advanced persistent threat (APT) - multiple methods to penetrate and then live undetected 330 | 5. Insider vs outsider 331 | 332 | ### Threat Landscape Shift 333 | 334 | - Around 2005 - criminalization of cyberspace allowing monetization 335 | - Market for exploits 336 | -------------------------------------------------------------------------------- /notes/01-Secure-Software-Concepts/03-Security-Policies-and-Regulations.md: -------------------------------------------------------------------------------- 1 | # Security Policies and Regulations 2 | 3 | - **All hazards**: senior management is responsible for security, compliance, all exercises in risk management 4 | 5 | ## FISMA 6 | 7 | - **Federal Information Security Management Act of 2002** 8 | - 📝 Primary governing law for federal computer systems 9 | 10 | - Requires each federal agency to implement a security program 11 | - NIST (National Institute of Standards and Technology) developed guidelines 12 | - Risk Management Framework (RMF) was published by NIST 13 | - Initial framework included: 14 | - Inventory of systems 15 | - Categorize information and systems according to risk level 16 | - security controls 17 | - Certification/accreditation of systems (risk assessment and security plans) 18 | - Training 19 | - Information Security Automation Program 20 | - Security Content Automation Protocol (SCAP) 21 | 22 | NIST six steps for a RMF: 23 | 24 | 1. Categorize systems 25 | 2. Select security controls 26 | 3. Implement controls 27 | 4. Assess Controls 28 | 5. Authorize information systems 29 | 6. Monitor controls 30 | 31 | ## Sarbanes-Oxley (2002) 32 | 33 | - financial accounting information systems must have control over integrity 34 | 35 | ## Gramm-Leach-Bliley Act / Financial Modernization Act of 1999 (GLBA) 36 | 37 | - Protect PFI (personal financial information) 38 | - act specifies rules for collection, processing, storage, and disposal of PFI 39 | 40 | Primary rules: 41 | 42 | 1. Financial Privacy Rule - collection and disclosure of PFI 43 | 2. Safeguards Rule - applies to financial institutions - covers design, implementation, and maintenance of safeguards to protect PFI 44 | 3. Pretexting Protections Rule - address pretexting (falsely pretending) to obtain PFI 45 | 46 | ## HIPAA and HITECH 47 | 48 | - HIPAA - (Healthcare Insurance Portability and Accountability Act) 49 | - Protect PHI (personal health information) 50 | - HITECH - (Health Information Technology for Economic and Clinical Health Act) 51 | - enhance privacy of electronic PHI records 52 | 53 | ## Payment Card Industry (PCI) 54 | 55 | Industry group established to secure cardholder data 56 | 57 | ### Data Security Standard (PCI DSS) 58 | 59 | Industry group members that accept and process bank cards are required to protect cardholder data 60 | 61 | ### Payment Application Data Security Standard (PA DSS) 62 | 63 | Standard to validated that a payment application is compliant with PCI DSS 64 | 65 | ### PIN Transaction Security (PTS) 66 | 67 | Applies to PIN Entry Devices (PEDs) 68 | 69 | ## Legal Issues 70 | 71 | ### Intellectual Property 72 | 73 | 1. Patents 74 | 1. Exclusive right for a specified time 75 | 2. protect rights in exchange for disclosure of invention 76 | 3. Varies by country but in the US, invention must be new, useful, and non-obvious 77 | 4. Prevent others from using invention 78 | 5. Patent must be applied for prior to disclosure 79 | 6. challenging and expensive 80 | 2. Copyrights 81 | 1. Protection of an idea or information for a specified time 82 | 2. right to be credited, who may adapt, who may perform, who may financially benefit, etc 83 | 3. governed internationally by Berne Convention 84 | 4. straightforward and affordable 85 | 3. Trademarks 86 | 1. recognizable quality of product/firm 87 | 2. used to build brand association 88 | 3. can be common-law or registered - registered provides more legal protection and recovery 89 | 4. managed internationally through World Intellectual Property Organization 90 | 4. Trade Secrets 91 | 1. best time-based protection 92 | 2. protected by many laws as long as company makes a reasonable attempt to keep it secret 93 | 3. if secret is independently discovered (e.g. recipe), then secret holder has no recourse 94 | 4. US Digital Millenium Copyright Act prohibits reverse-engineering of security safeguards 95 | 5. Warranty 96 | 1. hardware often has a warranty to perform at the specified level 97 | 2. software does not and is generally sold as is 98 | 99 | ## Privacy 100 | 101 | - To obtain certain goods, users must consent to share certain information 102 | - One main issue with privacy is data disposition 103 | - 📝 founded on notice, choice, and security 104 | 105 | ### Privacy Policy 106 | 107 | Internal privacy policy details the firm's responsibilities to protect information 108 | 109 | External privacy policy, or privacy disclosure statement, informs customers how data is protected, used, and disposed of 110 | 111 | In financial sector, Gramm-Leach-Bliley Act mandates firms clearly state how information is shared 112 | 113 | ### PII 114 | 115 | ### PHI (Personal Health Information / Protected Health Information) 116 | 117 | Highly valued by cyber criminals 118 | 119 | ### Breach notifications 120 | 121 | - Incident response (what happened, how, what was lost) 122 | - Most states have disclosure laws, no federal law 123 | 124 | ### Data Protection Principles 125 | 126 | - data protection - European Union 127 | - European Union Data Protection Directive (EUDPD) - old 128 | - General Data Protection Regulation (GDPR) 129 | - In US, consumers must opt-out 130 | 131 | #### European Union Privacy Law 132 | 133 | - consumers must opt-in 134 | - three conditions must be met for processing personal data: 135 | - transparency: consent, including purpose and recipients 136 | - legitimate purpose 137 | - proportionality 138 | 139 | #### Safe Harbor Principles 140 | 141 | - Non-EU firms can meet EUDPD requirements by: 142 | - **Have been replaced, still helpful to understand** 143 | 144 | 1. **Notice**: inform customers of data collection and purpose 145 | 2. **Choice**: can opt out of collection and transfer of data 146 | 3. **Onward transfer**: third parties must follow principles 147 | 4. **Security**: Reasonable efforts to prevent loss of data 148 | 5. **Data integrity**: Relevant and reliable for purpose it was collected 149 | 6. **Access**: Customers can access data and correct/delete 150 | 7. **Enforcement**: Effective means for enforcing rules 151 | 152 | ### GDPR (2018) 153 | 154 | Several major changes: 155 | 156 | 1. Personal Data elements are anything that can be linked back to a subject, including cookies 157 | 2. Individuals must have full access to how data is processed in a clear manner 158 | 1. who is asking for the data 159 | 2. what the data will be used for 160 | 3. how long can it be kept 161 | 4. if and where it will be transferred internationally 162 | 5. right to access, correct, or erase 163 | 6. right to withdraw consent, even after collection 164 | 7. right to lodge a complaint 165 | 166 | ### California Consumer Privacy Act of 2018 (AB 375) 167 | 168 | Similar to GDPR 169 | 170 | individuals still must opt out but they have rights: 171 | 172 | - right to know (access to data and how it's used) 173 | - right to delete (some exceptions) 174 | - right to opt out of sale of information 175 | - right to non-discrimination if they don't want data sold 176 | 177 | ## Security Standards 178 | 179 | ### ISO (International Organization for Standardization) 180 | 181 | - five year review cycle 182 | 183 | Relevant area is under JTC 1 - Information Technology 184 | 185 | - Subcommittee 7 (Software and Systems Engineering) 186 | - Subcommittee 27 (IT Security Techniques) 187 | 188 | Prominent ISO Standards for CSSLPs - **See page 64** 189 | 190 | ### ISO 2700X Series 191 | 192 | For information security 193 | 194 | Includes vocabulary, code of practice, implementation guidance, metrics, and risk management 195 | 196 | ### ISO 15408 Common Criteria / Evaluation Assurance Levels (EAL) 197 | 198 | Functional and assurance requirements 199 | 200 | Claims can be made about the product that can be evaluated and verified 201 | 202 | - **TOE**: Target of Evaluation - product or system being evaluated 203 | - **ST**: Security Target - security properties of a TOE 204 | - **PP**: Protection profile - set of security requirements associated with a certain class of product 205 | - products in the same class can be compared more easily 206 | 207 | higher EAL != better security 208 | 209 | ### ISO 9126 Software Engineering Product Quality 210 | 211 | - four parts to define a quality model 212 | - Quality of use metrics for specific scenarios 213 | - Functionality 214 | - Reliability 215 | - Usability 216 | - Efficiency 217 | - Maintainability 218 | - Portability 219 | 220 | ### ISO 12207 Systems and Software Engineering - Software Life Cycle Processes 221 | 222 | - set of processes each having its own activities, tasks, and outcomes 223 | 224 | ### ISO 15504 Information Technology - Process Assessment 225 | 226 | SPICE/SPICD - Software Process Improvement and Capability Determination 227 | 228 | ### NIST 229 | 230 | National Institute of Standards and Technology 231 | 232 | Computer security division 233 | 234 | - Federal Information Security Management Act of 2002 (FISMA) 235 | 236 | Information Technology Laboratory (ITL) 237 | 238 | - Security bulletins 6x/yr 239 | - Interagency/internal reports (NISTIRs): technical research 240 | 241 | #### Federal Information Processing Standards (FIPS) 242 | 243 | - mandatory reqs on fed agencies and specific contractors 244 | - few but broad in authority and scope 245 | - Since FISMA, all aspects are mandatory and waivers are not allowed 246 | 247 | #### NIST SP 800 Series 248 | 249 | - more commonly used by industry 250 | - communicate results of research/guidelines assoc with securing systems 251 | - incl. cryptographic protocols, security reqs, risk mgmt framework, governance, etc 252 | 253 | #### Industry 254 | 255 | - SAFECode 256 | - Industry-backed 257 | - increase comm. between firms on software assurance 258 | - share best practices that have been successful 259 | - **SAFECode Releases Software Security Guidance for Agile Practitioners** 260 | - valuable to large and small firms 261 | 262 | ## Secure Software Architecture 263 | 264 | ### Security Frameworks 265 | 266 | #### COBIT - Control Objectives for Information and Related Technology 267 | 268 | Published by ISACA (Information Systems Audit and Control Association) 269 | 270 | - bridge gap between control reqs, tech issues, and business risks 271 | - Latest is COBIT 2019 (book explains COBIT 5) 272 | 273 | ##### COBIT 5 Principles 274 | 275 | 1. Meeting stakeholder needs 276 | 2. covering the enterprise end to end 277 | 3. applying a single, integrated frmwrk 278 | 4. enabling a holistic apprch 279 | 5. separating governance from mgmt 280 | 281 | #### COSO - Committee of Sponsoring Organizations of the Treadway Commission 282 | 283 | - five private-sector orgs in response to Treadway Commissions report on fraudulent financial reporting 284 | - Enterprise Risk mgmt integrated frmwrk to assess control systems 285 | - five components/principles 286 | - control env 287 | - risk assmnt 288 | - ctrl activities 289 | - info and communication 290 | - monitoring 291 | 292 | #### ITIL - Information Technology Infrastructure Library 293 | 294 | - aligning IT services with bus. needs 295 | 296 | ##### Five volumes 297 | 298 | 1. ITIL Service Strategy 299 | 2. ITIL Service Design 300 | 3. ITIL Service Transition 301 | 4. ITIL Service Operation 302 | 5. ITIL Continual Service Improvement 303 | 304 | #### Zachman 305 | 306 | - matrix frmwrk to define an enterprise 307 | 308 | #### SABSA - Sherwood Applied Business Security Architecture (SABSA) 309 | 310 | - frmwrk and methodology for risk-driven enterprise infosec architectures 311 | - similar to Zachman 312 | - Goal: all reqs, including security reqs, can be derived from business reqs 313 | - Works well with SDLC 314 | 315 | #### SDLC 316 | 317 | Using some kind of process-based lifecycle results in greater security 318 | 319 | - partly due to models 320 | - partly due to opportunities for process improvement on models 321 | 322 | #### SEI CMMI (Software Engineering Institute - Capability Maturity Model Integration) 323 | 324 | - rates process maturity on a 1-5 scale 325 | - Three primary areas: product/service dvlpmnt, service establishment/mgmt, product/service acquisition 326 | - **framework for business process improvement**: improving operational processes 327 | 328 | ##### Process Maturity Levels 📝 329 | 330 | 1. **Initial:** uncontrolled, results unpredictable 331 | 2. **Managed:** established, typically reactive 332 | 3. **Defined:** characterized for org, proactive 333 | 4. **Quantitatively Managed:** measured and controlled 334 | 5. **Optimizing:** process improvement 335 | 336 | #### OWASP - already familiar with :) 337 | 338 | #### OCTAVE - Operationally Critical Threat, Asset, and Vulnerability Evauluation 339 | 340 | - tools, techniques, methods for risk-based infosec assmnt 341 | - Three phases: build asset-based threat profiles, identify infra vulns, dvlp security strategy 342 | 343 | #### BSI - Build Security In 344 | 345 | - US Dep of Homeland Security 346 | - info on research, best practices, generic principles for software security 347 | - collaborative effort for devs, architects, infosec practitioners to build security into SDLC 348 | 349 | ## Trusted Computing 350 | 351 | - developed and promoted by trusted computing group (TCG) 352 | - Has a trusted platform module (TPM) with encryption key that is only accessible through the TPM chip 353 | - controversy: could the machine be secured from its owner? 354 | 355 | ### Principles 356 | 357 | 1. security 358 | 2. privacy 359 | 3. interoperability 360 | 4. portability of data 361 | 5. controllability 362 | 6. ease of use 363 | 364 | #### Ring Model 365 | 366 | - system method 367 | - protect data/functionality from errors and malicious behavior 368 | - ring can only interact within itself or with adjacent rings 369 | 370 | #### Reference Monitor (reference validation mechanism) 371 | 372 | - access control methodology 373 | - mediates interaction between subjects/objects 374 | - 📝 three qualities are req: 375 | - no path around it, always invoked (complete mediation) 376 | - tamper-proof 377 | - small enough to be verifiable 378 | 379 | #### Protected Objects 380 | 381 | - existence may be known, cannot be interacted with directly 382 | - must use protected subsystem with specific procedures and a security policy 383 | 384 | ### Trusted Computing Base (TCB) 385 | 386 | - combination of software/firmware/hardware to ensure security 387 | - includes kernel and reference monitors, **not applications** 388 | - if application becomes compromised, it would not affect TCB 389 | 390 | ### Trusted Platform Module (TPM) 391 | 392 | - secure storage of crypto. keys and platform auth - on a chip 393 | 394 | ### Microsoft Trustworthy Computing Initiative (2002) 395 | 396 | Four pillars: 397 | 398 | 1. security (including social dimension) 399 | 2. privacy 400 | 3. reliability 401 | 4. business integrity 402 | 403 | ## Acquisition 404 | 405 | Terms: 406 | 407 | - Commercial off-the-shelf (COTS) 408 | - Government off-the-shelf (GOTS) 409 | 410 | ### Build vs buy 411 | 412 | - some things are best purchased (database software) 413 | - mission-critical or proprietary business info is best built 414 | 415 | ### Outsourcing 416 | 417 | - can find cheaper programmers/people but most of a project's cost is not from the coders 418 | - has challenges due to geographic separation 419 | 420 | ### Contractual Terms and SLAs 421 | 422 | - should include references to security ctrls/standards 423 | --------------------------------------------------------------------------------