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 today’s threats means it is no longer viable to simply add on a security layer at the end of development 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?
Ignore security at your peril
First, let’s take a look at the consequences businesses face if their software is insecure or vulnerable. The biggest risk is of course a data breach or cyber-attack. The 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 – but they also might face additional costs of recovery expenses, productivity losses, and the often devastating impact to their reputation and customer good will.
Furthermore, with data volumes rapidly increasing and cyber criminals gaining ever more sophisticated methods and tools, these costs are unfortunately set to only increase. A report by the Ponemon Institute revealed that while organisations last year spent approximately $46 billion on cybersecurity, the number of security breaches increased 20 percent, 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.
Free eBook: Modern Retail Security Risk – Get your copy now.
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 security as a priority. However, if they stick to their current routine, there will only ever be time and resources for a hurried penetration test just before a project goes live, a lack of due diligence which could leave potential vulnerabilities open to the exploits of cybercriminals.
Taking the right steps
Security must be proactive rather than reactive and needs to be built into the software development lifecycle and continually tested and measured throughout. This begins with defining security requirements that are both functional and non-functional, which translates into a design upon which security testers can “think like the criminals” and use threat modelling to ensure that 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 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.
[1] “Cost of Cyber Crime Study 2013,” Ponemon.
By Stephen Morrow, Head of Security Services, SQS
About SQS
The SQS Group (SQS) is the world’s leading specialist in software quality. SQS’ position and expertise as the market leader are the result of over 30 years of successful consultancy. The company’s competitive edge stems mainly from its PractiQ methodology, which is based on many years of project experience and specialist knowledge across a wide range of industries. With over 7,000 completed projects, SQS has a strong customer base, including half of the DAX-30, almost a third of the STOXX-50 and 20 FTSE-100 companies. Our customers include Allianz, Beazley, BP, Centrica, Commerzbank, Daimler, Deutsche Post, Generali, JP Morgan, Meteor, Reuters, UBS and Volkswagen.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.