Organisations and software developers strive to build new solutions that make use of the latest and greatest technology trends, such as cloud computing, mobile computing and big data – and, very often, security is an after thought in the software development lifecycle.
Furthermore, while these technologies are exciting and offer end users new features, they also expand the attack surface of a system. Attackers look at the new features and technologies as potential areas of weakness. New additions and changes to a product may also introduce new vulnerabilities to be exploited.

At the same time, developers are doing their best to satisfy the business requirements, which usually does not include a specific focus on security. On top of that, security will typically only be tested at the end of the development process in the form of a penetration test before the application goes live.
But at this stage, as deadlines are fast-approaching, budgets are running out, and expectations are fast rising, the effort to remediate vulnerabilities combined with the pressures that teams are under to ship products means there’s always a very real risk that vulnerabilities will make it to production.
Security – first, last and every stage inbetween
In the software development community, there is (or, at least, there has been) a general tendency to overlook security and to take it for granted – perhaps due to the utilisation of certain technologies that are considered more secure out-of-the-box solutions.
Even if these technologies are secure, this does not necessarily mean that a system will still be secure after a new technology is integrated.
Consequently, early phases of the development lifecycle, such as analysis or design, where the requirements are gathered and the architectural components and technologies are chosen, may introduce security flaws.
When security is not in place during those phases, these issues are not discovered until the very end (if they are discovered at all). It becomes apparent that the integration of security in every phase of the software development lifecycle is vital. Even if this creates an initial overhead, it enables early detection and mitigation of potential vulnerabilities that will subsequently reduce costs overall.
In our experience, and in order to have an effective and secure software development lifecycle, it is fundamental to give developers a deeper understanding of security and put them directly in control of the security of the software they write.
Checklists and documents such as the OWASP Secure Coding Practices Guide and the OWASP Application Security Verification Standard give developers a valid starting point and a framework to work within.
However, these checklists and documents, while providing useful guidance, are unlikely to be enough, on their own, to change developers’ appreciation of how and why the approach and recommendations they suggest would make their applications more secure.
An effective method to ensure that those checklists and security frameworks are fully understood, though, is by exposing developers to security from an attacker’s point of view. More specifically, instead of just training them about secure coding practices, they should be guided through the discovery and exploitation of software vulnerabilities, as if they were the attackers.
Exploiting a Cross-Site Scripting vulnerability to steal session cookies, keylog a user, or exploiting an SQL injection to retrieve credit card details from a database is an interesting and challenging process that truly engages developers in a memorable way.
After this understanding has been gained, developers can then be introduced to tools such as static-code analysis and vulnerability scanners that they can integrate into their development and testing processes. Another benefit of truly embracing an attackers’ mindset is that this enables developers to start viewing their multi-tier architecture as a large attack surface, whose components they learn to identify and scrutinise for potential vulnerabilities.
Last, but not least, this helps bridge the gap between the developers’ community and the security community so that we can interact and collaborate more efficiently towards the common goal of reliable and secure applications. This is perfectly expressed and condensed in the “Rugged Manifesto” put forward by the Rugged Software Developers movement.
Putting the developers in the spotlight of this process, and helping them change their mindset, is an integral part of proactively working towards a more secure development lifecycle. Developers are given a whole new perspective and the opportunity to acknowledge the importance and benefits of security policies and tools.
Additionally, developers are able to satisfy the business requirements in a more secure manner. Even though this does not substitute the need for security experts, it signals the start of secure development and significantly reduces the costs imposed by the very late detection of security flaws and vulnerabilities.
Filippos Raditsas is a security consultant at MWR InfoSecurity. He can be contacted via the MWR InfoSecurity website. This is the last in a series of contributed articles from MWR InfoSecurity experts. See also: 
How to stop attackers getting a toehold on the corporate network; and, Defence in depth: how a layered approach to security can inhibit cyber attackers

Leave a Reply