Security Analysis for Start-up/Real Organisations

Don't be afraid

And it's not that frightening. The main reason to sit down and get a handle on your security is to stop worrying about it. Almost all attacks in real-life involve following a single weak seam through an organisation. Not zero-days, not brilliant ruses, no NSA, no black magic. Just twisting one small mistake into another. Take the HBGary hack from a few years ago. HBGary was a high-end security consultancy in contact with both the NSA and Interpol. One of the founders literally wrote the book on infecting Windows machines.

The attackers [Anonymous] began by breaking into the HBGary website which was badly built by a third-party. The CEO's encrypted [technically it is more complicated than that] password for their website was retrieved. As his password as weak, it was easily decrypted. He also used the same weak password for his email. Another employee also used a weak password, which he then re-used to administer the company's internal support server. From the internal support server, the attackers could then steal yet more passwords, which allowed access to the firm's e-mail system. The attackers could now see all the firm's correspondence and impersonate any email user.

And so...

From: Jussi
To: Greg
Subject: Re: need to ssh into rootkit
ok,
it should now accept from anywhere to 47152 as ssh. i am doing
testing so that it works for sure.
your password is changeme123

i am online so just shoot me if you need something.

in europe, but not in finland? :-)

_jussi

And with this, one of the world's most elite security consultancies came to have a critical server with the password 'changeme123'. And this is how most breaches occur. The normal attack is simply finding and following a single overlooked fault-line. (A hacktivist targeting another security firm even wrote a guide.)

Having a large IT budget (whether in terms of time, money or stress) but no clear sense of what is at stake is almost a guarantee that these things will happen. Great weight will have been put on doing something anything. People will feel they have now "invested" in it and that it is "done". And, in practice, the worst problems will still be there.

It is the whole chain of systems, people and process that matters. This is both a daunting challenge [How does losing control of your blog affect the cheque printer?] and an opportunity for easy wins [If our bank account requires phone confirmation for transfers over $50,000 per day, then that's the worst possible loss from a compromised PC.]. Managing security across the entire chain of trust/vulnerability is a balancing act. But with a little preparation, you can tilt those balances far in your favour. As a defender you do need to be lucky all the time, but you also get to choose the terrain.

What are you protecting?

So, where to start? List every asset you are trying to defend. This is more than you think. For example, any web business is going to have site availability as an asset. An asset separate to their site. The site might be perfectly fine, but inaccessible to the public due to a denial-of-service attack. Any software company needs to protect its source code. Every company has business secrets. If you have bank accounts, they go on the list too - it doesn't matter if they are part of your product, if they have money in them and you use online banking, they are at risk.

Now write down all the actors. Actors for our purposes can be both people and organisations. Typically we would represent different roles in an organisation as separate actors, for ex. developers, back-office staff or executives are all separate actors. One person can be several actors and that is fine. Actors in our diagram are mostly representative of groups rather than being specific people. All of your suppliers are actors in your system. If you use GMail, you need to consider that Google can read your email. All your server security can be by-passed by your hosting provider.

What can go wrong?

Now you have the edges for an 'information flow diagram'. This is where we start to introduce actual components like PCs and servers to our model. For our purposes a component might be an email account, a build process, the control panel for your hosting. It is any functionally discrete "thing" that the assets to be protected can be reached through. For example, your website will be a separate component to your web server (and neither is an asset). Your website could be compromised by changing your domain name or by hacking a 3rd-party component included on the site, but neither of those would affect the server at all - this needs to be clear from information flow diagram.

Draw directional lines that show how one component might manipulate another. This exercise will often reveal that the CTO's email is in fact the most critical component in protecting the entire system. Desktop PCs usually also jump out as big overlooked control points. And PCs are often where breaches happen. It does not matter to an attacker if they steal credit card numbers from a server locked up in a data centre or a call centre agent's work laptop.

information flow diagram

Really think about all the separate moving parts in your environment. For example, most modern servers have a remote access cards which allow them to be booted and re-installed remotely. These cards are separate to the server, even having their own network interfaces, and can completely take control over them. A networking switch or modern commercial firewall might have similar remote administration features. (There was an interesting scandal in Greece when Vodafone's phone switches were infiltrated through an call monitoring module they hadn't even bought.)

Hopefully this should already give you a good idea of where your potential issues are. For regular business talking this diagram over might well be the only thinking they need to do before they start looking into specific types of vulnerabilities and remediations. As a start-up (especially in FinTech) you will most likely have more complicated needs and will want to think about this in a more formal way.

Why?

Threat modeling means moving past your assets to look at how they might be compromised and by whom. At the very least this will include: criminals who want your computers for botnets, your own customers, angry ex. employees, industrial competitors, etc. Then be realistic in assessing their abilities. There aren't many evil super-hackers. For example a jilted employee will not be able to write malware, a professional attacker will do, but most likely they won't be able to tamper your internet connection. For the tiny number of organisation who need to worry about national intelligence agencies (or certain countries), well... this blog post is not a good place to start! (But if it makes the exercise more creative, then do throw in the NSA as a Big Bad :-))

So for example...

Attacker Motivation Abilities
Evil ex. employee
  • Embarasse company
  • Steal customer details
  • Influence ex-colleges
  • Retains old passwords
Script Kiddie
  • Brief fame
  • Blackmail company
  • Displacement activity
    • Use simple hacking tools (maybe with a proxy)
    • Get their friends to run DDOS scripts
    • Trick call centre operatives

    So we now have a clear idea of :-

    • What we are protecting
    • From whom
    • On what "terrain"

    Okay, now you can be afraid

    You will notice that this is towards the end of the article. This is because rational concern is good; free-wheeling paranoia is unproductive. At this point, if you are a media agency you will know that you are not bothered about denial-of-service attacks. And if you are a German satellite communications provider you will know you need to worry about the NSA. So the fears with have at this point are realistic ones. So how do we channel these "good fears"? Personally, I like attack trees. They look like this...

    • Get CEOs emails

      • Steal Blackberry
      • Access from control panel

        • Bribe sysadmin
        • Hack sysadmin's computer
      • Guess password

        • ( See Password Guessing tree. )

    List off all the possible attacker goals and use them as roots for your trees. Have the information flow diagram in front of you. Look at the asset that should be at the top of the tree and looks down through all the components to find possible attacks. This is also a point where you can begin to look at checklists and technical security guides to give you ideas. One Windows PC is much like another and you should copy others who've had more time to look at a particular problem.

    Some checklists I like :-

    You will find that a there are significant overlaps in the attack trees for different goals. For example, compromising a sysadmin account will allow an attacker to reach many different goals. Factor these out into "appendix" attack trees and just refer to them in the other trees.

    attack tree

    In a formal threat assessment, you might want to label the leaves with money costs and then trace the path of least cost up to your goals. But usually a couple of attack paths will jump out as being real problems, with the rest looking like too much work to be worthwhile for a realistic attacker. (Remember that the HBGary attack could have been limited to their sales website simply by not re-using passwords.) Only now should we start thinking about doing something.

    Protect the company, not the computer

    Now that we have a list of attack paths to worry about we can look at mitigating them. That might mean installing technical counter-measures on components, removing them from critical paths, etc. Anything that makes the unacceptable attack path go away without introducing a worse problem somewhere else. It doesn't have to be a technical fix like installing anti-virus software. Non-technical fixes are usually better. Business level controls can catch IT failures. The reverse is not true.

    Take the issue of domain name hijacking. Domain names are typically controlled from an account who's password can be reset by email. This makes sense, most businesses are wholesalers, pubs, etc. They typically have minimal security requirements and forget their passwords. So we might :-

    • Enable two-factor authentication. (And put that second-factor in a floor safe.)
    • Segregate the controlling email account to a single laptop.
    • Ask the domain register to put a note on the account asking nothing be done to it without calling the CTO.

    And so on.

    The important goal is not the introduction of security measures but the elimination of risk. We are trying to adjust the information flow so that attackers need to breach a thing AND another thing, rather than OR another thing. And we are trying to identify our control points, the parts of the information flow diagram that connect many important things, so that we can ensure that they are simple and well-managed.

    This way of thinking can give us the perspective to be selective in where and how we use security products, rather than simply trying to buy security by spending a certain sum of money. Remember that even anti-virus software is susceptible to viruses and that a data-loss prevention product can be a single point for spying on your entire network as well as for protecting it. Everything you introduce to your network is another box in your model. Security is a subset of reliability, it tends to be reduced by adding more moving parts.

    We can also consider rationally if using outside suppliers is more or less of a risk. It might seem safer to have your email behind the company firewall, but do you have the resources to keep a mail server secure and can you provide the level of anti-virus protection that GMail (or Office365) do? Conversely, if you run a high security website (say a bank) and embed an active component from a social media service, then the actual security of your website is only as strong as the social media service. If the social media service is compromised your website will go with it. It may even be worthwhile for an attacker to target them simply to get to you.

    As a general rule, physically segregating functions, having close monitoring and other mitigations which remove components from critical paths and/or set upper limits on the damage, are preferable to technical counter-measures which aim to "harden" components. (I've already expressed the opinion elsewhere that it is impossible to make a general purpose office computer safe from a skilled attacker under normal use.)

    Even if you aren't willing to establish multiple office IT networks, it is sensible to at least isolate system admin functions and online banking on dedicated machines. See my article on IT cleanrooms for a proposed isolation scheme.

    Wrapping Up

    In bullet-points :-

    • Compartmentalise everything
    • Try not to store sensitive data to begin with
    • Remember what you are protecting
    • Dot the 'i's and cross the 't's

    Further reading

    So with all those caveats, here are some security band-aids I recommend looking at.

    For the desktop :-

    For the web :-

    For mobile :-

    But remember, if it is not solving a problem you know you have, it is just a toy, not a tool!