CISSP Domain 8 - Flashcards
Defining Good Code - Quality
- How fit for a purpose something is
- When developing software: It’s usually thought of after the fact
- Keys to ensuring quality:
- Code Reviews
- Interface Testing
- Misuse cases
Defining Good Code - Software Controls
To address input, output, encryption, logical flow, methods for performing calculations, interprocess communication, access, and interaction with other software
Defining Good Code - Security Controls
- Usually technical
- Will depend on:
- Application’s purpose
- Environment in which it will run
- Sensitivity of the data it will process
- Functionality it will execute
- Security policy attached to it
- Example: If software will only be run behind 3 firewalls and accessible only by an administrator, it will have fewer security requirements. If it is a publicly-accessible web application it will be subject to quite a few very restrictive security controls
Where Do We Place Security? - Introduction
- Software is responsible for the vast majority of vulnerabilities
- The importance of implementing proper security in software is a relatively new focus
- It is very uncommon to find a software developer who is also a security professional
- Software vendors are trying to get products to market as soon as possible and do not make security a priority
- Customers have become accustomed to receiving software with security flaws that are then patched
- Customers cannot fix the security flaws in software they purchase, so they resort to perimeter solutions
Where Do We Place Security? - Environment vs. Application
- Environment (At the OS)
- Great to ensure a consistent approach, but the OS has no visibility or control of access activities within an application
- Perimeter devices are more reactive in nature: they protect best against known vulnerabilities that are discovered over time
- Application
- Provides very granular control, but does nothing for security outside of the application, including any external resource the application requires
- The more functionality that is packed into an application, the more difficult it becomes to achieve a good level of security hygiene
Where Do We Place Security? - Implementation and Default Issues
- Software should default to ‘No Access’ after installation
- Security patches: Often not installed because the administrator:
- Does not keep up to date on security vulnerabilities
- May not realize the importance of applying patches
- Might fear the patches will cause other problems
Software Development Life Cycle - Introduction
SDLC: Concerned with creating a repeatable and predictable process that development teams will follow
- Desired results
- Higher level of product quality
- Fewer missed deadlines
- Lower cost
- Acceptable level of functionality
Software Development Life Cycle - Phases
- Requirements gathering: Figure out what the product will do when completed
- Design: Plan how the product will be put together
- Development: Put the product together
- Testing/validation: Make sure the product does what the requirements said it should do
- Release/maintenance: Ship the product and update as-needed
Software Development Life Cycle - Phases with a Security Perspective
- Requirements gathering
- Security risk assessment
- Privacy risk assessment
- Risk-level acceptance
- Informational, functional and behavioral requirements
- Design
- Attack surface analysis
- Threat modeling
- Development
- Automated CASE tools
- Static analysis
- Testing/validation
- Dynamic analysis
- Fuzzing
- Manual testing
- Unit, integration, acceptance and regression testing
- Release/maintenance
- Final security review
Software Development Life Cycle - Project Management - Introduction
- Ties together all of the pieces required to deliver a product
- Specifically ensures that each phase is addressed properly
Software Development Life Cycle - Project Management - Security management
- Part of PM in which a security plan is created from the beginning
- It must be able to stand alone and have its own lifetime
- Will be referenced after the project has been completed during audits and as a way to validate the product meets specific security objectives
Software Development Life Cycle - Project Management - Statement of work (SOW)
- Drives software projects being developed for specific customers
- Helps clarify customer requirements
Software Development Life Cycle - Project Management - Scope Creep
- Addition of new requirements not originally envisioned
* Project management must ensure that it adheres to the SOW closely to avoid it
Software Development Life Cycle - Project Management - Work Breakdown Structure (WBS)
- Defines the tasks and subtasks that are required to meet the stated requirements
- The SDLC depends on it to be accurate
Software Development Life Cycle - Requirements Gathering Phase - Focus
- What the finished product should be capable of
- What it should look like
- How it should behave
Software Development Life Cycle - Requirements Gathering Phase - Security related tasks
- Security requirements
- Security risk assessment
- Privacy risk assessment
- After completing it, we assign a privacy impact rating to each data element
- Privacy Impact Ratings
- P1: High Privacy Risk: PII is routinely handled and stored
- P2: Moderate Privacy Risk: PII is handled in a one-time, user-initiated data transfer
- P3: Low Privacy Risk: No PII is handled or stored
- Risk-level acceptance: All possible risks will probably not be addressed, so the team should address the most important ones first
Software Development Life Cycle - Requirements Gathering Phase - Models for Software Requirements
- Informational model: Lists the type of information to be processed and how they are processed
- Functional model: Lists the tasks and functions an application needs to provide
- Behavioral model: Lists the states the application will be in during and after specific transactions take place
Software Development Life Cycle - Design Phase - Introduction
- Takes each requirement and shows how the product will meet it
- Skipping this step: Unstable and insecure product
Software Development Life Cycle - Design Phase - Outputs
- Data design
- Architectural design
- Procedural design
Software Development Life Cycle - Design Phase - Attack Surface
- Portion of the application visible to an attacker
- It’s made as small as possible by reducing
- The amount of code running
- Entry points
- Privilege levels
- Unnecessary services
- Attack surface analysis
- Automated scan of an application resulting in a report
- Looks at files, registry entries, data stored in memory, session information, and process and service details
- End goal: Identify and reduce the amount of code and/or functionality that is accessible by untrusted users
Software Development Life Cycle - Design Phase - Threat modeling
- Imagining various malicious scenarios and designing the software to counteract the threats
- Threat Tree
- Useful tool to visualize and document various attack vectors into the software
- Visually shows each threat and how it is related to other threats
Software Development Life Cycle - Development Phase - Introduction
- The design is broken down into scheduled deliverables, and developers get down to work
- Computer-Aided Software Engineering (CASE) tool
- To auto-generate code
- Create automated tests
- Handle debugging activities
- Writing secure code is not an easy task
- Most vulnerabilities result from poor programming practices
Software Development Life Cycle - Development Phase - Common mistakes
- Not checking the input length to avoid buffer overflows
- Not inspecting code to prevent the use of covert channels
- Not checking/enforcing proper data types
- Not ensuring checkpoints cannot be bypassed by users
- Not verifying proper syntax
- Not verifying checksums
Software Development Life Cycle - Development Phase - Buffer Overflows
- Can result in Privilege Escalation:
- This is the act of exploiting a process or configuration setting to gain access to resources that normally are off limits to the process or user
- Can be mitigated by
- Using input validation
- Ensuring least privilege