New technologies move at incredible speeds which is why building software that is secure should always be a top priority for any organisation. As new software is created, so are more vulnerabilities. As these vulnerabilities are created, attackers stand a better chance at finding and exploiting them for malicious purposes.
A software security initiative (SSI) is key to mitigating these risks. Here, we look at the seven software security myths which are common misconceptions of best practices and explore how SSIs should work.
Myth 1 – Perimeter security can secure your applications
Perimeter security was initially designed to protect internal networks from malicious external users by selectively preventing network traffic from entering and exiting the network.
It has since evolved to include firewalls, security event and information management (SIEM) products and technology for monitoring the operating environment in real time. While perimeter security is a worthy investment, it does nothing to actually secure the software you rely on.
> See also: The three golden rules for software security in the IoT
Due to more advanced threats, we must make sure our data, software and networks are protected by more than just perimeter security measures. The last few years have seen a typical security perimeter dissolve, with an increasing number of organisations and applications taking to the cloud. Perimeter security as an all-powerful solution is indeed a myth; whilst it acts as the first line of defence, it’s not the one true answer to security.
Myth 2 – A tool is all you need for security software
All software projects produce code and tools have played a major part in finding and resolving many defects in this code. But are they key to solving security threats and vulnerabilities?
Black box testing tools were the earliest for testing simple protocols such as HTTP. Scanning a web app for known problems with the black box approach is affordable and appealing, but isn’t feasible for other protocols.
Although more advanced tools allow new rules to be added over time, if a rule has not yet been written, the tool won’t find the problem. When it comes to security, what you don’t know could very likely hurt you.
Tools really only tackle 50% of the problem. A comprehensive approach to security involves holistically combining both code review and architectural analysis.
Myth 3 – Penetration testing solves everything
Penetration testing is the most frequently and commonly applied of all software security practices and conducting it at the end of the software development lifecycle (SDLC) can be a rewarding security activity. However, just like a tool can’t solve the software security problem by itself, neither can penetration testing.
A majority of software security defects and vulnerabilities don’t directly relate to security functionality; rather, they often involve unexpected (albeit intentional) misuse of an application discovered by an attacker.
It’s a simple task to test whether a feature works or not, but it’s much more difficult to show whether a system is secure enough under malicious attack. How many tests do you do before giving up and declaring it ‘secure enough’?
‘Passing’ a software penetration test provides little assurance that an application is secure enough to withstand an attack and most organisations misunderstand this. As a result, penetration testing often leaves organisations with a false sense of security.
Myth 4 – Software security is a cryptography problem
Software security isn’t the same as security software. You can use a crypto library to add a security feature to an application but this isn’t the same as making an application secure. Cryptography can be a useful tool when it comes to securing data but software security needs to be built in from the ground up.
Security is a system property, not a thing – simply adding crypto measures to code is unlikely to make it secure. Additionally, cryptography is incredibly complex to get right. It can’t find or eradicate bugs or flaws but can sometimes temporarily obscure them, making life more difficult for debuggers and architects. And even crypto falls prey to penetration testing from time to time.
Software security is about integrating security practices into the way you build software, not simply integrating security features into your code. There is no single fix that guarantees security. Achieving the most secure software requires carefully administered and strategic step-by-step measures throughout the SDLC.
Myth 5 – It’s all about finding bugs in your code
Implementation bugs in code account for at least half of the overall software security problem; fixing and finding those bugs is an essential SSI practice. Sadly, it’s very common for firms to find issues without taking any measures to fix them. Part of the problem is that technology developed to find bugs often lacks remediation recommendations for fixing these issues.
Remember, bugs are only half of the equation. Make sure to also focus your attention on the flaws occurring at the design level.
Myth 6 – Security should be solved by developers
Who should ‘do’ software security? Security people? Compliance people? Developers? All of them? None of them? Sadly, solving software security is not as easy as picking only one group of people to hang the problem on. Ultimately, it should be coordinated by a central software security group (SSG). Creating a SSG should be the first step when your organisation is preparing to tackle software security.
There are a few key things to consider when forming a SSG: what kinds of people should join? How big should the group be? How do you even organise it in the first place? Ideally you need a mix of software people who understand development, security people with strong architectural knowledge and people who can interact with the business.
Myth 7 – Only high-risk applications need to be secured
The seventh and last myth of software security is about scale. Today’s application portfolios are often large with thousands of apps, so the aim is to secure the overall attack surface.
No matter whether you’re working on a small project or huge corporate application strategy, the key to reasonable risk management is to identify and track risks over time as software projects unfold.
> See also: Why privacy software is the next big challenge for coders
Risk management is the mature way to embrace software security due to the fact it’s a careful balance between security and business functionality. Too much security can ruin a business proposition by bogging it down.
Conversely, not enough security can lead to unacceptable levels of risk. A successful risk management programme should be a combination of ensuring that no code is left unprotected, whilst also allocating and managing security controls between high, medium and low risk assets – the key is to ensure the entire software portfolio is covered.
There is no silver bullet for securing software. The reality is that software security involves a multi-dimensional approach over an organisation’s entire application portfolio with security built in from the ground up.
Sourced from Gary McGraw, CTO, Cigital
