Secure Development Lifecycle
Last updated
Robust Software
Last updated
Three "Good" examples:
Microsoft Security Development Lifecycle (SDL).
Software Security Touchpoints.
Software Assurance Forum for excellence in Code (SAFECode)
Cyber security-related training.
Elicitation of explicit security requirements.
Define metrics, report compliance
Apply Threat Modelling (security risks analysis).
Establish Design Requirements.
Define and use Cryptography Standards.
Manage security risk when using 3rd party components.
Use approved tools.
Perform static analysis security testing (SAST).
Perform penetration testing.
Establish a standard incident response process.
STRIDE approach
Spoofing Identity. (pretend to be someone else)
Tampering with data. (malicious modification of data)
Repudiation. (denying the performance of an action)
Information disclosure. (exposure of classified info)
Denial of service. (service unavailable or unusable)
Elevation of privilege. (access to more elevated privileges).
STRIDE, Attack trees, and Architectural Risk Analysis help enumerate threats and act upon the design to eliminate or control the impacts.
List assets/components.
Identify threats (e.g. with data flow diagrams).
Identify and classify (STRIDE) the vulnerabilities.
Not only guides the implementation of design features but also is resistant to known threats.
Saltzer and Schroeder security principles:
Economy of mechanisms (KISS).
Fail-safe defaults (failure = lack of access).
Complete mediation (apply constant authorizations).
Open design (use of keys and passwords).
Separation of privilege (multiple keys, if possible)
Least privilege (only the needed set of privileges).
Least common mechanism (minimize common mechanisms).
Psychological acceptability (user interface shall help).
Complementary to Saltzer and Schroeder security principles:
Defense in depth (redundancy in security).
Design for updating (security patches shall be easy).
Selection of security features, such as cryptography, authentication, and logging to reduce the risks identified through threat modeling.
Earn or give, but never assume, trust.
Use an authentication mechanism that cannot be bypassed or tampered with.
Authorize after you authenticate.
Strictly separate data and control instructions, and never process control instructions received from untrusted sources.
Define an approach that ensures all data are explicitly validated.
Use cryptography correctly.
Identify sensitive data and how they should be handled.
Always consider the users.
Understand how integrating external components changes your attack surface.
Be flexible when considering future changes to objects and actors.
Run-time verification of compiled or packaged software to check functionality that is only apparent when all components are integrated and running.
Use a suite of pre-built attacks and malformed strings that can detect memory corruption, user privilege issues, injection attacks, and other critical security problems.
May employ fuzzing, an automated technique of inputting known invalid and unexpected test cases at an application, often in large volume.
Similar to SAST, can be run by the developer and/or integrated into the build and deployment pipeline as a check-in gate.
DAST can be considered automated penetration testing.
An example of a commonly used tool is the american fuzzy lop
Penetration testing is black box testing of a running system to simulate the actions of an attacker.
To be performed by skilled security professionals, internal or external to the organization, opportunistically simulating the actions of a hacker.
The objective is to uncover any form of vulnerability - from small implementation bugs to major design flaws resulting from coding errors, system configuration faults, design flaws, or other operational deployment weaknesses.
A test should attempt both unauthorized misuse of and access to target assets and violations of the assumptions.
A resource for structuring penetration tests is the OWASP Top 10 Most Critical Web Application Security Risks.
Penetration testers can be referred to as white hat hackers or ethical hackers. In the penetration and patch model, penetration testing was the only line of security analysis before deploying a system.
Organizations must be prepared for inevitable attacks.
Preparation of an Incident Response Plan (IRP).
The plan shall include who to contact in case of a security emergency, establish the protocol for efficient vulnerability mitigation, customer response and communication, and the rapid deployment of a fix.
It shall also include plans for code inherited from other groups within the organization and for third-party code.
The plan shall be tested before it is needed!
Lessons learned (responses to actual attacks) -> factored back into the SDL.
