It was not the best time at Initech. In a demonstration with senior management a representative of a well-known security company hacked their application, that caused a security audit to be performed to it and the report for it was more than one hundred pages long with tens of vulnerabilities ranging from minor to critical. All in a sudden security, that so far has never been considered, became very important and the senior management demanded the situation to be fixed.
As the leader of the department that developed and maintained the infrastructure and the platform services Tom was assigned the task of improving the situation. After some thoughts he decided to create a new position, called Security Architect, reporting directly to him with the mandate to make security a part of the development process for new services and prioritize and push to the various team backlogs the issues found during assessments. The position was then offered to Bob, and this was a controversial choice. Bob was at the time the architect for another Initech department and was recently one of the key people who saved the company’s most important project from failure, but he had no previous security experience and was well known for his poor social skills and lack of diplomacy, that caused him to clash with many people both from technology and other branches of the organization.
Bob was at the time looking for new challenges so he quickly accepted the position, thinking that his development background and interest in processes would compensate for the lack of specific security knowledge, and not that long after started working together with Nick, Initech’s lead architect, analyzing the situation and seeing what actions could be taken. They very soon realized that there were two issues to be tackled:
- Lack of security knowledge in the development teams: only a minority of the developers were aware of the principles of secure software development and how to apply those in practice.
- Security not considered at all when designing and implementing new functionalities, only at the end reacting to security audit results.
To address the first issue Bob worked with Initech’s security provider to create a training program for all members of the technology department. The plan had two training sessions, once per year, one focused on the OWASP top 10 vulnerabilities for web applications and STRIDE modeling, mandatory for everyone in technology, the “basic training” and one “advanced” session whose content was defined based on the need of the moment (for example one year it was focused on mobile applications and sites, another year on services running in docker, etc). In some occasions there were also additional trainings for other target groups, like a special training for content editors.
For the second issue Bob and Nick decided to dedicate the instance of architect forum meeting before the release train would start to a special program: architects would describe there what feature are planning to release, the results of the risk analysis they did in their teams on those and their recommendation if a security audit for the feature is required or not. Bob and Nick could then ask questions on those and eventually Bob would decide if a security audit is required or not.
To measure if the process would be working or not Bob decided to run an application wide security audit every year and see if the quality level would increase (less vulnerabilities found and with lower severity) or not.
This plan was presented to Tom and to the CSO, who quickly approved it, and then presented to the team architects and taken into use. The first training sessions have been given and the risk analysis process was taken very seriously by all the teams. In a few month times the amount of vulnerabilities found by auditing new features went considerably down together with their severity, critical vulnerabilities became the exception rather than the rule. Also teams became accustomed to run risk analysis on their own so after less than one year Bob decided to drop the formal review of those in the architect forum, knowing that he could trust the teams on such matter and that he would be contacted if they had doubts or if they decided that a new feature would need to be audited.
This process ran for many years and its results can be summarized by the comment one of the security auditors gave to Bob: “it became very difficult to find any security issue in Initech’s application”. This experience has shown that:
- It is possible to embed security into an existing development process without having to do very complex things.
- Training is a key thing. Without awareness no security process can work. Also trainings must be kept relevant for the context of the company (so things like talking about mobile applications to a company that only has a web based application or showing php code examples in a Java company must be avoided).
- Support from senior management is needed.