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.

Like a lot of the state legislation dealing with privacy and security, it has a few problems....Nevada's law applies to all PII transmitted electronically except via facsimile. I'm not familiar with the state of the art in sniffing and hacking facsimile transmissions, but I'm guessing it isn't rocket science. The definition of encryption in the statute is bears no resemblence to any other definition I have ever read, and it opens the door to many different security controls potentially being permissable under the definition. See the definition at the end of the article, which should give cryptographers a lot of heartburn. You could use a simple letter substitution and have it pass for encryption using their definition. Well intended, but poorly executed in my book.

The proliferation of state laws dealing with privacy and security continues, and it raises some interesting bigger picture questions to think about...

• Keeping track of the various state's individual regulations and requirements is becoming a real quagmire, as they are diverging in terms of what comprises PII, what the organization needs to do in terms of breach notification, and what controls must be put in place.
  
• State compliance regulations like this are all bark and no bite- it's not like Nevada is going to have an enforcement group running around checking to make sure that every business that deals with PII is using encryption (as they define it). I guess if you had a breach, that fact that you might not have been using encryption might open you up from a liability standpoint.
  
• Are state legislatures really equipped to define best practices for securing access to PII? The answer is pretty clearly no.
  

It seems to me that we really need a federal law that is carefully constructued in this area.

Jim

NRS 205.4742 "Encryption" defined. "Encryption" means the use of any protective or disruptive measure, including, without limitation, cryptography, enciphering, encoding or a computer contaminant, to:

1. Prevent, impede, delay or disrupt access to any data, information, image, program, signal or sound;

2. Cause or make any data, information, image, program, signal or sound unintelligible or unusable; or

3. Prevent, impede, delay or disrupt the normal operation or use of any component, device, equipment, system or network.

 

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 combination of data breach laws with the antiquated and one-sided license agreements prevalent in the software industry has put IT organizations into a "squeeze play" of sorts.

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 Joint Commission, previously known as JCAHO, is updating some of the standards and elements of performance relating to information management, privacy, and security. Many healthcare organizations seem to pay more attention to the Joint Commission standards than they do to HIPAA, because have JCAHO accreditation is very important to the organization's business performance. JCAHO accreditation is an independent measure of healthcare quality of performance, across many areas of their business (information management being one). Liability insurers look to JCAHO accreditation as a measure of quality and risk, so this tends to be a big deal.

Joint Commission information management standards which are changing include:
IM 02.01.03, EP 5, which now reads "The hospital protects against unauthorized access, use, and disclosure of health information". The previous language just said "The organization implements the policy".

IM 02.01.03, EP 8, which now reads "The hospital monitors compliance with its policies on the security and integrity of health information".

The language is obviously not overly prescriptive in terms of how healthcare organizations are supposed to achieve these standards. One assumption is that the organizations will turn first to the HIPAA Security and Privacy Rules for guidance. Maybe they will also look at ISO27002 for more specific controls relating to information security.

These and the other changes to the JCAHO information management (security and privacy) standards are important because healthcare organizations now have the Joint Commission accreditation process at risk if they fail to adequately implement their information security program.

Jim

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.

I have been reading Geekonomics, and the further along I get in it the more I think that the systemic problems we face in IT security need to be solved at a lot higher level than throwing security technologies at each new problem that emerges. (BTW- it is an excellent must read for those in the security industry, and particularly for those who aren't but who need to understand where we are at, and how we got here)

I was also reading an interview in the most recent issue of IEEE Security & Privacy with Jon Swartz, who has covered IT security for USA Today, and who has a new book out called Zero Day Threat. There was a line in it about sabre rattling in Washington DC after some Senators identity information was stolen, but then losing interest when a Supreme Court appointment came up.

Maybe this latest set of hacking incidents will stir our elected representatives to actually look at and do something about security.

Jim

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.

I agree with Eric that Google should comply with HIPAA privacy and security rule requirements, after all, they set a fairly low bar on the security side. I also think that CMS should start thinking about these cases, because we will see more of this in the near future, both from Google and Microsoft, but also from regional health information networks, and other medical record sharing entities that are not technically providers of healthcare services.

Jim

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.

By way of introduction, I worked for one of the early IT-GRC product vendors (before the analysts decided that IT-GRC was different from enterprise GRC). I have also done consulting work for another vendor in this area, and I have authored a course on IT Risk Management. I have had enough exposure to large end users that I would like to think that I understand where these products provide value and utility, and where there are holes.

First, I think it’s important to draw a distinction between the enterprise GRC crowd (Pasisley, Open Pages, Axentis, and others), and the IT-GRC crowd (I would put Agiliance, Brabeion, ControlPath, Avior, Compliance Spectrum, Relational Security, Modulo, and Archer in this category). The enterprise GRC products tend to be all about workflow, with little depth in the area of IT risk assessment, analysis, and management, and little depth in the IT security-centric compliance regulations and standards (HIPAA, GLBA/FFIEC, NERC/FERC, PCI, ISO27000, BITS, FISMA). By contrast, the IT-GRC products tend to have a lot of depth in terms of very specific controls and requirements that relate directly to these regulations and standards. These two categories are different products, solving different problems, being sold to different audiences.

My 2 cents on the IT-GRC products- they provide a lot of functionality that highly regulated (read financial services) organizations need. They structure security management, providing the means to assess compliance to an external regulation, or to an internal, best practices framework. They also structure the workflow of security and compliance- in one analyst briefing I did a few years ago, the analyst remarked that the IT-GRC product in question was sort of for security & compliance managers like Peoplesoft was to HR managers. In a large organization, managing security and compliance can be overwhelming, and these tools give the manager a better way to manage the overall effort. And there is value for the business units and their management in these tools.

They are not without fault- as I have blogged previously here, few of them do much in the way of true analysis of risk. Most of them stop at helping to gather data about risk, or they use some proprietary method to try and calculate risk, as I have also blogged about previously. But to characterize these products as dead is wrong.

There’s also the familiar dynamic at work here that the analysts have decided that this category will be called IT-GRC, and therefore the vendors will all have to rush to provide more and hopefully better "R”, and even some “G”, irrespective of what their users are asking for, lest the vendors get left off the MQ, Wave, or whatever.

To Chris Hoff's contention that GRC products are "audit driven compliance all tarted up", I think you have to tell us if you're talking about enterprise GRC, or IT-GRC. Many of the IT-GRC products are *highly* asset focused. There is a direction in some of these tools to create direct linkages to data from other security tools- vulnerability management systems, configuration management, etc..

I will agree with Rich on this point- security vendors putting a little GRC lipstick on their favorite pig probably isn’t a great strategy.

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 AJAX and other new technologies.

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.

Then there are the big, cataclysmic security events like TJX, Societe General, or Hannaford. With highly impactful security breaches like Hannaford, it sometimes takes a while to understand not only the “how-what-where-when-why” detail aspects of the breach, but more importantly the likely future impacts.

The future impacts and likely consequences as a result of the Hannaford can be expected to be significant. Consequences to Hannaford will no doubt include fines and a lengthy mandated security program (with external security audit and review) from the FTC. In terms of PCI compliance, it isn’t entirely clear if penalties can be imposed by the credit card payment chain. After all, Hannaford claimed PCI compliance. The bigger long-term impacts will likely be to the future of the PCI standard- once the attack vector and vulnerabilities, whether technical or administrative, are better understood, the PCI standard will have to ratchet up the controls specified so as to prevent these attacks in the future.

To the general IT world, this latest big breach adds more fuel to the fire for a US national law on consumer data privacy. This was a sophisticated attack that should rightfully scare the heck out of IT security execs in all sectors and industries. It is also a reminder that compliance does not equal security.

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.