The old days of development and operations being separate are long gone, and we now have a more powerful, faster and productive way of working: DevOps. DevOps allows more collaboration and communication across multiple departments to achieve greater results. What if we optimize that further and add security?
Going back to 1970 when Winston W. Royce first formally presented the waterfall method in an article, security would fit right at the end of development and testing, as a penetration test. Security at the end means very little breathing space if there were any security vulnerabilities to fix - especially if projects are tight on money/have strict deadlines to meet, which leads (sometimes) to security being missed altogether.
Releasing an unsecured application is not part of best practice but most of all hitting the headlines for a security breach is not what any organization wants! Instead of thinking of security at the end of development, how about considering it in development?
Furthermore, considering it in design. The new EU General Data Protection Regulation (GDPR) is coming into play on the 25th of May 2018, and it is coming in with a big bang including the Privacy by Design legal obligation. Now we must consider security by design as a legal requirement, so we will be seeing a big change in the attitude in protecting customer data to minimize customer data breaches. Why? Fines of €20 million or 4% of annual turnover – depending on which is higher, which is a very large amount.
So, what is security adding in development and operations? DevSecOps. It is all about continuous delivery when it comes to DevOps so automation here is key, having an application installed in the integrated development environment (IDE) that will continuously scan the code and warn developers of insecure code, or maybe a quick security scan when code is imported into the repository to check through which the developer can fix when they get back to coding.
A lot of developers will agree that a tool that shows too many false positives will just be more of a nuisance than help, so spending quite some time picking the right tool and understanding what learning mechanisms they have, to produce fewer false positives as time goes on, will be highly beneficial.
Along with static code tests as described above, using a dynamic application security testing tool will add to the security of the application. It will be doing more of the black hat security testing on the application level. It can also be used on a regular basis in production which will be ongoing security checks on the application.
Talking about security by design, threat modelling can be used at the start, thinking like a hacker and trying to access confidential information on the application. Once vulnerabilities are identified, it gives a scope for developers to cover.
Security in applications is a very big topic, and enabling it in each department and getting teams to collaborate around achieving maximum security will be difficult. The end result is a robust application that will be compliant with new the GDPR law and not create any data breach headlines!
Audrey Budryte is a student at Queen Mary University of London studying a four year Computer Science degree with a Software Engineering focus. She is also a young degree apprentice working at the Testing portfolio of the John Lewis Partnership.