This article is more than 1 year old

App dev security – where are the risks?

Tackling bigger and better idiots

Thanks for some great comments from the article about making applications more secure. One of my favourites was, “It's all very well trying to make your software idiot proof, but the problem is that the world keeps creating bigger and better idiots.” How true this often appears.

Meanwhile, from secure applications we can turn our attention to the development process itself. Much as we would like them to be otherwise, developers themselves are only human – and fallible. When we conducted some research into security around development and test last year, we identified four areas of risk:

  • Sourcing – i.e. who is involved in the development process
  • Geography – where people are, and how they are organised
  • Environment – what tools and systems are in place for developers
  • Data – what information is being used or managed as part of development/test

Of course these areas are inter-related. Few organisations these days have the benefit of an entirely in-house development team these days, and we have all seen the issue of having a key developer move on, potentially subcontracted in as a consultant, from some far-flung place. Meanwhile, data and environment are tightly knit: in our research we were surprised to see how many organisations actually run test applications on the same systems as the live environment, for example. While this may sound like a recipe for disaster there may be no choice, if costs to replicate an environment are prohibitive.

CIA

Risks can be divided into three types, based around the old stalwart confidentiality-integrity-availability acronym.

For availability, it’s clear that here we are thinking wider than security – in the above example, a potential outcome is that the test system crashes, pulling the live system down with it.

Integrity and confidentiality are just as much of a concern for protecting information itself, as for the possible compliance damage (and legal exposure) that may be caused if data is lost or damaged. And of course, source code represents a company’s IP, and needs its own protection.

Join us on 21 July, as we will be bottoming out some more of these risks, along with how to run a more secure development shop, in our upcoming Regcast. In the meantime if you have any experiences or best practices you’d like to share, do let us know. ®

More about

TIP US OFF

Send us news


Other stories you might like