Implementation -> Application Hardening: Application Hardening Level 1
Risk and Opportunity
Risk: Using an insecure application might lead to a compromised application. This might lead to total data theft or data modification.
Following frameworks like the
- OWASP Application Security Verification Standard Level 1
- OWASP Mobile Application Security Verification Standard Level 1
in all applications provides a good baseline.
Required knowledge: High (two disciplines)
Required time: High
Required resources (systems): Low
To tackle the security of code developed in-house, OWASP offers an extensive collection of Cheatsheets
demonstrating how to implement features securely. Moreover, the Security Knowledge Framework offers an extensive library of code patterns spanning several programming languages. These patterns can be used to not only jumpstart the development process, but also do so securely.
Planning aka Requirements Gathering & Analysis
The Requirements gathering process tries to answer the question: "What is the system going to do?" At this stage, the SAMM project offers 3 distinct maturity levels covering both in-house software development and third party supplier security.
Organisations can use these to add solid security considerations at the start of the Software Development or Procurement process.
These general security considerations can be audited by using a subsection of the ASVS controls in section V1 as a questionnaire. This process attempts to ensure that every feature has concrete security considerations.
In case of internal development and if the organisation maps Features to Epics, the Security Knowledge Framework can be used to facilitate this process by leveraging its questionnaire function, shown below.
Source: OWASP Project Integration
OWASP SAMM 2 Mapping: software-requirements|A|1
ISO27001:2017 Controls Mapping:
- hardening is not explicitly covered by ISO 27001 - too specific