In a world where cyber criminals are getting smarter every day and the penalties for data breaches could destroy a business, there is no denying that security is a crucial factor when developing software. However, the complexities of threats means it is no longer viable to simply add on a security layer at the end and rely on testing just before the project goes live – this is simply too little, too late. Making security – and the testing of it – an integral part of the development process will ensure that the end result is fit for purpose. So why are so many organisations failing to do just that and is this process easier said than done? asks Stephen Morrow, head of security services, SQS.
First let’s take a look at the consequences businesses face if their software is insecure or vulnerable. The biggest risk is a data breach or cyber-attack. The knock on effects from data loss of this kind are extensive; not only can businesses face a significant fine for the initial breach – which can be as much as £500,000 – they also face additional costs of recovery expenses, productivity losses and the often devastating impact to their reputation and customer good will.
With data volumes rapidly increasing and cyber criminals gaining ever more sophisticated methods and tools, the costs are only set to increase. A report by the US Ponemon institute revealed that while organisations last year spent approximately $46 billion on cybersecurity, the number of security breaches increased 20 per cent and the cost of individual breaches increased 30 percent [1]. It is evident, therefore, that security spending is in the wrong place, typically the focus is on perimeter defences and security infrastructure but since the bad guys have found ways around this, organisations need to evolve to mitigate the new threat landscape with a proactive approach.
So with such costly consequences, why is security still so often tacked on to the end of a project? Most commonly it will be budget and time restrictions holding organisations back from putting it as a priority. However, by taking this approach, there will only ever be time and resource for a hurried penetration test just before a project goes live, with a lack of due diligence resulting in potential vulnerabilities that could be easily exploited by cyber-criminals.
Security must be proactive rather than reactive and needs to be built into the software development life-cycle and continually tested and measured throughout the entire life-cycle. This begins with defining security requirements that are both functional and non-functional, which translates into a design upon which security testers can use their mind set (that is, think like the criminals) and use threat modelling to ensure the right measures are in place to protect against attacks.
Throughout the process the coding needs to be reviewed and analysed, ensuring any issues are completely fixed before moving onto the next stage. Then, during the test phases security testers can start hacking the system to reveal any vulnerabilities or common issues. This means that the final penetration test performed (usually by an independent third party) before the application goes live should be nothing more than a tick in the box, rather than holding the whole project back by revealing previously unfixed and undiscovered security problems.
However, knowing what to do is only the first step. The biggest challenge when it comes to ensuring security is tested at every step of the way is making sure that everyone within an organisation is on board. Business and IT goals need to be aligned and the board needs to understand why security is an important part of the process. Security shouldn’t just sit with the development team – the responsibility for security and testing its effectiveness should be shared amongst the whole organisation, with buy-in from key stakeholders so that they understand its importance and crucially, where their budget is going.
Fortunately there are tools to help organisations start off on the right foot. The Open Software Assurance Maturity Model (OpenSAMM) is an open, independent framework to help organisations formulate and implement a strategy for software security that is tailored to the specific risks facing the organisation – for instance, a government department will have different security requirements to a financial services firm or a franchised business. The resources provided by OpenSAMM will aid in evaluating an organisation’s existing software security practices, building a balanced software security programme in well-defined iterations, demonstrating concrete improvements to a security assurance programme and defining and measuring security-related activities within an organisation.
Starting with security should be the easy option, it should save time and money and most crucially keep your business and customer information secure from relevant threats. But as we have highlighted, getting the whole organisation on board to support IT is going to be the biggest challenge when it comes to ensuring secure software. However, those businesses that do not catch up and change their security mentality could see their IT systems crumble as cyber-criminals take the next step.
