CISSP - DOMAIN 8 WITH COMPLETE SOLUTIONS 100%

CISSP - DOMAIN 8 WITH COMPLETE SOLUTIONS 100% Defining Good Code - Quality - ANSWER * 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 - ANSWER To address input, output, encryption, logical flow, methods for performing calculations, interprocess communication, access, and interaction with other software Defining Good Code - Security Controls - ANSWER * 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 - ANSWER * 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 - ANSWER * 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 - ANSWER * 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 - ANSWER 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 - ANSWER * 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 - ANSWER * 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 - ANSWER * 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 - ANSWER * 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) - ANSWER * Drives software projects being developed for specific customers * Helps clarify customer requirements Software Development Life Cycle - Project Management - Scope Creep - ANSWER * 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) - ANSWER * 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 - ANSWER * 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 - ANSWER * 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 - ANSWER * 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