Human factors researchers have taken interest in cyber security. This is good, because we need to think about most attacks in terms of both technology and psychology on both sides of the fence. Phishing emails is the most common initial attack strategy used in targeted attacks. It is therefore important to make your people able to avoid such deception. 

 

 
A recent paper in the August issue of “Human Factors” by Proctor and Chen discusses decision making in detection of phishing. A key factor found by researchers is that a mismatch between cues in a phishing email and the expectations the recipients have is crucial to detecting a phishing attempt. Such cues are typically technology related such as strange URL’s, errors in corporate identity, slight misuse of terminology. It may this be questioned if awareness training by itself is an effective mitigation element – people need to know their domains well too, as well as what to expect of URL’s and technology solutions from emails and web sites. 

People frequently (heh, heh) define risk as the product of consequences and probabilities of uncertain or stochastic events:

RISK = CONSEQUENCE x PROBABILITY

This has led to a range of risk metrics and ways to compare risk with acceptance criteria. For technical safety risk, there is typically an acceptable frequency defined per consequence category. In a risk analysis, catastrophic events may for example be acceptable with a frequency no higher than one event per one million years. Recently, cyber security risk assessments have become more common also for operators of technical systems, such as waste water treatment plants, intelligent homes or oil and gas production rigs. Obviously, cyber threats are real and intruders can hit you just as hard as a random hardware failure – such as the steel mill in Germany that was hit by an advanced cyber attack originating on an external network. Asset owners have slowly come to realize this – and some of them are trying to use their established risk management frameworks also for cyber threats – only to discover that is really hard to do that. Why is this not a good approach?

Consider the following event scenario: intruder manages to steer your update call to a rogue patch server by a fake internal DNS server, pushing a corrupt Windows patch to your system, thereby gaining admin access to your engineering workstations… how do you assess the frequency of this scenario? Once every 1 million years? Weekly? Obviously, applying the concept of “frequency” as a measure of probability is not the best of ideas in this domain. This has led many people to think “probabilities cannot be used for cyber risks”. This again begs the question – if you do not know if a scenario is likely or extremely unlikely to occur – how do you decide how to allocate your resources when designing counter measures?

A more reasonable concept is maybe to consider how “credible” a scenario is – rather than a frequency of occurrence. This is also how academics tend to look at the topic; we can rank threat scenarios according to how credible they are. An interesting thing that separates risks related to targeted cyber attacks from typical technical risk analysis is that the credibility (or probability) of an attack taking place is not independent of the consequence of this event; the reason the attack occurs is that somebody wants to hurt you. They may be more motivated if the consequences are worse for you! Things to consider when deciding if an attack or a threat is credible are:

• Who is the attacker?
• What is the motivation of the attacker?
• Does the attacker have the necessary resources (money, people, technical equipment, etc)?
• Does the attacker have a positive cost-benefit relationship (as seen from the bad guy’s point of view)?
• Does the attacker have the necessary skills or access to the necessary skills to perform the attack?

Armed with this, you should be able to form a reasonably well informed estimate of the probability – or credibility – of an identified attack such as the one above.

I will be taking more about this at the next ESREL conference, together with colleagues from LR! Maybe I’ll see you in Zürich in September?

The source of bad security in an IT system is software. Vulnerabilities exist primarily because of two things:

• design flaws
• Implementation errors – that is, programming mistakes

The tools we have for fighting such vulnerabilities all belong in the “quality assurance” box. However, no matter how good we are at coding and all that comes with it, software will always ship with hidden bugs. Whenever such a bug is discovered and it is a security vulnerability, it is only a question of time before exploit code becomes available. The software vendor rushes to stuff the hole and push a patch to the users. This helps only if users actually update their systems. 

  
The average time from a patch is released until it is installed in businesses is 6 months. That’s like not changing locks before half a year after known thieves got away with your front door key. 

SCADA security has lately received lots of attention, both in mainstream media and within the security community. There are good reasons for this, as an increasing number of manufacturing and energy companies are seeing information security threats becoming more important. SANS recently issued a whitepaper on industrial control systems and security based on a survey among professionals on all continents. The whitepaper contains many interesting results from the survey. These are three of the most interesting findings:

• 15% of respondents who had identified security breaches found that current contractors, consultants or suppliers were responsible for the breach
• Only 35% of respondents actively include security requirements in their purchasing process
• The number of breaches in industrial control systems seem to be increasing (9% of respondents had identified such breaches in the 2014 survey vs. 17% in the 2015 survey)

That external parties with legitimate access to the SCADA networks are sources in many actual breaches is not very surprising. These parties are normally outside the asset owner’s management control, and they may have very different policies, awareness and protections available at their end. One notable example from a while back where this was the case in a much publicized data breach was the Target fraud in 2014. In that case, the attack vector came via a phishing e-mail sent to representatives for one of Target’s HVAC vendors. The vendor connected to Target’s IT network over a VPN tunnel, unknowingly transporting the malware to the network. The advanced attack managed to siphon away credit card data from millions of customers, uploading it to an FTP server located in Russia. Media has described this attack in detail and from many angles and it is an interesting case study on advanced persistent threats.

This is obviously a cause of concern; how do you protect yourself against attack vectors using your vendors as point of entry? Of course, managing credentials and only giving access to systems the vendor should have access to is a good starting point. But what can you do to influence whaty they do on “the other side” of the contract interface?

First of all – security awareness training should not only be for engineers and operators. The same type of awareness training and understanding of the business risk related to cyber attacks should be provided to your purchasers. From reliability engineering we have long seen that obtaining items that comply with requirements can be challenging; if the requirements are not even articulated, no compliance can be expected. Including security requirements in purchasing and contracts should be an important priority. It is probably a good idea to include this in your company’s security policy.

The next obvious question is maybe “what kind of requirements should I put forward to the vendor”? This depends on your situation and the risk to your assets, but it should include both technology requirements, after-sales updating and service requirements, security practices, and awareness requirements for companies providing services. If your HVAC vendor has low security awareness, it is more likely that he or she will fall for a phishing attempt – putting your control system assets at risk. Due diligence should thus include cyber security requirements; it is really no different from other quality and risk management controls that we normally integrate into our purchasing processes.

Anyone following current news can see that cyber security is an increasing problem for society, from private individuals to government institutions to small and large corporations. Traditional defense of information assets has followed a simplistic perimeter defense sort of thinking, with an incident response team in addition responsible for finding and fixing problems after they have occurred. Modern thinking in security emerging over the last decade has largely left this approach to security because it is very inefficient for protecting our information assets. The current term used for a more holistic view on security management is often referred to as “cyber intelligence”, such as this article at Darkreading.com. Modern thinking around this has emerged by combining developments in software security, criminology, military counter-insurgency tactics and risk management. This change was summed up nicely at the last RSA security summit with one sentence;

There is no perimeter.

The meaning of this is that setting up a defense consisting of firewalls and anti-virus protection is a good thing to do – but by no means is it a solution to all problems; even with these kind of technologies present, breaches are inevitable. Still, many organizations still follow the whack-a-mole-thinking:

• Invest in antivirus and firewall tools
• Buy an intrusion detection system
• If a breach is discovered, disconnect the computer from the network and re-image it to cleanse

There are many reasons why this does not work. Here are three of them; viruses today often mutate from on infection to the next, making signature based AV more or less useless for advanced malware, and most attacks live on the network for extended time before delivering a payload, basically invisible from both users and automated network tools for intrusion detection. Finally, there are always people with legitimate access to the information assets who can be influenced to initiate an attack – knowingly or not (typically this is referred to as social engineering). Basically – you don’t know what hits you before it’s too late.

The worst thing is probably that there is no direct cure. The good news is that you can make your systems much harder targets through good risk management and defense strategies that can help you cope with the threat in a much better way. Following basic risk management thinking can get you a long way by identifying potential weaknesses, threats and vulnerabilities in all parts of your information system lifecycle is the starting point. This means even during development (if it is your software/hardware) or procurement – you need to assess the dangers and find mitigation plans. A mitigation plan should not be simply reactive (whack-the-mole) but rather proactive, such as “how can we minimize the risk such that we think it is acceptable taking both probabilities and consequences into account”? In order to have an informed opinion on this, you need to determine not only what the potential impact of an attack could be, but also the credibility of such an attack. In order to do that, you need to review who the attackers are, how is the outside world affecting the situation, what are the attackers motivations, what are their capabilities, is there a cost-benefit trade-off, and so on. It is from this view the term “cyber intelligence” comes. Having such information at hand, together with a lifecycle oriented mitigation plan, puts you in place to build a resilient organization that is not played out on the sideline easily by the bad guys.