Software security is an important part of the overall security in Telenor Digital. The outset for building secure software in Telenor Digital is to embrace the opportunities that DevOps approaches like agile, continuous integration and continuous delivery give us to improve security. As our organisation doesnt have a massive history of legacy systems and legacy ways of working we are allowed to tap from some of the most recent practices for securing our code. It is the ideal starting point for a journey to improve our software security.
Software security is the idea of engineering software so that it continues to function correctly under malicious attack.It is about designing software to be secure, making sure that the software is secure, educating developers, architects and users about how to build secure things.
On the other hand application security is about protecting the software after the development is complete. For example by protecting against malicious code, locking down executables, monitoring programs as they run etc (1) It is generally agreed that the best option is to build secure software from the start. In the long run it is easier to build security in than to protect code. Software security is about helping builders to do a better job and to design for security so that malicious attacks get difficult.
The state of software securityAs stated by Mark Andreesen, maybe best known from being the one of the coauthors of one of the first widely used web browser mosaic- in a 2011 wall street journal essay “software is eating the world”. More and more software is built into things - and more and more is actually virtualized or digitalised. Industries are disrupted by software. Or more pessimistically put by Josh Corman in a OWASP AppSec Conference presentation: “Software is infecting the world. In other words we need to build security into the software in order to create the necessary foundation for trust.
Lets take a look at the state of software security as of today. Statistics from CVE, a dictionary of publicly known information security vulnerabilities and exposures, shows this year a significantly lower number of such vulnerabilities than earlier years.
SANS has published as study that shows that the gap between so-called Defenders i.e. the security and operations teams responsible for securing applications and running secure systems and Builders developers and development organisations is decreasing. According to SANS reliable and secure systems is dependent on these groups climbing out of their silos and more closely together. The study shows this is already happening However while we are working in the right direction we still need a bigger effort: Management must provide developers with time, tools and training to build secure systems Developers must understand that they share important responsibilities for security. Security and operations teams must understand and adapt to the ways development is changing and accelerating.
Software building practices are changing and offer opportunities to improve security that we must embrace.
The software (security) development lifecycle (SSDL) is important in ensuring predictable quality of the security work as it helps developers build more secure software and address security compliance requirements.
Disadvantages to traditional approach to security in a SSDLBefore looking at how newer software building practices allow building security in, we will take a look at some of the disadvantages of the traditional approach to security in a SSDL that we would like to improve.
Traditional approaches to software the SSDL includes extensive documentation, often extensive requirements analysis and design and risk analysis before development. After development there were extensive test periods where all kinds of checks were done including manual check-off by the security officer before code went into production. This approach implied long feedback and learning loops for security as it might have been a long period of time between when risk analysis was performed and when the security checks were completed.
Security benefits from short feedback and learning loops for security. Getting feedback shortly after the code is committed makes it easier to correct and improve security as the code is still fresh in the mind of the developer.
The traditional SSDL implemented in many organisations implies that developers deliver their code to operational people for pushing it to production. Because quality controls in traditional SSDLs are implemented through gateways that enforce isolations of developers from the operational environment, they are disenfranchised from caring or even knowing about security or operational issues.
In this approach operational people and not the developer is operationally responsible for that the code might have security implications.The emphasize is in this case not on making the developer aware of operational consequences of his or her code and of empowering him or her to fix.
Security benefits from software developers that are operationally responsible for that the code might have security implications if they also are empowered and enabled to fix. In traditional software development lifecycles there is an emphasize on doing a risk analysis upfront. But as innovative software projects imply unknown factors that only can be learned by trial and error understanding all of the risk upfront might not be possible because enough information is simply not available at that point.
Security benefits from learning by doing and from continuously harvesting new knowledge from trying out in real life is anticipated solutions work as expected.
Furthermore the requirements to deliver new features of changes in an ever bigger tempo simply does not fit with huge time consuming analysis of a possible future and a manual approach to security testing done at infrequent time slots. And as results from thorough security tests are ready, the developers long have changed the code and might have difficulties in understanding if the findings still apply.
When code is ready there would be no real reason why it should not be available to customers as quickly as possible.
How to improve? Agile as a basis for building secure codeAccording to SANS improvement can be done by “Wiring security into development tools and continuous integration and continuous delivery pipelines. Build feedback loops between builders, operations and defenders. Work together to continuously review and improve how application security is done”.
An agile development team who continuously deliver code to production is a very good starting point for improvement.
Lets first look at agile software development as a basis for building secure code. Agile software development is a group of software development methods in which solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change.
Some has questioned agile teams and their ability to deliver secure software. In a case study by NTNU and Sintef they found that small and medium sized agile software development organisations do not use any particular methodology to achieve security goals even when their software is web-facing and potential targets of attacks. Their study confirmed that even in cases where security is an articulated requirement and where security design is fed as input to the implementation team there is no guarantee that the end result meets the security objectives.
However that many agile teams do not consider security as of now does not imply that agile methodologies gives less opportunity to deliver secure s
