In agile environments, the traditional approach to security no longer works and design principles apply instead. Seen as another quality attribute, security becomes relative every step of the way. Only by considering the security and privacy consequences from concept to deployment can you remain in control in a fast changing landscape.
In a secure development lifecycle, everyone needs to understand their part. Product owners should learn how to apply threat modeling to identify and prevent risks and to create evil user stories. Developers should start with defensive programming. Testers should learn how to use security tools. Operations should deploy secure by default platforms and monitor the environments.
Threat modeling is a methodology to identify issues even before the first line of code is written. However, it quickly becomes difficult to apply when a system grows. In the agile world, it is more useful to start thinking in evil user stories. Evil user stories are linked to the normal user stories, but describe something you want to prevent. In order to be able to do so, it's important to learn to think about 'what could possibly go wrong'. Everything you come up with should be written down and be identified as 'acceptable' or 'should be prevented'. Over time the combined evil user stories will become the treat model of your system.
Especially in the world of online applications it's difficult to establish trust, so your applications should distrust input until proven innocent. This approach is called defensive programming or secure coding. Developers should build their applications as if every request is a potential attack. Only by applying this approach on a structural basis you can become resilient to attachs and write safer and better code.
Many hacks and attacks can be automated and many of these attacks can be simulated with tools. These tools are often free to use, so start using them in your own test setup. Nowadays many tools already have the ability to be combined with test suites or can easily be triggered with API's or via the command line. Just by adding some hacking tools in your build server you can identify many vulnerabilities on a continuous basis.
Traditionally patching systems was hard. It was difficult to apply fixes to running systems and often patches were applied in service windows to limit downtime. Hardening systems was also difficult as it involved many changes in the configuration and required many manual actions. Platform automation can help you with these challenges. System hardening is just a matter of creating the right scripts once. Once this configuration is as it should be, it's applied to all systems. Improving things is a matter of changing it in one place and roll it out on all systems. Patching has also become more easy by retrieving the latest versions all the time during instance creation.
Security monitoring traditionally required specialised technology. Nowadays things have become more easily with monitoring solutions like Elasticsearch and Kibana. Even without specifically looking for security events, you can easily identify the weird stuff by filtering out the known intended requests. Everything that is not intended behaviour is something worth investigating.
Xebia Academy
Wibautstraat 200
1091 GS Amsterdam
The Netherlands
E: academy@xebia.com
T: +31 (0)35 538 1921
Xebia Group © 2019. All rights reserved.
Xebia explores and creates new frontiers in IT. We provide innovative products and services and strive to stay one step ahead of our customers’ needs.