Security / Customer Story
Why
Remaining secure, while the impact on security processes and controls is reduced
What
Agile transformation of security processes
How
Implement trigger based policies to minimize overhead
Organizations must comply with regulatory policies, and failing to do so can result in steep fines or other repercussions. Security challenges have also changed rapidly. In a world dominated by web applications, mobile platforms, big data, cloud solutions and social interactions, the risks are no longer purely technical (such as encryption and network security). Businesses need to ask what’s necessary to the business and what merely increases the risks. Without a clear answer to these questions, security experts can only attempt to mitigate the technical risks, requiring much effort without minimal risk reduction.
Intergrated security
One problem is that many companies concentrate their security experts in focused departments where they perform business impact analysis, risk assessments, and penetration tests. There is often little daily interaction with the other business, operational, or development departments. To cope with the potential exposure and liability in today’s changing world, this has to change. Companies must implement strategic security in the software development lifecycle.
Multidisciplinary teams
A first glance, this might appear to be more challenging to accomplish than it is. Modern practices like Agile and DevOps have induced closer collaborations between business, development, and operational departments. The next logical step is to integrate security into Agile teams so security can be addressed continuously, throughout a project, rather than only at the beginning and end. Security experts should become more like counselors and trainers than cops. They should explain the risks and mitigations and coach development teams to come up with solutions. This approach, commonly referred to as SecDevOps, DevSecOps, DevOpSec, and Rugged DevOps, results in more secure applications without burdening the organization.
The KPN story
One of Xebia’s clients, KPN (a large Dutch telecom operator) was facing this challenge. Their landscape consisted of multiple back-ends and front-ends, each containing different information about the same customers. This fragmentation made it difficult for employees and users to gain insight into the complete profile. It also made it difficult to implement changes in the systems due to the many dependencies. With consultation, KPN decided to create a single front-end in front of the multiple back-ends. Using an Agile approach, they gained the flexibility to connect one system at a time and implement continuous improvements to the system.
Customer Profile
- Industry: Telecom & IT solutions
- Employees: 17.000
KPN Online
- Agile/SCRUM methodology
- Open, Selfcare and Mobile applications
- KPN Security Policy (several delete
hundred rules)
Before SecDevOps
- Security testing by third parties
- Focus on technical vulnerabilities
- Fix after find approach
Why SecDevOps
- Security integrated in SDLC
- Focus on mitigating threats
- Security awareness in teams
At first, this introduced friction with the, more project-based, security department. The KPN Security Policy consists of hundreds of rules that require validation before every production change. In an Agile environment, this validation would require an inordinate amount of time, especially with 20 scrum teams deploying every other week.
To cope with this problem, Xebia and KPN analyzed the complete policy and identified the circumstances most likely to trigger a rule. Based on this analysis, they created a questionnaire that highlighted relevant controls depending on the answers to less than twenty questions.
Going from a few hundred controls to a little more than a dozen questions might seem like an oversimplification. But the questionnaire acts as a smart filter. The full set of controls is still applicable, but the questionnaire identified only the relevant ones requiring actual validation. For example, anything related to personal or physical security is unlikely to be applicable during software development. They are now validated independently of sprints and at different intervals. During development, these controls are assumed to be in place and compliant.
Clear responsibilities
The biggest advantage of using the questionnaire is that responsibilities have become clearer. The full policy made it complicated to identify who was responsible, so nobody claimed ownership of any deviations. With the questionnaire, it’s immediately clear: “who’s responsible?”, “what are the dependencies?”, and “what is critical?”. This clarity allowed KPN to apply risk profiles with clear boundaries. As long as a team remains within the conditions set, there’s only a few controls that need proof of validation. When a team needs to cross a boundary, more controls become relevant.
This approach resulted in a better understanding of security within the teams. It made it easier to implement changes and reduced the time needed for validation. Production incidents have also decreased, proving that this approach works. Development and business can confidently apply changes without worrying about the security impact. They can focus more time on new functionality instead of spending it on fixing incidents. Integrating security into the software development lifecycle has catalyzed development within KPN.
