A few days ago, I asked my followers on Twitter if they used the two-factor authentication on Twitter, or if they knew what two-factor authentication was in the first place. The result was that almost no one is using this. Most accounts that are hacked, are hacked because users are stupid and use terrible passwords, and they use the same passwords on every site where they have an account. This means that whenever some news site with terrible security is hacked, the hacker has access to more or less all these users’ accounts, including e-mail, social media and their favorite online stockbroker… This is admittedly bad.

Two-factor authentication comes to the rescue – using this, you cannot log in simply because you have the password and the username. You also need to have some third-party security token, like an app on your phone, a confirmation SMS sent to you, or a code generator device. If the hacker does not have access to this third-party token, he or she cannot take over your account. That is, at least, the design intent.

So, how can a hacker bypass the need for a third-party security token, or getting your leaked password in the first place? They can use a good old phishing attack. Set up a web page that looks like the one you want to log in to, trick you to go to the fake site and enter the login data, and then use these to access the real page. This process is illustrated below.

First, you need to trick the user to visit your fake login page, typically by sending some form of e-mail asking to log in and update something. The user submits username and password in the fake view, that you transfer to the real view in order to generate the third-party confirmation code. The real page, believing it is communicating directly with the legitimate user, sends the confirmation code to the user’s call phone. The user then submits this through your fake login view. Then you, as the hacker, will have access to the confirmation code, and you can take over the account. Depending on the type of site you can execute actions, or at least gain insight to the user’s personal data. For very poorly secured financial applications you can even steal the user’s money.

Of course, this is much more complicated to get to work than simply stealing a username and password, or brute-forcing a weak password, so 2-factor authentication makes a lot of sense. But like all barriers you put in place in risk management, it is not a magic pill solving all headaches. You still need to keep your guard up – don’t fall for phishing scams, don’t use the same password on multiple sites, use strong passwords and keep up to date on security features on the sites you are using and that are critical to you. Sites like Facebook and Google’s products can send you an e-mail or text you whenever there is a new login, with location and type of computer/browser. This is a very good extra layer of security.

To sum it up: use two-factor authentication, but also don’t forget to follow other common good security practices.

During the American election campaigns in 2016 fake news was the new big thing, with Russia being accused of orchestrating an intelligence campaign to influence the outcome of the presidential election. Regardless of what Russia did or did not do, spreading the message efficiently requires both that traditional media pick it up to grant it credibility, and that people share it on social media platforms to get as much coverage as possible. Machine learning can play many roles in this, and we will look at an obvious use case, which is pretty much the same way recommendations work on Netflix or Amazon – by use of feature-based labelling.

Any “news” article will have several features. Examples of features are:

• Language style (using a readability metric)
• Length of article (word count)
• Use of celebrities (none, light, medium, heavy)
• Visual intensity (none, light, medium, heavy)
• Shock factor (none, light, medium, heavy)

Let us say we consider a news article successful if it receives more than 100k shares on Facebook, or if it is quoted on CNN. So, our news articles can be SUCCESSFUL or NOT SUCCESSFUL depending on these criteria.

One simple but often efficient way we can use machine learning to understand what makes an article successful is to use existing data to train a decision surface. Say we have a collection of 200 news articles, and that we can check whether they are successful or not (they are labelled). This is our training set. Based on that, we can use statistics to find out which features will help us predict which label to apply to which data point. If we boil this down to two factors (language style and word count), we can create a scatter plot of these articles. By analyzing our set of training data, we seek to learn how we can exploit the factors to make our fake news spread. We have plotted our training data in a scatter plot to inspect it visually.

What we learn from simply looking at the plot is that the article should be fairly short, and intermediately difficult in readability (seems to be somewhere between 60 and 80 on the Flesch index, corresponding to articles that can be read by high school graduates).

Using a classification algorithm like the Naïve Bayesian classification algorithm, we can generate a decision surface based on our data.

Everything that falls into the red region will be predicted as successful. Giving up on the ability to plot the features in a single scatter plot, we can feed the algorithm with our full feature set, allowing it to figure out more factors we should care about when creating our fake news campaign.

This shows that the same methods used to drive recommendation engines, can also be used to learn how to best influence people – useful both in marketing, and in trying to “rig elections”. By the way, this simple labeling of data using classifiers like above is one arm of machine learning, known as supervised learning. The data set used in this post was randomly generated – so it didn’t really teach you how to create efficient fake news articles – but it did show you how you can find out.

Information security focuses on three aspects of safeguarding data in our systems (CIA):

• Confidentiality: data should only be visible to those who have been granted access to them
• Integrity: data should not be altered by people not authorized to do so
• Availability: data should be available to everyone and all systems that need them, when the data is needed

In traditional IT, security thinking has been dominated by confidentiality. This is in most cases justified; the data itself is the valuable asset (think credit card information, medical journals, police records, accounting, business plans, etc.). In control systems, the real value is governed by the process control by the control system assets, and availability is extremely import, as well as integrity. Confidentiality on the other side may be less important.

Many organizations plan their security management based on traditional IT priorities, and apply these priorities also in the control system domain. This way, there may be a misalignment between the real priorities of the organization, and where the money and resources is spent.

Dr. Eric Cole, a renowned security expert, recommends asking senior management for these priorities, and then comparing with actual security expenditure from the last year – if there is misalignment between “what’s important” and “what’s done” it is time to take action. Have your thought through if your organization is spending the money where they are most needed to safeguard what is truly critical?

This week I have been present at SANS ICS Security Amsterdam, taking one of their courses on security for industrial control systems. This has been a fantastic opportunity to learn new things, reinforce known concepts at a deeper level, and to network and meet with a large range of people with interests in this field. I’ve been surprised to see people from law enforcement, national security, industry representatives, consultants and vendors coming together at one event. Information security has been a lot in the news lately, and is seen as a big part of the risk picture in almost every region and every industry.

Two things in particular have been very interesting to see when it comes to the stuff presented by the SANS course instructors:

1. Security researchers continue to find basic vulnerabilities in new product lines from major vendors (the big companies we’ve all heard about, I’m not going to shame anyone)
2. A lot of control systems are still facing the internet, are directly accessible with no or very weak security, and attacks are prevalent as found in honeypot research experiments

Basically, this confirms the notion that “the situation is bad and we need to do something about it”. People said this after Stuxnet, and they are still saying it. My impression from working with various clients is that industry is aware of the risks that exist “out there” but they are in varying degree doing something to control that risk. Too many still believe that “we will never be compromised as long as we have a firewall”. Relating to this, one might ask, what are the “basic vulnerabilities” and how do we work around that?

Many control system components today run on commodity OS’s, or are connected to servers running MS Windows or Linux, e.g. used to display HMI’s. These HMI’s are in many modern systems developed as web apps (running on local servers) for portability, ease of access, etc. This means that many of the vulnerabilities found in regular IT and on the web also apply to control systems. However, these risks are worse in the control system world because these systems need to run all the time and can therefore often not be patched, and should someone break in, they could cause real physical damage (think crashing of cars, blowing up an oil rig or destroying a melting furnace). Some of the top vulnerabilities we are exposed to are the following: buffer overflows (yes, still, lots of stuff running on old systems), SQL injection vulnerabilities and cross-site scripting vulnerabilities (web interfaces…). So, if we cannot patch, what can we do about this?

First of all, perform a risk and vulnerability assessment, taking both possible scenarios and credibility of scenarios into account. Make sure to establish a good baseline security policy and use this for managing these issues – there is lots of guidance available, and often sector specific. If you cannot patch, focus on what you can do; ensure everyone involved in purchasing, maintaining, producing and using control systems are aware of the risks and what types of behaviors are good, and what types are bad. This means that security awareness must be built into the organizational culture.

On the technical side, maybe especially with lots of legacy systems running, make sure the network architecture is reasonable and safe – avoid having critical assets directly facing the internet (do a Shodan search and you will find that lots of asset owners are not following good practice here). The architecture must weight risks and business needs – a full lockdown may be the safest way to go, but it may also stop core business functions from working.

Further, should a breach occur, make sure you have the organizational and technical capabilities to deal with that. Plan and train on incident response – and remember you are not alone. Get help from vendors both in managing the assets during normal operations, and during a crisis situation. Including incident response in service agreements may thus be a good idea.

This was a quick summary of topics we’ve looked at during training, and discussed over beers in Amsterdam. The training by SANS has been excellent, and I’m looking forward to bringing reinforced and new insights back to the office on Monday.

Yesterday my LR colleague Anders presented our work on aggressor profiling for use in security analysis at the European risk and reliability conference in Zürich. The approach attracted a lot of interest, also from people not working with security. One of the big challenges in integrating security assessments into existing risk management framework is how to work with the notion of probability or likelihood when considering infosec risks. Basically – we don’t know how to quality the probability of a given scenario in a reasonable manner – so how can we then risk assess it and treat it in a rational manner?

The approach presented looks exactly at this. A typical risk management process would involve risk identification, analysis and evaluation of consequences and likelihoods, planning of mitigation and follow-up/stakeholder involvement. We have found working with clients that people find identifying potential consequences of different scenarios much easier than identifying the credibility of scenarios. The approach to assessing credibilities is centered around two actors:

1. Who is the victim of the crime?
2. Who is the aggressor?

Given a certain victim with its financial standing, relationships to other organizations, geopolitical factors, etc., we can form an opinion about who would have any motivation to try and attack the asset. Possible categories of such attackers may be

• Script kiddies
• Hacktivists
• Other corporations
• Nation states
• Terrorists
• Rogue internals

Each of these stereotypes would have different traits and triggers shaping the credibility of an attack from them. This is related to motivation or intent, their resources and stamina, their skill sets and the cost-benefit ratio as seen from the bad guy perspective. Giving scores to these different traits and triggers can help establish the opinion of how credible a threat is.

An interesting effect in security is that the likelihood of a threat scenario is not necessarily decoupled from the consequence of the scenario; the motivation of the perpetrator may be reinforced by the potential gains of great damage. This should be kept in mind during considerations of intent and cost-benefit.

Forming structured opinions about this, allows us to sort threat scenarios not only according to consequences, but also according to credibility. That fits into standard risk management framworks. Somewhat simplified we can make a matrix to sort the different threat scenarios into “acceptable”, “should be looked at” and “unacceptable”.