Feeds

App dev security – where are the risks?

Tackling bigger and better idiots

  • alert
  • submit to reddit

Secure remote control for conventional and virtual desktops

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. ®

Choosing a cloud hosting partner with confidence

More from The Register

next story
Download alert: Nearly ALL top 100 Android, iOS paid apps hacked
Attack of the Clones? Yeah, but much, much scarier – report
NSA SOURCE CODE LEAK: Information slurp tools to appear online
Now you can run your own intelligence agency
Microsoft: Your Linux Docker containers are now OURS to command
New tool lets admins wrangle Linux apps from Windows
Soz, web devs: Google snatches its Wallet off the table
Killing off web service in 3 months... but app-happy bonkers are fine
First in line to order a Nexus 6? AT&T has a BRICK for you
Black Screen of Death plagues early Google-mobe batch
Whistling Google: PLEASE! Brussels can only hurt Europe, not us
And Commish is VERY pro-Google. Why should we worry?
prev story

Whitepapers

Seattle children’s accelerates Citrix login times by 500% with cross-tier insight
Seattle Children’s is a leading research hospital with a large and growing Citrix XenDesktop deployment. See how they used ExtraHop to accelerate launch times.
Why CIOs should rethink endpoint data protection in the age of mobility
Assessing trends in data protection, specifically with respect to mobile devices, BYOD, and remote employees.
A strategic approach to identity relationship management
ForgeRock commissioned Forrester to evaluate companies’ IAM practices and requirements when it comes to customer-facing scenarios versus employee-facing ones.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Protecting against web application threats using SSL
SSL encryption can protect server‐to‐server communications, client devices, cloud resources, and other endpoints in order to help prevent the risk of data loss and losing customer trust.