In the previous article we talked about the establishment of the program, its dissemination, definition of metrics and monitoring so that the program can be evolved. In this article we will talk about the importance of defining guidelines and monitoring.
Before we go into practice about implementation, we will understand the difference between policies and standards:
- Policies: Policies are formal statements produced and supported by senior management. They can be organization-wide, problem-specific or system-specific.
- Standards: Standards are mandatory actions or rules that support and guide formal policies.
In other words, the policy set assigns guidelines that must be followed by those involved in the scope of each policy, and standards are what must be done to meet these guidelines. We can use the ISO 27000 set of standards that certify an information security management system as an example. ISO 27.001 presents the guidelines and ISO 27.002 presents the details of what each guideline established in the previous one is.
Once the concepts are understood, it is important not to make a common mistake in initiatives within organizations, which is to define a set of extremely aggressive policies in the first instance. This will create a wall between teams and can lose sponsorship, because the goal of security is to enable teams to deliver secure software and not be a barrier to productivity. Set simple guidelines initially and improve after the program evaluation.
- Policies
Before any specific application security policy is developed, it is important that the practice is already being addressed in a corporate information security policy. A guideline defining the importance and commitment of the organization to the practice will help the teams’ involvement and commitment to the initiative.
Based on top management’s commitment to the practice, we should develop a set of policies that establish clear guidelines for each scope of action. Materials from the Open Web Application Security Project (OWASP) are important allies in this initiative. A good program has at least the following policies:
- Vulnerability management policy: establishes the guidelines that will determine the treatment of each vulnerability in the organization considering at least the accepted time for correction according to criticality and risk acceptance criteria.
- Third party software validation policy: any contracted application must meet the regulations that the organization is subject to in addition to having a security level and security management processes compatible with the risk appetite of the contractor.
- Testing and verification policies: establish which applications should be tested and why. The OWASP Application Security Verification Standard (ASVS) requirements guide can be used as criteria to establish an application criticality level according to the type of data and importance to the organization. Clearly define each type of test and the expected results of each. In the article on verification practices of the SAMM series that we are developing we will address the different types of tests and how each one fits into the life cycle of the application.
Each policy developed must consider the organization’s risk appetite and meet the regulations and criteria to which it is subject. One regulation we must be aware of in Brazil is the General Data Protection Law (LGPD). Another important guideline for companies that trade high volumes of credit cards is the PCI-DSS, a standard that has since its launch a requirement focused on application security and recently launched a program for certification of applications and processes.
In this content we address only application security-focused policies a number of other policies such as data classification, access control, incident response are part of an organization’s security initiative.
- Patterns
For policies to be followed and for those involved to be able to meet their guidelines, it is important that standards are developed to facilitate understanding. The standards should be clear and specific according to the behaviors of users and technologies involved.
Using the basic policies established in the previous topic we can use some OWASP and SAFECode models as standards to meet the following policies:
- Vulnerability Management: The OWASP risk rating methodology helps to establish the criteria to classify and prioritize the treatment of vulnerabilities according to the following characteristics:
- Threat Agent Factors
- Vulnerability Factors
- Technical Impact
- Business Impact
- Third Party Software Validation: SAFECode’s Framework for Software Supply Chain Integrity helps establish key criteria for practice:
- Chain of Custody
- Access with Minimum Privileges
- Separation of Duties
- Resistance to Change and Evidence
- Persistent Protections
- Compliance Management
- Code Tests and Checks
- Tests and Verifications: for this practice OWASP provides some mature and interesting models:
- Software Component Verification Standard (SCVS) addresses all Bill-of-Materials software management (SBOM)
- OWASP Code Review Guide addresses all manual source code security review practices
- OWASP Testing Guide addresses penetration testing of web applications
- OWASP Mobile Security Testing Guide addresses penetration testing of mobile applications
We have addressed some examples of standards, but specific materials according to the characteristics of each organization are needed – as are policies.
In addition to the development of standards, a mature program implements tools to guide and manage each of the standards, generating evidence for audits and indicators to mature the practice. A well-known model in technology companies are playbooks.
- Conformity Management
After all controls have been defined, it is important that the internal and external public of the organization monitor the compliance with the policies.
It establishes a clear channel so that internal teams and any supplier can know all the standards and present the fulfillment of each of the requirements.
For suppliers, it is important to pay attention to existing and new contracts that will be signed. OWASP provides a contract model of attachment so that suppliers are aware of the obligations related to software security.
- Conclusion
In this article we can observe the importance of policies and standards aligned with internal and external audiences, in addition to monitoring to meet legal obligations and process improvement.
In addition to the standards addressed in the following articles, we will address threat modeling and requirements definition that will guide and evaluate the actions of the teams involved in software development.
SAMM articles series
- Governance according to SAMM: Strategy and Metrics in Application Security
- Governance according to SAMM: Policies and Conformities in Application Security
- Governance According to SAMM: Application Security Education and Guidance
- Design according to SAMM: Threat Modeling in Application Security
- Design According to SAMM: Security Requirements in AppSec
- Design according to SAMM – Secure Architecture in Application Security
- Implementation according to SAMM: Secure Build in Application Security
- Implementation according to SAMM: Secure Deployment in Application Security
- Implementation According to SAMM: Defect Management in AppSec
- Verification according to SAMM: Application Security Architecture Analysis
- Verification according to SAMM: Requirements-Driven Testing in Application Security
- Verification according to SAMM: Security Tests in Application Security
- Operations according to SAMM: Application Security Incident Management
- Operations according to SAMM: Environment Management and Application Security
- Operations according to SAMM: Operational Management in Application Security