This is the final post in the series of four posts. In the first post, we covered the overview of our 3 phase approach to build an application security program, followed by a second post describing the first phase i.e. Assessment and 3rd post providing details on our second phase i.e. Design.
Today, we will discuss the final step i.e. implementing the application security program. This is the phase where we will make a decision on the strategy to implement and actually implement the program.
It is a known fact that the introduction of an application security programme in an organisation is not just a technical challenge, it also brings a big cultural change with it. It impacts the way people do their day-to-day tasks. Hence, it is important that we introduce the program in phases for easier adoption while discarding the big bang approach.
The figure below provides an example of how the twelve security practices could be divided in phases.
Figure 1 – Introducing Security Practices in Phases for Easier Adoption
In the first phase, we are only introducing foundational practices i.e. practices required to give direction to an application security program such as ‘Strategy and Metrics’ and ‘Policy and Compliance’. In addition, we introduce the practices, which we deem can be easily adopted by the teams based on the ‘Assessment’ results. E.g. if a development team is using static analysis for measuring code quality, it will more than likely be happy to adopt static analysis for identifying security vulnerabilities as well.
Some of the practices can be further broken down into multiple activities. In which case a practice itself may be introduced in phases e.g. ‘Security Testing’ (as demonstrated in above example) or may only be implemented partially, depending upon www.snanc.org business requirements.
Finally, Education is a practice, which is evolutionary and continuous. Therefore, attributing education to any one phase cannot be justified. Education doesn’t only refer to providing secure coding training to developers, but all the teams involved in the application security program are to be trained in performing the security activities they are accountable and/or responsible for. New courses are added and existing courses evolve throughout the life of the application security programme.
As demonstrated below, we can foresee the interim maturity state after the introduction of phase 1 and subsequent phases. This may also allow us to visualise if we are heading in the right direction in order to meet business objectives.
Figure 2 – Program Roadmap to Visualise Interim Maturity State of the Organisation
While dividing the security practices into phases makes it easier for application security processes to be introduced, we should not forget that it is all theoretical at this stage. And, a less effective process introduced to a large audience may become a reason for the organisation to lose trust in the program. Hence, the recommended approach to deploy the program is to start with introducing each phase as a PILOT to a small group, preferably those who participated in the assessment. During the PILOT, we monitor and analyse the impact of introduction of the programme. Based on the observations and feedback, we may need to adjust the processes designed in Phase 2.
As a second step (i.e. prior to introducing the programme to the wider community), we should create a program support team (i.e. a group of individuals from security and development teams) with keen interest and knowledge of application security. Once trained, this team will support the wider audience in effectively using the processes and/or technologies introduced through the programme.
Now, we introduce the programme to the rest of the organisation while continuously monitoring changes (due to the rollout) and periodically assessing what worked and what didn’t. We use this information to expand the programme, refining controls and, lastly, mandating the controls one-by-one.
This post was originally published by me at http://h30499.www3.hp.com/t5/Fortify-Application-Security/Building-an-Application-Security-Program-Part-4/ba-p/6631972