Nevada is set to start enforcing compliance with a law governing how businesses operating in the state can transmit personally identifiable information (PII). The law (see article here, or see the actual statute here) was passed last year, and it goes into effect October 1st. It requires the use of encryption (or something that might faintly resemble data encryption) when PII is transmitted.
Following the lead of Minnesota, the California legislature
recently
passed legislation (AB 1656) that requires retailers to implement data
protection controls if they retain customer’s personal information. The
California bill does not require retailers to compensate card issuers for the
costs of closing accounts and reissuing cards, but it does require the
retailers to notify consumers affected by security breaches, with the cost of
notification being borne by the retailer. With significant amendments from the
original bill that was vetoed by the governor in 2007, this version of the bill
is expected to now be signed.
The Minnesota
law, signed into law in 2007, goes further by putting the liability for the
cost of card reissuance on the retailer rather than the issuing bank.
My prediction is that we will see continued legislative
pressure to move the costs of breach cleanup away from card issuing banks, to
those responsible for the breach (oftentimes the retailers).
An interesting aspect of this new bill is that it is more
prescriptive than the state data privacy laws typically are. The bill has
specific language around storage of cardholder data, a requirement to have and
implement a policy regarding customer information data retention, limiting
access to only those whose job requires access, and use of encryption to protect
cardholder data.
At a glance, the language used seems to mirror the
controls found in PCI 1.1, which is good. But it is one more set of controls
that have to be understood and accounted for if you are a firm that operates in
the payment card processing chain, and if you are doing business in California.
As with SB1386, this law applies to breaches involving California
consumers , meaning if you have California consumers in your customer base, the
law applies to you.
I am reading Geekonomics at present, and while there are many reasons to praise the book, one of the key takeaways for me has been something that I haven't thought about previously. Namely, that the data breach laws that have come into existence in the past few years have put IT in an untenable situation, because they require disclosure of security breaches (and likely open the company up to legal consequences), but the company has no recourse on the back end. This is because even though many breaches can be directly traced to the software manufacturer's lack of software QA, as David Rice points out in the chapter entitled "Absolute Immunity: You Couldn't Sue Us Even If You Wanted To", software license agreements are highly one-sided, providing almost no ability for the user/IT organization to pursue the manufacturer.
The Joint Commission, which is a non-profit organization that publishes standards for healthcare organizations and runs an accreditation program, is updating some of their standards for 2009, including some which impact information security.
The story about China hacking into politicians systems has been in the news the today (Network World coverage). Maybe it's actually a good thing in the long run, because this kind of activity has the chance to actually stimulate our politicians in the US to think about how to address security issues.
Martin McKeay recently posted a blog entry on behalf of Eric Irvin that describes Google's personal health record services, and their posture relative to HIPAA requirements. The short version of the story is that Google apparently is not legally required to comply with HIPAA because they are neither a provider of healthcare services, nor a payer, hence they are not a covered entity as described in the HIPAA act language.
Great, a food fight erupts on one of my favorite topics, and I’m the last guy to reach for the mashed potatoes. Rich Mogul decides that GRC is dead, and Alan Shimel points out some IT security realities (compliance is a big driver) here. Chris Hoff makes a few points as well here.
Doing what I do in my day job, I sit
through a lot of presentations on various aspects of security. I had the
pleasure of sitting through a couple of presentations this week (one by a
leading analyst on Web 2.0 security issues, and one by a vendor CTO). My short
version of the takeaways from the talk were that there are a huge number of
security issues related to Web 2.0 technologies, including cross-site scripting
and many more. Many of these existed before Web 2.0, but are exacerbated by
Without rehashing a lot of the detail from
the event, the thing that really struck me was how similar my own internalized
summary from the event was to almost every other security presentation I have
heard in the last five years or so. You could almost use this as the punch line
to every security issues talk: “The security issues are not generally well
understood yet, they are going to be very significant, we’re pretty much
screwed, and we don’t know where the solutions to the problem are going to come
from.“
It’s a depressing conclusion to reach at
the end of most talks on IT security. And I'm generally an optimistic person, so it's not like this is my "glass half empty" self talking.
I am also wading through Geekonomics,
which appears to do a very good job of describing the big picture of how the IT
industry has reached this particular place at this moment.
I was out on vacation (and then at RSA) when much of the interesting detail about the Hannaford breach emerged. Security professionals and probably the general public are growing a little desensitized to security breach news, particularly of the type “company XYZ lost a laptop, and NN,NNN individuals NPI is now at risk”. This stuff is so commonplace that it gets tuned out. I guess it means that the markets for endpoint security technologies, full disk encryption, etc. will be robust for a long time, but beyond this, not much of a big deal.
A recent consulting assignment had me creating a comprehensive, 300 slide course on IT risk management. It was an interesting exercise, and gave me the chance to learn a lot about risk management. I am also exceedingly glad it’s done!
During the development of the course, I worked with a number of the vendors of IT risk management software tools, many of whom graciously allowed me to use screen shots to illustrate various aspects of the risk management process.
One of the things that struck me as I was building the course, and looking for screen shots to illustrate things like threat modeling, was how little functionality there is generally in this area. The IT risk management tools as a category provide a lot of functionality in the area of information gathering (modeling the organization structure, gathering information about controls in place via assessments or via API’s or direct connections). In some cases the tools will calculate risks purely on the basis of the existence and strength of controls (as evaluated). The tools then apply proprietary formulas to decide how much risk exists if a best practices control is lacking on a key asset. In essence, ignoring things like threat modeling, threat capability, loss event frequency, etc.. Many also ignore probable loss magnitude (or impact), and loss frequency.
If you think about some of the formulas and approaches to risk analysis that are drilled into every CISSP candidate…
Annual rate of occurrence (ARO) = number of times the threat can be expected to occur, affecting the asset, annually
Probable loss magnitude (PLM) = expected loss per occurrence
Annual loss expectancy (ALE) = ARO x PLM
… it seems like there’s a disconnect between the functionality in popular IT risk management tools, and the way that IT security practitioners are taught to measure risk. In looking at ten or so different IT risk management tools, I saw just a couple that had any functionality in the area of threat identification and modeling. And the functionality was pretty limited.
Risk analysis still seems to be more art than science, with qualitative versus quantitative debates, and multiple methodologies and frameworks (FIRM, FAIR, Octave, FRAP, and so on) available. Most of these frameworks assess and analyze risk differently, and there is lots of variability on basic things like terms and definitions. Few of the IT-GRC products map to these frameworks, and some of the products use a model that assesses the presence or absence of controls, and the maturity of controls, to determine the level of risk…a sort of best practices approach to gauging risk. The algorithms used to calculate risk are almost always proprietary. Relatively few of the IT-GRC products provide any real threat modeling capability.
My guess is that practitioners using IT risk management tools still end up doing a whiteboard exercise to quantify risk (or to assign a qualitative high-medium-low measurement).
I would love to hear from any users who struggling with this, and who use an ITRM tool. Understanding how you gather data for risk analysis, how much of the data you gather can be done by automated means, and how you then use the information gathered to conduct a risk analysis would be very interesting.
Also, I will post a link and blog entry on the risk management course when it is made commercially available, likely in 6-8 weeks.