Latest Secure Software Design Checklist

Secure Software Design Checklist

The Secure Software Design Checklist is a comprehensive guide for software architects, developers, and engineers aiming to create robust, secure applications from the ground up. This checklist focuses on embedding security best practices into the design phase of the Software Development Lifecycle (SDLC), ensuring vulnerabilities are mitigated before they become costly issues.

Secure Software Design Checklist
Security Mechanisms & Principles
	1. Is the Design simple enough to implement security? 2. Does the design address security and privacy concerns? 3. Does the design document address Confidentiality, Integrity and availability as required? 4. Does the design describe how to securely implement and deploy all functionality required by a given feature or function? 5. Verify that all protection levels have an associated set of protection requirements, such as encryption requirements, integrity requirements, retention, privacy and other confidentiality requirements, and that these are applied in the architecture. 6. Does the design specifications considers ‘Least privilege’ where Rights are minimum and users granted access explicitly? 7. Are project teams provided with a list of recommended third-party components? 8. Are project teams building software from centrally controlled platforms and frameworks?
Attack Surface Analysis
	1. Does the design address and document the common types of attacks it faces from attackers? 2. Does the attack surface Analysis categorizes the attack surface into logical parts based on based on function, design and technology such as: • Sign-in/authentication entry points • Administration/Operation interfaces • Inquiries and search functions • Data entry/CRUD forms • Business workflows • Transactional interfaces/APIs • Operational command and monitoring interfaces/APIs • Interfaces with other applications/systems 3. Does the attack surface Analysis documents the various entry and exit points into the system such as: • User interface (UI) forms and fields • HTTP headers and cookies • APIs • Files • Databases • Other local storage • Email or other kinds of messages • Run-time arguments 4. Does the attack surface analysis document the functions and what parts of the system need to be reviewed/tested for security vulnerabilities? 5. Does the attack surface analysis identify and document the high risk areas of code that require defense-in-depth protection – what parts of the system that you need to defend.
Threat Modelling
	1. Is the Threat Modelling process following the steps such as: Step 1: Decomposing the Application Step 2: Determining and ranking threats Step 3: Determining countermeasures and mitigation for the threats. 2. Does Decomposing the application produce enough information about the following: a.External dependencies b.Entry Points c.Assets d.Trust Levels for external entities e.Data Flow Diagrams 3. Does the Determining threats activity categorize the various threats and define security controls to mitigate the respective threats. 4. Does the Determining Threats procedure follows the STRIDE methodology by considering the attackers goals such as: a. Spoofing b. Tampering c. Repudiation d. Information Disclosure e. Denial of Service f. Elevation of Privilege. 5. Does the Threat Analysis include Threat ranking based on risk factor posed by the various identified threats. Does the risk ranking/risk prioritization follows the Microsoft DREAD model or any generic model? 6. Does the Threat Analysis include protective measure (e.g. security control, policy measures) in place that can prevent each threat previously identified via threat analysis from being realized? 7. If the Threat analysis provides any Non-mitigated/Partially Mitigated threats what are the suggested alternate mitigation strategies?
Data Protection
	1. Does the design document provides mechanisms to secure sensitive data at rest/in transit? 2. Is the design document considering how the sensitive data is protected from unauthorized access?
Input and Output (I/O) Architecture
	1. Verify that input and output requirements clearly define how to handle and process data based on type, content, and applicable laws, regulations, and other policy compliance. 2. Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that adequate integrity controls (and possibly encryption if sensitive data is sent) are enforced to prevent deserialization attacks including object injection. 3. Verify that input validation is enforced on a trusted service layer. 4. Verify that output encoding occurs close to or by the interpreter for which it is intended.
Communication Security
	1. Does the design document secure the communication between enterprise systems/service access clients? 2. Does the communication uses standard technologies like HTTPS, SSL, TLS protocols to communicate securely?
Environment and Tools Specification
	1. Whether the designer specified the Application Environment Requirements for deploying and securing the application. 2. Whether the technical architect specified the Tools, Technologies and frameworks to be used for application development.
Secure Authentication Architecture
	1. Whether the design mentions the use of unique or special low-privilege operating system accounts for all application components, services, and servers. 2. Ensure that communications between application components, including APIs, middleware and data layers, are authenticated. Components should have the least necessary privileges needed. 3. Ensure that the application uses a single vetted authentication mechanism that is known to be secure, can be extended to include strong authentication, and has sufficient logging and monitoring to detect account abuse or breaches. 4. Ensure that all authentication pathways and identity management APIs implement consistent authentication security control strength, such that there are no weaker alternatives per the risk of the application.
Errors, Logging and Auditing Architecture
	1. Verify that a common logging format and approach is used across the system. 2. Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation.

Suggested Exercises: Secure Software Requirements and Design Tests