Friday, 3 August 2012

100% Secure

“100% Secure” is a term that you might think had gone out of fashion but strangely there are still plenty of people out there who are willing to make this extraordinarily bold claim about their systems.  In this day and age claiming to be 100% secure on the Internet is a bit like claiming that you’ve built a machine that is 100% efficient to a scientist or an engineer. At the very least it’s going to be met with skepticism and at worst with derision.

Shopping sites seem to be among the worst culprits for making this claim and it’s probably reasonable to assume that this is motivated by a need to reassure the customer. The problem is that no matter how many soothing claims a website may make, it does not provide a guarantee that it is genuine or secure.  Very often the use of SSL (Secure Socket Layer) is the justification as to why they are absolutely secure but SSL does not provide complete security. It simply secures the communication channel between the client and the server with cryptography.  This provides significant protection against man-in-the-middle attacks, a situation in which an attacker has seized control of a routing device between the client and server and can intercept and modify packets of data.  When the data in question is transmitted over an unencrypted channel with no safeguards the attacker is free to intercept sensitive information such as login credentials or they could even manipulate the client’s session to perform unauthorised actions.

While it is very important to protect against this type of thing it is by no means the only threat to a website’s security. There are a whole host of other attacks which are much simpler to perform and that can have a far greater impact. I will not go into any great detail about these but some of the main classes of web attack are.

  • ·         Cross-site scripting
  • ·         Cross-site request forgery
  • ·         SQL injection
  • ·         Authentication bypass
  • ·         Remote code/command execution

Each of these vulnerability classes comes in many different forms and they can be triggered in a wide variety of ways. Each of them has the potential to undermine the security of multiple users, while some have the potential to undermine the security of every single user on the site. Securing communications between the client and server is a moot point if the server suffers from devastating flaws. An example of this might be that the client’s private data is stored in an unencrypted database on the server and this data can be exfiltrated by means of an SQL injection or by the attacker leveraging remote command execution to initiate a database dump.

Just defending against all known technical vulnerabilities is a herculean task, especially on large and complex systems but even if the main system is immune to all known technical problems there are still other ways it can be attacked. The server hosting a website may not have sufficient physical security or someone who occupies a trusted position and has access to the system may not really be all that trustworthy.  Then of course there are any external dependencies the system may have, we need to consider whether the system automatically updates itself or otherwise depends on other systems and if so are they also secure? There is no end of possible attack scenarios and we can even consider more exotic threats, what if someone is willing to take down power supplies to disrupt the system? What if someone tried to launch an armed assault against the data centre in order to get at some juicy data? The problem is that these last two scenarios are possible but they are extremely unlikely.  If the risk of an event is low and the measures required to prevent it are expensive then it is difficult to justify spending time and resources on defending against it.  So let us consider what it would take to make a system fully secure.  Every single scenario will have been taken into account and some quantity of resources will have been expended on reducing the risk of each event to exactly zero. Such a system would be vastly expensive and would most likely have severely degraded usability resulting from all the additional security measures. (Just imagine filling out a CAPTCHA and multiple it by about oh let’s say 100)  It should be apparent that such a system requires an unrealistic amount of resources and would rely on its creators and users to be completely infallible and absolutely trustworthy.  Keeping a system secure is as much a challenge of managing human nature as it is of engineering.

If the system is never going to be totally secure then why spend time and money on security at all? Well the best we can really hope for is to reduce the risk to acceptable levels and to have a disaster recovery plan in place if something does go terribly wrong.  Security is like any other risk and as with any other risk assessments we need to know at least the following.

  • ·         What are the risks?
  • ·         How likely are they to occur?
  • ·         What is the impact if they do occur?
  • ·         How expensive is it to reduce the risk to an acceptable level?

Once we know the answers to these questions we can make an informed choice on the best place to focus on making improvements.  It makes sense to start on items that give the most benefit for the least cost and to keep making more improvements as the resources become available to do them. It would also be wise to periodically revise the list of risks as the world of security and the internet are very dynamic and new threats can emerge overnight.

I believe that 100% security is an ideal that we must strive towards within the constraints of the resources available and without severely impeding the usability of a system. Even though it may be impossible to reach perfection the very act of trying is what keeps a system as secure as it possibly can be. The alternative is to complacently believe that you are always safe while the threat landscape evolves around you; in this case you become the proverbial boiling frog that sits waiting for the inevitable disaster and who really wants to do that?

No comments:

Post a Comment