paulmudgett.com

I’ve been mulling on the appointment of Howard Schmidt as U.S. Cybersecurity Coordinator for several days.  This is the appointment that has been 10-months in the coming since President Obama vowed to create the post.   This is the role that was previously filled (at least functionally) by Melissa Hathaway who left over frustration with the way the U.S. government works.  Before her, it was Amit Yoran who was the cybersecurity czar for DHS.  He was dessimated by bureaucrats and lasted only a year.

Schmidt had a previous run as a cybersecurity advisor for the G.W. Bush presidency.  From all accounts he is a skilled man with an impressive resume.  Unfortunately, the position itself has been designed with so many obstacles that success is unlikely.  Though he is supposed to have access to the President, the position is several steps down the organization ladder.  As I’ve seen in the private sector, when you place security out-of-sight it quickly becomes out-of-mind.

The mission of the position has been set by President Obama but with executive-level focus on so many different arenas, I’m afraid the cyber-security talk will be just that… talk.  This position is one with a lot of responsibility without the authority needed to accomplish the goals.  A recipe for failure in any organization.  This nation needs information security leadership.  Howard Schmidt is the right man but the position will limit his ability to succeed.   Best of luck!  I hope I’m wrong.

Articles regarding this appointment:

Rotella, Sebastian.  “Howard Schmidt named cyber-security czar“.  LA Times, 12/23/2009

Nakashima, Ellen.  “Obama to name Howard Schmidt as cybersecurity coordinator“.  Washington Post, 12/22/2009

How do you even start protecting your information assets if you don’t have an understanding of the risk to them?  I would venture to say… you don’t.  It’s difficult for some to get started down this path because they quickly get overwhelmed with the task at hand.  Many times, a good effort gets set aside because the level of detail gets too cumbersome to reach the finish line.  Perhaps this can help.

Organizational assets

You have to know what you have but it doesn’t have to be a lonely road to get the information.  Start with a network scanning tool to detect the systems on your network and try to understand the type of data being stored on each.  However, don’t try to perform a risk assessment on each individual system.  Group them into sensible categories based on type of data (customer, HR, financial), application type (web, database, app) or business function (web, e-mail, accounting/finance).

Find out who “owns” this data.  A department head, Director, VP, whoever is ultimately responsible for the data.  Remember, determining risk is a business responsibility and it is up to Information Security to adequately illustrate the risk and controls so that informed decisions can be made.

The Risk Rating Matrix

There are many ways that this can be done and even sample matrices you can use online.  Take your pick.   Some assign rankings for Threats, Vulnerabilities, and Impacts for each part of the security triad (Confidentiality, Integrity, Availability).  Some take into account compensating controls.    Some use liklihood of an event happening.  Some multiply their risk rating by how easy it is to detect an issue to get an overall score.

Regardless of what method works for you any method should take these suggestions into consideration:

• If you are assigning scores in your rankings of threats, vulnerabilities, impact, etc. make sure you use an even numbered scale like 1-6.  This eliminates the “middle of the road” pick and forces one to fall on the high side or the low side.
• Make sure each ranking number is labeled so that it is easy to understand what a 2 means versus a 5.
• Provide an overall ranking that can be used to compare risks and prioritize them for clearer decision making.
• Doing something is better than doing nothing.  Don’t expect perfection the first time out.

Take Action

With your rankings and priorities established in collaboration with the data owner you are in a better position to implement controls that provide value.  The acceptance of risk should be firmly in the hands of the data owner (and signed off on).   When budgets are tight, you now have the opportunity to address the biggest risks because you have taken the time to identify them.

There is no such thing as 100% security.  Reducing your risk profile by applying a measured approach to risk management is however, entirely possible.  Doing nothing is a bad choice.  Where do you want to be?

The U.S. House of Representatives has passed HR 2221, the Data Accountability and Trust Act.  This sets nationwide breach notification requirements that trump the patchwork of State laws that have been in effect with California leading the way in 2002.   The passage was written about in a Federal Computer Week article “House passes bill to require data breach notifications“.

Overall, standardizing the definition of Personally Identifiable Information will help in protecting the data.  This is a good thing as some states have more stringent definitions than others.   Data brokers have greater requirements.  Also a good thing.

The problem I see comes from the FTC having jurisdiction over the new law.  The FTC does not have authority to enforce regulations on government, banks, savings and loans, insurance industry and non-profits which would include higher education and some healthcare environments.  These industries are often the victims of data breaches yet they aren’t covered by this new federal law.

We’ve seen the FTC extend its reach with the Red Flags rule and perhaps they will follow suit with the new data breach notification legislation.  If they let some industries with known disclosure issues slip through the cracks then the overall effectiveness of the legislation is diminished.

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.