Occam’s Razor for Information Security

What if the principle of Occam’s Razor was applied to information security controls?

“All things being equal, a simpler explanation is better than a more complex one”

In other words, if we spent more time applying simple controls rather than chasing buzzwords and “big stories”, would we see an overall reduction in data breaches?  According to the recent  Verizon Communications report (pdf)  we would.  The report indicates that 97-percent of data breaches were the result of bad guys using simple techniques that could have been countered by applying “simple or intermediate” controls.  Have we been running in circles for this long when the “simple” solution has been staring right at us?

I think this is the case because “simple” things are boring and mundane.  As such, people become complacent and start to believe that effort placed on simple tasks is a waste of time since the “real” threat is going to be much more sophisticated.  If the reported facts of data breaches are true, then that belief isn’t supported.

A variation of Pareto’s Principle (the 80/20 rule) seems to come into play.  Perhaps if we are diligent in applying simple controls (the 20%) then maybe 80% of breaches can be avoided.  Maybe instead of focusing on complex systems that require massive amounts of human resource overhead, a focus on simple controls would yield greater security results.  Applying the principle of least privilege to limit access to sensitive information or replacing local administrator rights on workstations with user or power user may just have a bigger payoff than a $100k SEIM solution that is never fully deployed.

If most breaches are due to a failure in applying simple security measures, then doesn’t it make sense to apply our efforts in improving simple controls?

———————————————————-
Photo Credit:  ddpavumba at freedigitalphotos.net

Checkbox Security Fails Again

Regulatory compliance is often a confusing mess.  Rattling off the alphabet of compliance can often result in dizziness, headaches, and for some, a bad case of nausea.   PCI-DSS, HIPAA, HITECH, GLB, SOX, and heck, might as well throw in some state data breach notification laws as well.  Congress doesn’t want to stop there as they continue their efforts to add even more to this list of rules to live by.

Don’t get me wrong.  The rules are there for a reason (though often they arise from knee-jerk reactions to events so that our Representatives can appear to be doing something useful).  The problem is, with so many different regulations with varying definitions and requirements attempts at compliance start to resemble the traffic signal depicted to the right.   The cure for one bout of “alphabetitis” doesn’t necessarily vaccinate you for the others.  In the meantime, while you’re running around creating paperwork for compliance and checking off boxes, your ongoing security efforts essentially fall into the “to do” bucket.

Unfortunately, it has been proven time and time again that point-in-time, checkbox security is ineffective.  Unless you live in a spider hole like a Doomsday Prepper you may have noticed a recent breach of credit card data.   If you are a “prepper”, here’s a quick catch-you-up article from ABC News, April 2 -  “Experts Say Global Payments’ Breach May Not Be Only One“.

But wait!!  How could this have happened in the era of PCI Compliance? 

To be blunt, building an information security program around compliance is an approach steeped in failure.  The desire is very strong to have a favorable audit report but once that is over, the focus tends to shift away from the continuous protection of sensitive information.   As we continue to see breaches impacting organizations that have been engaged in and satisfying compliance requirements, you have to think about where the real problem lies.

Michael Mimoso was quite clear in an article “Global Payments credit card security breach exposes PCI shortcomings” where he said:

Clearly, PCI DSS continues to be a joke and a money pit that isn’t about security, but at a minimum, point-in-time compliance.

With that in mind, how do we step away from the point-in-time compliance effort and focus strictly on security.  As is often the case, let’s look at something entirely basic.  In order to protect something you have to know what it is.  Regulators and legislators aren’t helping in this regard.  Protected information is defined differently depending on the flavor of legislation you’re working with.  Wouldn’t it make sense to have a single definition of sensitive or protected information and then set in motion the defenses necessary to protect and monitor that data on an ongoing basis? If you store, process or transmit data under this one definition then you have to protect it regardless if you’re in healthcare, finance, or any industry vertical that uses such information.

I don’t think we can rely on government to help in this regard.  So, create your own matrix of sensitive information (maybe I’ll take that on as a project and post it) and then apply the SANS 20 Critical Controls or use some other framework to build a year-round, continuous information security program that protects that data all the time rather than playing the mark and erase checkbox game of compliance.  If you have deployed a solid information security program then compliance audits should, quite frankly, be a simple verification process.

 

_________________________________

Photo Credit: Stuart Miles at Freedigitalphotos
Illustration Credit: digitalart at Freedigitalphotos

They did WHAT with my data?

What are your employees doing with your data?

I know… they are all doing their jobs and not doing anything out of the ordinary.  Unfortunately, that isn’t always the case.  Time and time again, we see individuals inside an organization abusing their access to inappropriately view, or in the worst case steal, sensitive information.

Take for example this recently reported case in Hawaii – “HCFCU admits member information breached“.   Almost a year ago some “trusted” employees accessed information to fill up petitions for the credit union board nomination process.  Another employee thought this was messed up and reported it.   The credit union is putting employees through “new training” to reinforce policies.   I hope they have other tools to detect inappropriate access other than relying on the “just tell us” approach.

This is just one of many example of insiders breaching confidentiality.  This happens quite frequently whether it is the budding entrepreneur stealing your customer lists to go into business on his own or the hospital employee swiping medical records of celebrities to sell to the paparazzi.    The insider threat appears in just about any industry vertical.

Ask yourself:

  1. Who has access to what information?  Do they need that access to perform their job?
  2. When someone changes jobs internally, do you just tack on their new permissions to their old OR do you remove previous access and give them what they need for their new position?
  3. Do you have generic user accounts or does each person have a user account that identifies them and their access?
  4. Can you tell who has accessed your most sensitive information and when?   Is access times or number of records accessed outside of the norm?   Do you know what to do when that happens?
  5. Do you have incident response procedures in place that direct you on how to handle a breach should it occur?

Based on your answers, you may be at greater risk of a breach.   There is no such thing as 100% security but taking appropriate measures to safeguard sensitive information from external and internal threats, being able to detect abnormal behavior, and having a plan “just in case” all fit within the practice of due diligence.

In information security, you can’t assume that everyone will do the right thing.  Too many organizations have experienced the results of such assumptions in terms of dollars and cents, tarnished reputation, lost customers, and for some..they shut their doors.   It simply isn’t worth the risk.

Photo Credit:  photostock at freedigitalphotos.net

Before I hire you I’ll need the keys to your home…

I wouldn’t believe it if I didn’t read multiple stories talking about employers asking prospective employees to hand over their Facebook passwords during job interviews.  This is simply outrageous yet I can see how those who have been looking for work for over a year may feel compelled to provide their credentials or lose an opportunity for employment.  This really ranks as a big thumbs down for employers who are engaged in this behavior.

Now, I’ll be the first to say that publicly accessible information in a digital world is fair game.  If you allow pictures of your pot smoking adventures or previous dime-store stealing expertise to be available to anyone on the Internet then you can’t complain when that public information ruins your chance of getting a job.  If you’ve been bashing an employer on public forums using your real name, I would think that an interviewer can fairly question you about it.  The thing is, what you decide to make public on the Internet is part of your global resume available for any potential employer to view.  You can’t cry foul.

That said, asking a potential candidate to turn over their user ID and password so you can view something intended to be private is beyond the pale.  That is no different than invading a candidate’s home, snooping through their medicine cabinet and snatching their diary from under the mattress in order to read their “private” thoughts before making a hiring decision. This isn’t an episode of House, right?

Let’s take this a step further.  Do potential employers have a right to access information related to friends and family who aren’t applying for a job?  A request for Facebook credentials gives access not just to information a candidate has deemed private but also allows them to pry into the private information of friends and acquaintances.  Insanity anyone?

The potential for abuse here is enormous.  While it is fair for any employer to do as extensive a background check as they feel is necessary to vet potential employees (criminal, financial, public records, internet search, etc.), it is not appropriate to invade into areas that someone has explicitly chosen not to expose publicly as part of the hiring process.

 

Photo credit:  ntwowe at freedigitalphotos.net

Lessons in Due Diligence

An article by Kim Zetter on Wired.com caught my attention:  “Restaurants Sue Vendor for Unsecured Card Processor”.

The gist is that several restaurants purchased Point-of-Sale (POS) systems from a particular vendor.  These POS systems that were sold were apparently not Payment Card Industry – Data Security Standard (PCI-DSS) compliant and that resulted in a breach costing the restaurants a hefty sum.

One issue comes from unpatched, poorly configured remote access and the other alleged problem came from default login administrator userID and passwords.  From the article:

Visa also sent out a bulletin in November 2006 warning that one of the most frequent vectors for hackers to penetrate POS systems was through poorly configured or unpatched remote-access software (.pdf) and default passwords. Nonetheless, the restaurants say, Radiant and Computer World sold them a product that was neither PCI-compliant nor secured against a known attack.

So, the vendor sold them the product that was known to have these flaws but on the flip side, the restaurants bought these systems that are known to have these flaws.   I can certainly see the case here but from a security perspective there are some lessons learned when it comes to due diligence and basic security practices.

1.  If you blindly believe marketing slicks about the “state-of-the-art” product you’re purchasing that can do everything including cooking your dinner and washing dishes…well… you get the point.   Visa had produced a bulletin regarding the flaws with the product a year before one of the restaurants bought the product.   A little due diligence in the selection process would have gone a long way.

2.  So, you buy a product and install it.  It has remote access capabilities.  You leave the default administrator ID and password that is well known to anybody who can grab an online manual.  You’re breached.   If you install a new software product for Pete’s sake, change the default account passwords.  If your bank gives everybody a password of “password” to their online banking, would you change yours or just leave it?  (BTW, they don’t do that… just an illustration).

3.  Implementing a system with known flaws and not updating it is pretty bad.  It’s like installing a Microsoft server and not applying security patches for a year.  You get breached because of a vulnerability that should have been fixed a year ago.  Good luck blaming Microsoft for that one.   Patch management is essential.

By no means am I blaming the victim in this case.  They are chefs and restaurant managers, not IT or InfoSec people.  They relied on the vendor to provide them a product that was up to snuff with PCI requirements and trusted them to sell a product that protected their customer’s information.  When we examine and extended this into our own business and technology implementations, their experience provides some lessons for all of us.  Hopefully we can learn from this and apply due diligence to all of our vendor interactions and purchases.