Domain Summary: CISSP Domain-8 

Short description

Pros

Cons

Best suitability

Waterfall Model

A linear and sequential approach with distinct phases.

Each phase must be completed before the next begins.

Simple and easy to understand and use.

Clear milestones and structured process.

Inflexible (rigid), especially with changes.

Late testing can lead to higher costs.

Best for well-defined projects with minimal expected changes.

Incremental Model

Develops a system through repeated cycles (increments) and adds features in each increment.

Each increment is fully functional and can operate independently.

More flexible than Waterfall.

Early releases for testing and feedback.

Needs good planning and design.

This can lead to higher costs over time.

Suitable for projects where functionality can be delivered in phases.

Prototyping

Creates prototype (small model) before actual development.

Early feedback, and more user involvement.

This can lead to insufficient analysis.

Projects with unclear user requirements.

Spiral

Combines design and prototyping in stages, emphasizing risk analysis.

Each cycle involves planning, risk analysis, engineering, and evaluation.

Focus on risk assessment and reduction.

Highly flexible and adaptable.

Complex and can be more costly.

Requires expertise in risk evaluation

Ideal for high-risk projects requiring iterative risk assessment

Joint Application Development (Jad)

Brings together business stakeholders and developers in collaborative workshops.

Focuses on consensus and collaborative decision-making.

Encourages stakeholder involvement and feedback.

Rapid development and delivery.

Can be time-consuming.

Depends heavily on stakeholder commitment.

Projects requiring extensive user interaction.

Projects where user requirements are a major factor.

Rapid Application Development (RAD)

Emphasizes rapid development and iterations.

Faster development reduces risk.

Depends heavily on a strong team and user involvement.

Small to medium projects with tight schedules.

Cleanroom Model

Cleanroom focuses heavily on mathematical models to deliver defect-free software

High quality, less error prone.

Can be rigid and time-consuming.

Focuses on defect prevention, ideal for critical systems needing high reliability

Kanban

Kanban focuses on visualizing workflows and improving process efficiency

Extreme Programming (XP)

XP emphasizes technical excellence with practices like test-driven development (TDD) and pair programming.

Learn Methodology

Lean methodology focuses on minimizing waste (gaps), maximizing value, and facilitating faster delivery of products.

Scaled Agile Framework (SAFe)

Scaled Agile Framework (SAFe) is a structured approach for scaling Agile practices across large organizations. SAFe is a comprehensive framework to align multiple teams, stakeholders, and business goals while maintaining Agile principles. SAFe incorporates roles, events, and artifacts to manage complex, large-scale projects efficiently by aligning the business team with the technical teams toward shared goals. The SAFe framework emphasizes lean thinking and continuous delivery.

I recommend you visit the Scaled Agile Framework to get a practical feel of the framework.

CI/CD stands for Continuous Integration and Continuous Delivery/Deployment. CI/CD helps streamline the development process, ensuring high-quality software is delivered rapidly and efficiently. CI involves the practice of automatically integrating code changes into a shared repository multiple times a day. Each integration is verified by automated tests to detect errors early, while CD is the practice of automatically preparing code changes for production release. After the code passes tests and is integrated, it’s made ready for deployment to production, ensuring it can be delivered at any time with minimal manual intervention.

Software Engineering Institute (SEI) at Carnegie Mellon University

Process improvement in software engineering and organizational development

Process performance, capability, and improvement

5 Levels: Initial, Managed, Defined, Quantitatively Managed, Optimizing

OWASP

Software security assurance

Software security practices

3 Levels: Initial, Repeatable, Defined

Synopsys (created independently)

Software security practices in real-world software development environments

Descriptive model based on real-world data

3 Levels: Basic, Deployed, Advanced

HTML is a standard markup language for creating and structuring web pages and web applications. These languages may be susceptible to Cross-site scripting (XSS) and malicious file uploads. It is recommended to sanitize and validate user input and use a Content Security Policy (CSP).

Content Security Policy (CSP)

CSP is a security standard designed to protect web applications from various types of attacks, such as Cross-Site Scripting (XSS), data injection, and clickjacking. It helps developers define a set of rules that specify which sources of content are considered trustworthy. This mitigates the risk of malicious scripts being executed within the browser

CSP can enhance security by limiting JavaScript execution to only scripts hosted on the developer's domain, preventing inline script tags to reduce injection attacks, and also including a report-URI directive to mandate browsers to send reports when a violation happens.

CSS is a style sheet language used for describing the presentation of a document written in HTML or XML. CSS can also be susceptible to Cross-site scripting (XSS) via style injection and clickjacking attacks and hence it is important to validate and sanitize all inputs and use secure Content Security Policy (CSP) settings.

JavaScript is a scripting language for creating dynamic and interactive content on web pages and providing additional functionalities. While JavaScripts are heavily used, they might also be susceptible to Cross-site scripting (XSS), Cross-site request forgery (CSRF), and Code injection. It is recommended to sanitize user input, Use CSP and Sub resource Integrity, and Implement proper error handling.

Python is a high-level, interpreted programming language with dynamic semantics, used for web development, scripting, data analysis, and more. The code may be susceptible to code injection, command injection, and Cross-site scripting (XSS) when used in web applications and hence it is important to validate and sanitize user input, Use secure coding practices, Implement access control and authentication mechanisms.

Libraries provide reusable routines or functionalities to simplify software development. Libraries often include security-focused functions and routines. Outdated, insecure, and external libraries, if not properly managed may lead to compromise and supply chain risks.

From a security perspective ensure we use libraries from reputable sources only and keep them updated to address security vulnerabilities. While using a third-party library, ensure we conduct a dependency check using tools like OWASP Dependency-check, npm, etc., ensure their integrity is intact by validating the checksum or signed release and scanning them for vulnerability before integrating them. If some Libraries require licensing terms, validate licensing as per the organization's licensing policy and try to automate the checks using appropriate tools like FOSSA, Sonatype Nexus, etc.

IDE is a software that provides an interface and features for developers to facilitate writing, editing, and managing source code. Modern IDEs come with integrated features like code analysis, secure coding standards, and version control integration. It is important to use feature-rich IDEs for development in an isolated environment and keep them updated with the latest versions, plugins, and extensions. Integrated features to detect vulnerabilities during coding should be enabled to facilitate secure coding.

Identify and resolve software bugs, manage bug reports, and track debugging efforts. Help in identifying security vulnerabilities in code; bug databases can track security-related bugs.

Compilers translate source code into executable programs, optimize code, and check for syntax errors. Use compilers that offer security features like buffer overflow protection and code sanitization.

Developers use a lot of testing tools to automate the process of verifying and validating that a software program or application meets its requirements. The security team gets involved in validating the test cases for effective security.

SAST is performed to analyze source code or compiled versions of code to find security flaws when the code is static without running the program. The various methods used for SAST are as follows:

·       Manual Code reviews and Peer code reviews

·       Automated Static Analysis Tools involve scanning the source code or binaries to detect vulnerabilities automatically.

·       IDE plugins highlight the potential vulnerabilities while the developers write the code.

·       Integrating SAST tools into the CI/CD pipeline during the build phase.

·       Usage of custom scripts

The PRIMARY advantage of SAST is that it can detect issues early in the development cycle and can identify the following types of vulnerabilities.  

·       Code level vulnerabilities like buffer overflows, SQL injection, and hardcoding secrets (passwords and API keys)

·       Validation of secure coding practices

·       Analyze Data flow issues like potential leaks or misuse

·       Dependency analysis on third-party libraries for known vulnerabilities

·       Identity any logical flow errors like race conditions, insecure loops

·       Identity any hardcoded secrets in the code

·       Validating adherence to specific code-level requirements to industry regulations like PCI-DSS, HIPAA, or GDPR.

The downside of SAST is that it cannot identify runtime issues and often requires expert analysis.

Software Composition Analysis (SCA) is the process of identifying and managing the Third-party and open-source components, libraries, and dependencies used within a software application. It focuses on analyzing these components for security vulnerabilities, licensing compliance issues, and outdated versions by comparing detected components against vulnerability databases (e.g., NVD, OSS Index) and license databases. SCA can be integrated into development workflows. SCA can be performed during development, build, before deployment and also when the application is in production.

DAST involves testing an application during runtime to find vulnerabilities that are only detectable when a program is running. DAST tools interact with the application as a black-box tester and simulate the actions of an attacker to uncover security issues in real time. The various methodologies used for DAST may include:

 Crawling: to crawl the webpages or application modules to identify exposed attack surfaces like forms, API, URLs

 Fuzzing: inputting malformed data to see the security behavior of the application.

 Authentication Testing: checks for attacks like brute force, session hijacking, or credential stuffing.

DAST can identify a wide range of vulnerabilities in the application which may include Injection flaws like SQL Injection, command injection, Cross-site Scripting (XSS), Broken authentication, Security misconfigurations, Sensitive data exposure, CSRF, and server-side issues.

IAST combines aspects of both SAST and DAST by testing applications from within using instrumentation during runtime. It provides the benefits of both SAST and DAST, offers more accurate results, and reduces false positives.

IAST is getting more popular now as the IAST tools can be seamlessly integrated into DevSecOps CI/CD pipelines (automation) to provide real-time security feedback during testing. IAST is also suitable for applications where both source code and live running are accessible and continuous testing is needed.

It is an approach in which any new software version is first released to a small subset of users. This small subset of users or servers is called a canary and once the version is rolled out to this subject, it is closely monitored for behavior (feedback) and performance. In layman’s language before deploying any changes, we test it out in a pilot phase. The whole idea is to test the stability and functionality of the new version in a production environment with real users but on a limited scale.

Canary Deployment: Canary deployments extend the idea of canary testing to the deployment process. Any new software version is deployed first to a small subset of users before any large-scale deployment.

This is the setup where the developers write and test codes, build new features, fix bugs and experiment any new ideas.

Security recommendations

· Development infrastructure should be separated from production and the developer's access to production data should be restricted.

·  It is recommended for developers to have separate accounts for development and production where the production accounts are strictly controlled with the least privileges as per role-based access controls.

·   The development environment should not have access to any production data.

·    All development accounts should be removed from the product before pushing to the test environment.

The test environment is for quality assurance personnel who need to validate the functionality, performance, and reliability of the software before it moves to production. It is often a replica of the production environment.

Security recommendations

·       Ensure the test environment is separated from development and production.

·       Do not use live production data for testing as production data may contain sensitive information like PII. If there is a pressing need, make sure to sanitize or anonymize production data before usage in testing.

·       Access should be limited to the QA team

This is the environment where the software is finally run to mimic the production environment (like a lab). Staging mirrors the production environment but remains isolated with no direct production dependencies.

Security recommendations

·       The testing must be performed with dummy accounts and not real production accounts

·       All integration with real production applications and api should be disabled.

This environment runs on a secure and hardened infrastructure and must be separated from the dev/test/staging environment.

Any sensitive data should be encrypted, and access is restricted to only essential personnel.

Security Considerations during Acquisitions of Commercial Off-The-Shelf (COTS)

·       The term refers to ready-made software purchased from vendors and used as-is. This approach is good when the organization has standard requirements and may not need customized features. The advantage of COTS is that the functionality can easily be verified or confirmed by the vendor. Often these software are verified by independent parties (certifications) and software updates are readily available, however, we should be aware of the risks involved with COTS; these are:

·       Inability to validate code-level vulnerabilities: Since the software is provided by a third party and acts as a black box for the user (no internal code visibility), the organization does not have the accessibility to perform SAST on the source code. COTS may be more often subject to Common vulnerabilities like Privilege escalation, Buffer overflow, etc.

·       There are chances that the vendor may go out of business which might impact the company operations. It is advisable to assess such risk and if the possibility is deemed high, Code escrow services can be taken up with mutual agreement. Code Escrow is the secure storage of a software source code with an Independent third party and the code is released to the licensee under specific agreed-upon conditions like vendor going out of business or bankrupt.

The organization should maintain an accurate inventory of COTS software and components and track their licenses. Organizations must integrate Risk Management Practices for COTS and evaluate risk periodically through activities like threat modeling, vulnerability assessment, and pen testing. A thorough risk assessment on the architecture and related vulnerabilities should be performed. Finally, as Static Application Security Testing (SAST) is not an option in COTS, try implementing additional controls like IDS/IPS, WAF, or compensating controls to keep the risk within acceptable limits.

Security Considerations during Acquisitions of  Open-source software (OSS)

The Organization leverages software with source code that is freely available for modification and distribution. This approach may reduce costs but requires careful management of security and compliance aspects. Here are a few risk related to OSS:

 Copyleft Issues: Many OSS are free to be used, modified, and distributed for individual and commercial use, however, as a CISSP you must clearly understand the licensing term in consultation with the legal team before integrating open-source code or modules in the commercial software, as few OSS agreement requires the source code to be made freely available.

 Technical Skills: OSS can be complex to use and require high technical skills for usage. Ensure your team understands the solution better and has the required technical skills.

 Support and Updates: In some cases, OSS may lack dedicated support and timely patches as such projects are mostly run through donations. Ensure you perform a sufficient evaluation before starting to leverage such software.

 Validate Sour Code Integrity: Since OSS code is available equally to good and bad guys. Bad Guys can insert malicious code and package them, Ensure to download OSS from official repositories after appropriate code validation. 

Security Considerations during Acquisitions of Third-Party Software

In this approach, the Organization outsources the software developed to an external entity. This approach offers the required customization but relies on a third party for updates, security, and support. Selection of third party should be based on specific skill set and expertise. The agreements with the Third party should take care of secure coding aspects like the manual code review can be performed by the third party and company in-house developers. Another approach can be to make sure the product is certified by an independent third party of assurance. 

Security Considerations during Acquisitions of Managed Services

Many companies outsource their IT and security infrastructure to be managed by a third party so that the business can focus on their core expertise. In such cases, the managed service providers may use their software or integrate existing software with their software through secure APIs. Managed services often include security monitoring, network monitoring, technical support, help desk, and so on.  It may include services like cloud-based solutions where the provider is responsible for the software's operation, maintenance, and security. Timely and periodic validation of the managed service provider security posture and practices is important which may include reviewing their compliance audit reports for SOC2 type 2, CSA Star Audit reports, and so on. 

 SQL Vulnerability

If an application lacks input validation, an attacker can inject malicious input to manipulate the backend SQL query to access or modify the database data.  

Example: Injecting ' OR '1'='1'-- into a login form to bypass authentication

In this case, the application is not validating or sanitizing the highlighted data above due to which the SQL query gets dynamically generated to bypass authentication.

SQL Injection may lead to loss of confidentiality, and authentication bypass, and the attacker can read and modify database information.

1. Use of Parametrized Queries can ensure that user input is treated as data, not executable SQL.

Example: SELECT * FROM users WHERE username =? AND password = ?;

2. Implement strict input validation and sanitization on the frontend application

3. Use of prepared statements – it’s a specific implementation of a parametrized query in which the query is precompiled and stored by the database

These are pre-written programming APIs built in the software library which developers can use to develop software applications.

These are pre-written APIs available as part of the Operating System (OS) which facilitate the interaction of various applications with the underlying Operating System

These are APIs used for building and interacting with Web-based services running on different devices and Platforms (OS)

Only acceptable for completely open, read-only APIs with no sensitive data involved.

Easy to implement but not very secure on its own. There is a Security risk if credentials/API keys are intercepted.

This approach is often used with other methods like HTTPS.

Enterprise-focused, for single sign-on (SSO), however, it can be complex to implement.

Provides message integrity and signature, However, the keys must be handled securely.

A secure and widely adopted standard that provides fine-grained access control.

Assume all inputs from users as untrusted and implement client-side and server-side input validation. It is important to implement server-side validation as the client's side input validation can be circumvented by the attacker through disabling the validation script or modifying the data after validation (data diddling) before it is sent to the server.

Encoding output refers to the process of converting potentially harmful characters within data before it's displayed on a webpage or sent to other systems. Encoding the output ensures that any harmful data injected by the attacker in the input field is rendered harmless preventing them from getting executed resulting in the prevention of Cross-Site scripting (XSS). E.g. Special characters like <, >, ', and " are replaced with their HTML entities (e.g., &lt;, &gt;, &apos;, &quot;).

Implement robust authentication like Multi-Factor Authentication to verify user identity and ensure authorization is based on the least privilege principle.

While error messages help in troubleshooting, errors displaying internal information of the software can provide internal insights to the attacker leading to attacks. Play a balancing role so that the error does not reveal sensitive information to the attackers about the internal structure of the application.

Use secure cookies with parameters like HttpOnly, Secure, and SameSite=Strict, proper session timeouts, and other measures to protect session data.

Use encryption, tokenization, and access controls to protect sensitive data. Use strong cryptographic ciphers and protocols to ensure the security of data at rest or in transmission.

Securely configure the application and its environment, including the web server, database server, and operating system

Ensure the file upload feature only allows the specific file format, else attackers can upload web shells to take control of the systems.

If an application ingests more data than it is designed for, it may lead to a buffer overflow attack. Ensure to follow good memory management practices.

Coupling is the degree of dependency between different modules or components. This is due to various modules sharing data structures unnecessarily, which should be avoided. It would be preferred to keep the Coupling LOW to prevent difficulty in maintaining, test, and scaling the software.   

Cohesion is the degree to which the elements within a single module are related and work together. A software developer should maximize the internal relationship within a module to make it self-contained and ready to be reused. Hence, HIGH Coupling is preferred.