Is your business unwilling to add security features to software?

Gavin Johnson-Lynn -

I recently took part in a meeting of the North-East England chapter of (ISC)2, where security experts from the region used the world café conversational format to discuss a number of topics. I lead a table discussing secure software development and an unwillingness for business to add security features came out as one of the key points to come out of it.

There are many reasons a business wouldn’t want to add security features to software, including:

  • Budget – is there budget to include security features? What happens if the budget is gone by the time you want a penetration test?
  • Business needs – the business goal is to deliver software that the customer wants, surely adding security doesn’t help?
  • Security vs usability – it can be perceived as better for the customer to strongly favour usability over security
  • Consequences – are the consequences and probability of a breach worth the effort to add security features?

A business that knows the importance of security is likely to list security features alongside more functional features on the software backlog.

Consequences

Businesses need to be clear on what the consequences of a security breach can be, before a breach occurs; indeed, having a clear understanding of the impact of a security breach can be a major driver to understanding and including more security.

Equifax is quoted as saying that its breach would “…hurt sales and result in costs of $60 million to $75 million”

A software breach can hurt a business in a number of different ways:

  • Business disruption
  • Fines
  • Loss of reputation
  • Loss of customers

All of this comes down to a loss of money for the business.

What’s the solution?

There isn’t always a solution and there doesn’t always need to be one. If the data and resources involved are identified by the company as very low risk then perhaps putting lots of effort into security isn’t worth the time and money; however, it still takes effort to look at what’s going on to identify what the risks are and that takes some degree of expertise.

GDPR. It gets talked about a lot these days and rightly so, it’s about to change a lot of things.

“Up to €20 million, or 4% annual global turnover – whichever is higher” (GDPR Fines)

That’s a serious potential consequence and is likely to make people put some real thought into handling security properly. It’s hard to tell what impact GDPR will have and how it will cope with a potential avalanche of violations, but it could be a major turning point in software security.

Security needs to be easy, the easier it is the more likely it is to be adopted. What kind of things are we talking about here?

  • Automated testing – how easy is it to tell just how good or bad your software security is?
  • Abundance of skilled staff – is it easy to find staff to build secure software?
  • Secure by default – are tools providing security by default, or relying on skilled users to make them secure?

A basic level of security in software is becoming easier to do, but the threat landscape is becoming broader and deeper, requiring more skills and more awareness to fully comprehend the risks.

Secure software development requires an array of tools, knowledge and experience to succeed. It’s not simple.

The solutions appear to be about punishing when security isn’t good enough in the hope that it will improve things. It’s all stick and no carrot. How could we make it more about the carrot?