Software flaws are at the root of many security exploits, and year after year we see the same old issues topping the OWASP top-ten, such as SQL injection and cross-site scripting (XSS). Are these really such hard problems to tackle? Or is the message just not getting through to developers?
We spoke with Justin Clarke, director and co-founder of Gotham Digital Science – a firm specialising in secure development lifecycle – and London chapter leader of OWASP. He explains that building secure software is a hard problem, what with tight deadlines and the business screaming at you for new features. However, when you analyse the flaws that have been exploited, you find that many would have been easy to fix – perhaps just taking minutes.
“In the end the easiest way to not have security issues is to not write them into the code in the first place,” he says.
Modern coding frameworks have got better in that they make it harder to accidentally code-in some of the more common flaws, such as cross-site scripting. Indeed, Apple is making just such a claim for its new programming language, Swift. But Clarke feels that more needs to be done with the frameworks and tools that developers are using to make them secure by design.
However, do we also need a change in mindset, to make security part of every decision a coder makes? Clarke explains that some people think security should be regarded as an aspect of software quality. So is the problem the culture in which developers are working, and do we have to promote security as an element of quality?
And, ultimately, who’s responsible for getting developers up to speed on security issues. Clarke says this is not an easy question to answer, but ultimately it’s the business owner who’s responsible if code goes out with flaws – “it’s a business issue if someone exploits it”.
[The OWASP AppSec Europe event takes place on 23-26 June in Cambridge.]
Network and security professionals make constant changes to their systems – an addition or deletion in Active Directory, perhaps, or a new firewall rule. And other these changes are reactive, fulfilling a sudden and urgent need. The problem is, many of us are not documenting these changes, and that’s creating major problems.
Security firm Netwrix recently carried out research which found that 57% of IT professionals make changes to their critical IT systems in an undocumented manner. Either the IT professional doesn’t bother to document it, or plans to do it later and then forgets.
So what danger does this lack of documentation pose?
Michael Fimin, CEO of Netwrix explains that many of the changes are directly security related – eg, changes to policies or access rights – and that not documenting them not only weakens security but can also have implications for compliance. And without visibility into all the changes you’ve made, you can never be sure about the current state of your security, he says.
There are change management systems that attempt to formalise the whole process – but for them to be effective, their use has to be enforced. Auditing systems help address this by logging changes automatically and by providing documentation. They’re not as structured as a change control system, but at least the information they provide is complete.
But if you’re automatically logging everything, how do you tell what’s really important? You need to be able to prioritise, explains Fimin, otherwise there’s the challenge of having to deal with too much data. Still, he argues, it’s important to document everything because you never know what’s going to become important later.