Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
| Define security requirements | The software stakeholders should Identify and document security requirements early in the development life cycle and make sure that subsequent development artifacts are evaluated for compliance with those requirements. When security requirements are not defined, the security of the resulting system cannot be effectively evaluated. |
| Model threats | Use threat modeling to anticipate the threats to which the software will be subjected. Threat modeling involves identifying key assets, decomposing the application, identifying and categorizing the threats to each asset or component, rating the threats based on a risk ranking, and then developing threat mitigation strategies that are implemented in designs, code, and test cases |
| Practice defense-in- depth | Manage application risk with multiple defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense can prevent a security flaw from becoming an exploitable vulnerability and/or limit the consequences of a successful exploit. For example, combining secure programming techniques with secure runtime environments should reduce the likelihood that vulnerabilities remaining in the code at deployment time can be exploited in the operational environment |
| Adhere to the principle of least privilege | Every process should be executed with the least set of privileges necessary to complete the job. Any elevated permission should only be accessed for the least amount of time required to complete the privileged task. This approach reduces the opportunities an attacker must execute arbitrary code with elevated privileges |
| Deny-By-Default | User access decisions should be based on permissions rather than exclusion. This means that, by default, access is denied, and the protection scheme identifies conditions under which access is permitted. The system should set minimal or no permissions for new users/roles and users/roles should not receive access to new features until it is explicitly granted. |
| Validate input | Validate input from all trusted/untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user-controlled files. |
| Sanitize data sent to other systems | Ensure that all information sent to complex subsystems/external systems, including command shells, relational databases, and commercial off-the-shelf (COTS) components, is sanitized. Attackers might be able to employ SQL, command, or other injection techniques to access unused functionality in these components. Since the complex subsystem being called does not comprehend the context of the call, this is not necessarily an issue with input validation. The calling process is in charge of sanitizing the data prior to launching the subsystem because it is aware of the context. |
| Use effective quality assurance techniques | Vulnerabilities can sometimes be found and fixed using good quality assurance procedures. An efficient quality assurance program should include fuzz testing, penetration testing, and source code audits. Systems that have undergone independent security examinations may be more secure. External reviewers offer a distinct viewpoint, for instance, in spotting and correcting false assumptions. |
| Adopt a secure coding standard | Establish and enforce a secure coding standards for your target development language and platform. This principle will eliminate most of the security issues with code |
| Fail Securely | Implement controls and procedures that address security breaches in a safe and impact-free manner at the design and development stages. |