This is the 3rd post in the series of four posts. In the previous post, we looked at the first step of building an application security program i.e. Assessment.
In this post, we will discuss the proven approach to design an effective and scalable application security program for an enterprise.
By the time we enter the Design phase, we already have an understanding of organization’s security culture including:
- Software security objectives
- Security activities being performed and corresponding effectiveness
- Strengths and weaknesses of existing software development and security teams as well as processes
In design phase, we further process this information to identify the actual gap between the current level and the desired level of software security maturity. We create a plan to fill the identified gaps while leveraging the organization’s development team’s strength. For which, we take the data collected during assessment and mix it with industry best-practices in order to produce lightweight, easy to adopt processes and actionable guidelines that can be easily introduced in the organization.
The artifacts produced during the design phase and the approach to create these artifacts is explained below:
Security Requirements: Almost every organization needs to comply with requirements enforced by one or more government or industry regulatory bodies to stay in the business. Hence, we start with identifying the software security requirements and processes the organization must perform to satisfy compliance mandates. These requirements are then correlated to other security requirements compiled to achieve business objectives. The resultant list is a single comprehensive set of security requirements that the programme needs to achieve through adequate and effective usage of people, process and/or technology. A set of technical controls with implementation instructions is also created to fulfil the defined security requirements.
Secure Software Development Lifecycle: Next step in the design phase is to create a secure Software Development Lifecycle which is the core of any application security programme. It is not recommended that a new armodexperiment.com process be created from scratch unless absolutely necessary. Instead, we should take the organization’s existing SDLC process and improvise it by seamlessly weaving the security activities in it while ensuring the process enables the organization to meet the security requirements compiled earlier. The secure SDLC should clearly identify which security activities are to be performed manually and which could be automated.
Roles and Responsibilities: Several application security programmes fail despite having a good, secure SDLC. This is mostly because, although security activities have been defined within the SDLC, no one is made responsible or accountable for the execution of these activities. Therefore, it is very important to clearly identify the responsibilities and accountabilities for the defined security processes and activities.
In the image below, a sample RACI chart is shown for static code analysis activity. It explicitly defines that the Development Team Lead is accountable for scanning the code, whereas the Information Security Team is responsible for triaging the results of static analysis with the consultation of development teams.
Application Risk Classification Criteria: Not all applications pose the same risk to the organisation hence, it is not viable to perform equivalent security measures on all applications. To overcome this, we create “Application Risk Classification Criteria” in which we can utilise the application attributes such as data being handled by the application, accessibility, business criticality, etc to define the potential risk of the application. This can help development teams identify security requirements the application must comply with and which technical controls are to be implemented to fulfil these requirements.
Software Security Education Matrix: It is a known fact that an application security program requires a thorough, role specific and methodical software security education program to be successful. Hence, we use the assessment results to identify the area of focus and create a training matrix suggesting what role specific trainings are required.
Once all these artefacts have been prepared, we are ready to move into our next phase which is implementing the application security program. This will be discussed in the next and final post of the series. Stay tuned!
This post was originally published by me at http://h30499.www3.hp.com/t5/Fortify-Application-Security/Building-an-Application-Security-Program-Part-3/ba-p/6599960 .