Can Cyber Protection be Straight-Forward? - Part 1

May 12, 2017

 

In the wake of the recent WCry Ransomware attacks on the NHS I have to ask whether I am missing something; or has the cyber security world disappeared up the backside of complication?

 

Let me ask another question? Is it possible nowadays to adequately protect a system (or network of systems) by reducing the attack possibilities to a level where hackers are more than likely to go look elsewhere?


In short, can a system be compromised if an attacker;


A. Cannot get their executable code onto it and run it? 

 

and;


B. Cannot subvert or misuse any existing/resident executable code?

 

I hold that attackers will have a hard time compromising systems if they are prevented from doing both of the above points.

 

The situation is complicated slightly when any system which they could execute code from might have access to a target system but actually this is still a form of point B above, where the code they are subverting is still in the target system; it is misused because it trusts the source requests.

 

So, if I am correct, then what we have to do is implement controls to address these two attack methods.

 

Action A: No New Binaries Please?

 

We need a system (some sort of kernel driver) which uses the existing core Operating System (OS) function that maintains a list of binaries on its disk and which stops the introduction and running of any newly introduced binaries.

 

Such a solution would require the verification of security for any new binaries you legitimately wanted to introduce and that these could be added by disabling the solution temporarily.

 

It would also require implementation of suggestions in Action B below so that existing or newly introduced binaries could be trusted.

 

Such an idea is neither mine, nor new. The Royal Holloway ISG, University of London and Abatis have worked on such a project and created the Hard Disk Firewall (HDF). 

 

There are also other ways to achieve what I have described using whitelisting - Bit9 as an example, and integrity checking, an example being TripWire.

 

Action B - Prevent Subversion of Existing Binaries

 

We need to ensure that attackers cannot misuse our existing binaries.

Of course, this is not an easy task. 

 

When I refer to binaries I mean not only those provided with the raft of applications installed on a system but also all the executable code contained within an Operating System and within other core systems such as Web Servers, Networking Servers (DHCP, DNS), Security Systems such as Firewalls and Databases e.g. Database Management Systems (DBMS). 

 

Here are some ways of reducing the attack surface:

  • Ensure all patches (not just security) are installed

  • Install optimised/minimum distributions only

  • Remove command line functionality from all apps

  • Set permissions properly on all executables

  • Compartmentalise/segment systems both internally and from a network point of view; using virtualisation and design approaches using Docker. 

  • Disable all functions and features in OSs, DBMS, Web Servers, Networking and Security systems and of course, general and specific Applications.

  • Restrict the use of privileged accounts and restrict/reduce/remove reliance on generic, privileged accounts in areas such as app connections to databases.

  • Set up internal interface rules on firewalls which apply to internally initiated (outbound) connections. Don't just trust internal hosts.

Bit of a rant!

 

You might notice that, apart from Firewalls, I haven't referred much to a need for the plethora of security solutions that are regularly pushed to battle-worn CISOs, CIOs and IT Directors.  It's because when it comes to protecting against unauthorised access/hacking, it may be that such solutions are not really needed.

 

I find that many vendors seem almost to relish the current bleak situation of organisations being highly vulnerable as it satisfies their marketing aims to evangelise fear, uncertainty and doubt; and sell more relatively unnecessary software as a result. 

 

I also find that many CISOs with whom I speak and some of which I am honored to call friends are a bit fed up with this constant layering of IT security products which are mostly focused on telling you that you have been, or are currently, being breached rather than stopping you from being breached in the first place.

 

The plain fact is that most corporate executives consider that their organisations are not in the business of cyber defence. IT security vendors seem to have forgotten that their clients just want to get on with their business, doing what they do well. They simply don't want to employ teams of cyber geeks constantly monitoring their networks because they cannot adequately prevent attacks.

 

Nonetheless, clearly companies do want to protect their critical assets, which are increasingly in the form of data. A happy medium therefore needs to be found.

 

A Rallying Call

 

For me, it would seem far better for those responsible for protecting their organisations from the cyber threat to spend their hard earned budget on the two action areas above. Of course there are plenty of products to help automate these actions but let's try and not be defeatist and on the back foot against hackers. 

 

Instead of accepting that compromise is likely and spending increasing amounts on early warning software, let's take the ground back from the hackers.

 

This suggestion is by no means meant as a panacea defence for the Infosec threat. There are still many other important security issues to address; the insider threat, denial of service etc. 

 

I only offer perhaps a clarification of how we can all reduce the attack surface and make it harder for hackers to compromise our systems. Just like burglars, there will always be softer targets for them to breach. But that's somebody else's problem right?

 

Hope this helps!

Please reload

Archive
Please reload

Search by Tags
Please reload