Bill’s Security Blog

When most people talk about SCADA, they are generally including a whole lot of stuff that is not SCADA.

In general, true SCADA systems are and must be connected in some way. This is generally because they are located over a large geographical area. DCS systems are sometimes called SCADA, but they are not. DCS systems are what you find in small foot-print facilities, like a prison, a power plant, a bottling company.

These systems are generally similar in that they monitor and control a physical process. In the case of SCADA, these are dispersed over a large geographical area. In DCS, they are centrally located. In almost ALL cases, there is never a need to receive data from “outside” the SCADA or DCS system. The data is generated inside the system, and is often pumped out for analysis and monitoring. (It’s when we connected them that we screwed the poodle.)

This is important when it comes to securing these systems. When your digital assets are located over a large geographical area, you need some type of connectivity (4G, wired Internet, RF, whatever) that ties these together. This increases the attack surface.

However, if all your digital systems are in one small geographical area (e.g., a industrial plant), it’s easy to “snip the wire.”

Now, we can have a religious debate about air gaps - but that’s meaningless. When people say, “there’s no such thing as an air gap” they assume a whole bunch of conditions that may or may not be true. For the record, I will smack the next person that says, “there’s no such thing as an air gap.” The correct expression is “creating an air gap is hard.”

When securing industrial facilities that use digital equipment of various vintage and capability, creating an electronic air-gap is one step in implementing a robust “air gap”.

I try to think about the “air gap” as implementing controls to address “bad juju” that can get into or out of your digital equipment along 5 key vectors:

1. Direct network access (all types)
2. Wireless network access (all types)
3. Portable media and equipment (used to maintain digital assets, or to move data to-or-from digital assets)
4. Direct physical access (if you can touch it, you can pwn it…)
5. Supply chain (including vendor patching processes, and procurement-related issues)

Certainly, these can be collapsed into two vectors - logical and physical access - however, adding some granularity helps with discussion!

To illustrate - if the digital asset has no wired or wireless networking, physical access is controlled to authorized people with appropriate training, portable media and equipment that is connected to the system for maintenance and patching is rigorously protected, and we ensure any software or hardware coming in through the supply chain has reasonable degrees of security - then we have a well protected system. (Note, this gives you a good start on the prevention piece, but does not solve the monitoring/detection or incident response piece).

To establish an “air gap” we must address threats that can materialize along any of the 5 key vectors. If we do this successfully, then I will say, “you have a pretty good air gap.”

These vectors are very hard to address in a corporate environment, where the critical asset is DATA, and not hardware. The data is too easy to move, so it is nearly impossible to address all vectors to the data. Securing SCADA systems is also hard for similar reasons. But in terms of complexity, to get equivalent levels of protection for Data, SCADA, or DCS, I think the distribution of work would look as follows:
DATA - 85 %
SCADA - 10 %
DCS - 5 %
IE, if you spent 5% of your security budget on your DCS system security, you’d get equivalent protection as the 85% you spent to protect DATA.

The challenge is - we’ve spent decades working on data security (centuries if you consider crypto a part of data security), but only short years talking about SCADA and DCS security. So, as all humans do, we have to screw this up 1,000 times before we spend 10 minutes trying to figure out how to do it right once…

The attack vectors and mitigation are not exhaustive, and are exemplary only.

A denial of service (DOS) attack is an attack against limited resources. A DOS attack is an attack against the “availability” function of the typical “CIA” security triad of “Confidentiality, Integrity, and Availability”.

A DOS attack is perpetrated by applying enough pressure against a target that the target’s resource allocation is overwhelmed.

In the question you posed, a DOS attacks can be perpetrated against any resource that supports the Web infrastructure.

A successful DOS attack against a web site tends to exhaust resources in one or more of three primary categories:

1. Network resources (routing capacity, network bandwidth, etc)
2. Web server resources (processor power, memory power, host networking capacity)
3. Database server resources

Mitigating a DOS attack involves protections at all three levels of the infrastructure.

One popular DOS attack is the “Distributed Denial of Service” attack.

Mitigation for this type of attack include:

• Network layer traffic filtering to attempt to block sources of the network-based DOS traffic.
• Increased network bandwidth and capability – Can you out-power the attackers.
• Website mirroring and caching can be employed.
• Website collocating can also help. If your website is hosted on multiple physical networks, taking the site down involves attacking multiple network resources.

A second attack vector is against the web server’s physical resources.

Perhaps you can get enough traffic through the network filters to overwhelm the web server’s processing capabilities.

Mitigation for this type of attack include:

• Throttling network filtering to ensure that the web server(s) do not get more traffic than they can handle.
• Website mirroring helps by adding additional capacity.
• Caching can also help by reducing the amount of processing necessary to serve the site.

Another type of DOS attack is a targeted attack against the applications running on the website.

If the website uses a database back-end, it is possible to execute a DOS attack by using SQL Injections that destroy database integrity, or prevent database access.

Mitigation for this type of attack include:

• Proper coding practices in the web applications that prevent SQL Injection attacks.
• Proper database account security that prevents unauthorized destruction of data.
• Database redundancy that attempts to keep the data available even if one or more data source is unavailable.

Bruce Schnier summarizes and expands on the discussion from several security professionals in his post, “Security ROI” - quoting parts:

“ROI” as used in a security context is inaccurate. Security is not an investment that provides a return, like a new factory or a financial instrument. It’s an expense that, hopefully, pays for itself in cost savings. Security is about loss prevention, not about earnings. The term just doesn’t make sense in this context.

And a company should implement only security countermeasures that affect its bottom line positively. It shouldn’t spend more on a security problem than the problem is worth. Conversely, it shouldn’t ignore problems that are costing it money when there are cheaper mitigation alternatives.

I don’t necessarily agree that you should see a direct impact on your bottom line as the result of a security investment. I believe security investment is more like insurance where there may be no direct cost savings, but reduction in potential cost. I also like the insurance analogy because I think most non-security people can quickly grasp this analogy.

Let me explain.

As Bruce alludes to in his article, he traditional model for calculating risk in the security space is:
risk = threat x vulnerability x consequence

In my mind, “security” investment helps provide the mitigation necessary to reduce the vulnerability variable to a point where the risk value is acceptable.

Security countermeasures are a risk mitigation strategy.

Insurance is a little different, it helps offset the consequence variable.

But there is a similarity between “security” and “insurance” that I think most business people can understand.

They are both investments you are happy to pay, because they offset expected risk.

I have health insurance, car insurance, term insurance, permanent insurance, disability insurance, and probably a host of others as a part of my compensation package.

I’m very happy to “throw this money away” because it offsets risk to the point that I’m happy.

If I died today, I know my fiance will be taken care of, financially. I don’t see a direct reduction in my expenses, or increase in bottom line revenue if the threat never materializes.

I think business investment in security products and services are similar.

We implement them to reduce the risk value to the point where we are satisfied.

I like the insurance analogy, and think that it is much more tactile for non-security folks.

Bill

From the UK’s vnunet.com:
Hackers breach Best Western in data heist

It seems the hacker managed to insert a Trojan into the computers of a hotel and logged the user name and password of someone with sufficient security clearance to gain access to corporate servers.

Interesting, but not ingenious.

It does seem to indicate that the attack was target explicitly at data theft, rather than someone stumbling across a SQL injection attack vector.

How could defense-in-depth have helped here?

I guess we still need to learn a little more about how the attack progressed.

• Did the user get remote access to the SQL server?
• Was the website capable of retrieving this type of data if the user login credentials were sufficient?
• Did the attacker’s trojan dial out to a remote server allowing the perpetrator to take complete remote control of the box?
• Even if he had full remote control, was there any content filtering in place to prevent that data from traveling over the network? I guess the attacker could have encrypted the channel…

More from SecurityFocus.com:
Denial, hype cloud report of Best Western breach

“We can confirm that on August 21, 2008, three separate attempts were made via a single log-on ID to access the same data from a single hotel,” the company said in a statement released late Monday. “The hotel in question is the 107-room Best Western Hotel am Schloss Kopenick in Berlin, Germany, where a Trojan horse virus was detected by the hotel’s antivirus software.  The compromised log-in ID permitted access to reservations data for that property only. The log-in ID was immediately terminated, and the computer in question has been removed from use.”

Best Western said that it had narrowed down the number of customers affected to 10.

.

Motivating my thinking is yet another data breach.

This time, reported by Scotland’s Sunday Herald in an article:
Revealed: 8 million victims in the world’s biggest cyber heist

Target:
Best Western Hotels

What was lost:

Amounting to a complete identity-theft kit, the stolen data includes a range of private information including home addresses, telephone numbers, credit card details and place of employment.

According to Bill Brenner of SearchSecurity’s analysis of the 2007 Ponemon Institute study on data breach costs, the average cost of a data breach was roughly $200 per record.

The expected cost to Best Western: 8,000,000 records X $200/record = $1.6 billion dollars USD.

Now, none of this is rocket science.

Research on the cost of a data breach is published regularly, and most companies can easily determine their total number of potential records.

Looking at a bedrock equation of information security:
Risk = threat x vulnerability x cost

We’ve already got the cost, and it should be assumed that an organization like Best Western should expect the threat of being attack to be very high.

Last is the Vulnerability component.  The vulnerability is the loss of personally identifiable information up to and including the loss of credit card data.

While an organization like Best Western may not be able to affect the threat and cost components, they sure can do a lot on the vulnerability front.

They can do that through a number of mechanisms, both technical and non-technical (insurance and whatnot), and hence reduce the total risk.

I’ll focus on a few simple things:

1) Determine what is the most costly data to loose

Certainly, does an organization need to maintain the credit card information of every patron after they have cleared their tab?

If so, should that data be encrypted?

And should access permissions be put in place that prevent bulk reads from the database account servicing the website?

How much non-credit card customer history information do you really need to use for business analysis?

If  you don’t need more than 3 months of client data, then archive the rest off-disk.

The rule of thumb in this area, is that if the data isn’t critical for business operation, then get rid of it, securely!

2) Analyze insider access

Who/what, internally, has need-to-know access to the data?

How much access do they need?

Are policies, procedures and technical controls in place to prevent unauthorized access?

3) Analyze partner access

What partners have access to the data?

Exactly what data do they need?

Are they accessing the data using accounts that forbid unauthorized access to information they shouldn’t see?

What is the partner’s security policy for dealing with this information?  Can you trust them?

4) Review policies, procedures, and do validation

Regular review of policies and procedures should be performed.

And most importantly, routine validation of the system should be performed.

A validation check should be a timed, and triggered event.  It should be timed regularly to ensure that it actually happens.  And it should be triggered by such things as: a new partner added; a DBA is terminated; a new contractor is hired…

5) Assume the worst will happen

Because it will.

Bill