Friday, 4 December 2009

Proposed Pseudo-Code for Hacking Process

It is quite common in Information Systems to use pseudo code to describe a process. I have often thought that the same principle can be applied to the process of hacking an organisation, which may help people understand the process and how to protect themselves. Below is my proposal for this pseduo-code for the hacking process. This is very much a work in progress. I would welcome feedback on it and I will update it as suggestions are made or as I feel it needs revising.

organisation = proposed target
organisation.footprint(value, effort, risk)
profit = value - (effort * risk)
if profit > 0 then
  organisation.enumerate()
  select attack_type
    case DoS
      engage_botnet(myBotnet)
      myBotnet.launchDDoS(organisation)
    case Access
      organisation.gainAccess(myAccount)
      myAccount.Elevate()
      organisation.installBackdoor(myAccount)
      organisation.cleanUP()
  end select
else
  exit
end if

This highlights the fact that we only need enough security to make it not worthwhile attacking, i.e. it will cost the attacker more to compromise our system than they will gain. Who would spend £1m to get £10 worth of information? We don't need (indeed cannot have) absolute security, just enough to protect our system. It also highlights another interesting point. Perhaps we should make our countermeasures public - not the actual implementational details or versions, but the fact that they are in place, e.g. that we have an IDS. Consider blatant versus hidden CCTV cameras. Cameras in plain sight deter most criminals, whereas hidden cameras spy on criminals while they perpetrate their crime.

We want to make the risk of being caught/prosecuted value high, so that hackers require a higher value:effort ratio, which we won't give them. Given two identically protected organisations with the same value, would you attack the one that doesn't monitor activity or the one that does?

Obviously, the above is very vague and doesn't provide methods to complete these tasks, but that is not the point of this post. Backdoors and Trojans are usually relatively easy to install if you have the right level of access to the system, so much of your security is going to hang on stopping a hacker from gaining access. Gaining access to an organisation is usually performed in one of four main ways:
  • Malware
  • Sniffing
  • Direct Attack
  • Social Engineering
There are ways to protect yourself, up to a point. Some of the most critical are:
  • Installing Antivirus/Antispyware
  • Latest OS and Application Patches
  • Enterprise-level firewall, with IDS/IPS, AV, etc.
  • Personal firewalls on all mobile devices
  • Secure, hardened configurations
  • Browser lock-down
  • Encrypted communication (e.g. SSL/TLS, VPN, etc.)
  • User Education!

The last point is often overlooked as a critical security practice. Please feel free to comment.

4 comments:

Anonymous said...

If you could forgive me being a little picky over terminology… You use the term pseudo-code but I think the heart of what you are describing more generally is an algorithm - a series of step to achieve something - the pseudo-code is just one possible form of expressing the underlying algorithm. You could equally have gone with the same 'algorithm' but chosen say a graphical notation to express the process (along the lines of flow chats, UML etc).

I don’t think I’ve seen pseudo-code for a typical defence to mirror the attackbut security processes usually have that sense of being iterative and systematic processes (like ISO27000’s plan-do-check-act model). Expressing the attackers thought process in pseudo-code makes a strong point that attackers can be just as systematic as defenders. I’m sure people still tend think of a criminal as a stereotypical a loner who is a bit haphazard, a bit opportunistic, lucky even. It’s a more chilling (but realistic) take on criminals to realise that they can be systematic, smart and often well resourced organisations.

My second point would be that the perspective provides an important context to the ‘variables’. The pseudo-code is the process from an attackers point of view. They are the agent enacting the process so it is their assessment of value, effort & risk that guides the algorithm. The defenders take on the value, cost, risks can be different.

At a simple level if a thief takes £10 from me then I’m 10 pounds the worse off, but if I’m in a business where my reputation hinges on trust and security then the public knowledge that I had been robbed can cause me considerably more harm than the monetary value lost. That’s the reason it is so hard to get clear statistics or measurements about the extent of financial crimes online. Banks and financial institutions, etc. might not like to lose money to attackers but what they really fear is the impact on future business of people knowing they have vulnerabilities. On that basis they might be prepared to depart from a simple cost-benefit take on security – of course it is hard to put a price on a credible reputation. What I am sure is that attackers have no regard for the intangible damage to a reputation only the gains they make.

Anonymous said...

I'm going to be a bit realistic here! Although trying to create a "thought process" or a flow-chart of an attacker is quite useful to prevent the more "uneducated" attacker to penetrate a system, it comes to a point that a cracker is basically going to use points you have not even imagined they existed to enter your valuable system(s).

What i'm trying to say is that trying to put a hacker in a box is just doing you more harm by costing more to design it but in the end the attacker is the one who will think beyond your "box". I understand where you are coming from and the thing is that most security specialists nowadays follow the same curriculum take the same certifications thus creating a generation of professionals that are simply one step behind those determined enough to penetrate your system. Try to educate yourself in more practical levels than trying to theorise everything. Although an attacker will carefully plan ahead it all takes place in a computer, computers can, fortunately and unfortunately be made to do what you want with them.

Indeed the last point you mention in your security check list is often the one that is most often overlooked by even large corporate companies leaving an otherwise very secure system vulnerable to social engineering.

Now although cyber-crime or "hacking for money" is more prevelant than "hacking for curiosity" both can be as dangerous and lead to information leaks.

What has been talked in various communities as a possible "good plan" is to create systems that will have as little downtime after an attack, create a after-fail system plan not fail-safe one which is impossible to make. It has been a greater trend for companies to spend huge amounts of money to create a virtually impenetrable system only to see there "fortress" crumble to someone who could think a bit more!

my 2cents

P.S. I am obviously not talking about not fully securing your system, I am saying that if you are a target of a dedicated attacker he will eventually gain access :)

Luke Hebbes said...

@Anonymous (2): I agree with you that putting a hacker in a box is dangerous. Perhaps I didn’t make the point clear in the original post – this is not intended for security professionals or pen testers, but to explain things to IT and Computer people with little or no security background. The reason for being one step removed from actual attacks is that they move so fast and security professionals will always be one step behind the hackers. It also avoids the inevitable ridiculous statements such as “Oh well, I use a Mac not Windows so I’m not affected by this.”

You are also right that absolute security is impossible to achieve so we have to take a more pragmatic approach to security. There comes a point when a tiny amount more security costs a lot more money, time, management effort and is much less user-friendly. Wouldn’t it impact the business less if we take the hit and recover quickly and smoothly? Often the answer is yes. It isn’t just a “good plan” to design systems to be highly available and dependable, it is “critical”. Recovery after a breech must be just as much of the planning as the mitigation of the breech in the first place. We all insure our cars, hoping never to call on it, and then try desperately to avoid having any accidents, getting the car stolen or vandalized. However, in the end, a lot of us will end up claiming on the insurance at some point, no matter how careful we are. The same is true of security.

The Training Circle UK said...

Good post. I just stumbled upon your blog and wanted to say that I have really enjoyed reading your blog posts. Any way I’ll be subscribing to your feed and I hope you post again soon.

Post a Comment

Welcome to the RLR UK Blog

This blog is about network and information security issues primarily, but it does stray into other IT related fields, such as web development and anything else that we find interesting.

Tag Cloud

Twitter Updates

    follow me on Twitter

    Purewire Trust