Skip to main content

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
  select attack_type
    case DoS
    case Access
  end select
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.


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

  2. 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 :)

  3. @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.

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

Popular Posts

You say it's 'Security Best Practice' - prove it!

Over the last few weeks I have had many conversations and even attended presentations where people talk about 'Security Best Practices' and how we should all follow them. However, 'Best Practice' is just another way of saying 'What everyone else does!' OK, so if everyone else does it and it's the right thing to do, you should be able to prove it. The trouble is that nobody ever measures best practice - why would you? If everyone's doing it, it must be right. Well, I don't agree with this sentiment. Don't get me wrong, many of the so-called best practices are good for most organisations, but blindly following them without thought for your specific business could cause as many problems as you solve. I see best practice like buying an off-the-peg suit - it will fit most people acceptably well if they are a fairly 'normal' size and shape. However, it will never fit as well as a tailored suit and isn't an option for those of us who are o

Trusteer or no trust 'ere...

...that is the question. Well, I've had more of a look into Trusteer's Rapport, and it seems that my fears were justified. There are many security professionals out there who are claiming that this is 'snake oil' - marketing hype for something that isn't possible. Trusteer's Rapport gives security 'guaranteed' even if your machine is infected with malware according to their marketing department. Now any security professional worth his salt will tell you that this is rubbish and you should run a mile from claims like this. Anyway, I will try to address a few questions I raised in my last post about this. Firstly, I was correct in my assumption that Rapport requires a list of the servers that you wish to communicate with; it contacts a secure DNS server, which has a list already in it. This is how it switches from a phishing site to the legitimate site silently in the background. I have yet to fully investigate the security of this DNS, however, as most

Web Hosting Security Policy & Guidelines

I have seen so many websites hosted and developed insecurely that I have often thought I should write a guide of sorts for those wanting to commission a new website. Now I have have actually been asked to develop a web hosting security policy and a set of guidelines to give to project managers for dissemination to developers and hosting providers. So, I thought I would share some of my advice here. Before I do, though, I have to answer why we need this policy in the first place? There are many types of attack on websites, but these can be broadly categorised as follows: Denial of Service (DoS), Defacement and Data Breaches/Information Stealing. Data breaches and defacements hurt businesses' reputations and customer confidence as well as having direct financial impacts. But surely any hosting provider or solution developer will have these standards in place, yes? Well, in my experience the answer is no. It is true that they are mostly common sense and most providers will conform