Bill’s Security Blog

Over the past semester, I have had the opportunity to assist a co-worker who was taking an “Introduction to C++” class.

I was a C++ tutor in my undergraduate program, and I helped a lot of my fellows in the Master’s Degree program I was in at JMU. Though I’m no expert, and haven’t done any C++ since graduation, I have probably written close to 25,000 lines of C++, and was excited to get involved.

My coworker was taking the class in the context of an IT Management class that has a focus on security and disaster recovery.

After she submitted her last project, she sent me an email talking about how tough the class was for her.

Below was my reply. I felt it worth capturing in a blog post…

…
Also, don’t worry if you didn’t leave this class as the world’s best developer.

I think the real take-away is that coding is hard. It’s really, really hard.

It’s easy to make mistakes, very easy.

And it’s easy to hack something together, just enough to get the project done. It happens ALL the time. With the simple tools at our disposal, even novice developers can develop huge, web enabled, and EXTREMELY BUGGY software.

And from a security perspective, you must remember that fact ALL the time. That is the big learning lesson!

Not only will the software you buy have bugs.
But so will your firewalls, your anti-virus, you name it.

Coding is hard. It is F’ING hard.

And even worse, you can take two completely secure pieces of code, and put them together. And you know what, the result may have security bugs!!!

Remember your experiences in this class. Use that experience to govern your thinking in future security related projects.

The experiences you have had are why my number one motto is: “Security through simplicity.”

It’s my opinion that every piece of hardware or software increases risk through it’s very nature.

Even a security countermeasure has some implicit security risk that must be assumed.

On the business side, when implementing software, or installing a new piece of hardware you make a business case. Does the hardware or software save money, or allow sufficient increase in revenue to justify the cost.

From the security perspective, particularly with security countermeasures, that equation is a little different. The “cost” is measured in risk.

So the consideration must be: Does the amount of risk offset by the countermeasure, adjusted for the inherent risk associated with the countermeasure itself, reduce the overall risk sufficiently to justify the use of the countermeasure.

It’s a tough equation, given that it can be tough to calculate the risk inherent in a security countermeasure.  Why?  Because we want to think that security systems are secure.  But we know the truth.  We know how deep the rabbit hole goes.

For example, what’s the risk profile of a firewall?

Well, there’s a lot. Among them:

• Potential for flaws in firewall hardware and software that could allow unacceptable traffic through.
• Potential for human error in configuring rule sets.
• Potential for the firewall to fail in an unsafe mode.

And there are plenty of associated costs.

• Cost of the system.
• Cost of maintenance.
• Cost of developing security processes and procedures to manage the firewall.
• Cost of developing and maintaining trained staff to manage the firewall.
• Cost to accurately monitor the system.

The logic is cyclical.  The more risk you offset, the more you assume.

Hence my motto:

Security through simplicity.

Bill

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

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