Bill’s Security Blog

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