Smart Grid Hackenomics

I recently attended (and presented at) the Department of Homeland Security Industrial Control Systems Joint Working Group (DHS ICSJWG) meeting in Seattle Washington. It was a interesting event, and STUXNET seemed to be the hot topic everyone was discussing. Most of the sessions were quite good, and many were informative.

When I attend these types of events, I often find the side conversations I have with attendees more interesting than the conference itself. I had the opportunity to chat with people who work at DHS, FBI, NRC...and just about any other 3 letter agency seeking to get a handle on cyber security issues. It does my heart good to know that our government is indeed serious about cyber security, and truly seeking knowledge.

The most interesting discussion I had, however, was on the last day. It was during a lunch break with one of the attendees, and we started a discussion on the economics of attacking the Smart Grid. Essentially, we agreed that "hobbyist" attackers and "nation-state" attacks are perhaps not the types of threats that should (or do) cause great levels of concern at the C-level's of stakeholder companies. At the highest decision making level of any organization directly affected by security threats, the only issue that consistently keeps them awake at night is money...or rather the loss of money. In fact, when we talk about security, we must constantly understand that an enterprise's chief (and arguably exclusive) security concern is in securing their ability to keep making money (and not lose money).

In other words, if security does not lead to more $$$, expect some rolling eyes. Likewise, if a lack of security leads to a loss of $$$, expect some wide eyes. This is the beginning of my Theory of Hackenomics.

In our discussion, we used the financial industry as an example of an economic model that makes a lot of sense to organized criminal enterprises. In the former Soviet Union, there are criminal enterprise organizations that provide tools and support services (for a fee) to criminals who want to make a career out of exploiting security holes in the financial industry. This is a very popular target for criminals because it is both large in size, and the direct result of a successful attack is immediate access to cash. So as part of my theory I want to state the following: The quicker an attack leads to cash for the attacker, the greater the likelihood that the attack moves from theory to reality.

This is, however, only part of the theory. The other part has to do with volume. For organized crime to get involved, the volume needs to be big enough to take the risk. Remember, organized crime is just as concerned with risk as corporations are (some will argue that corporations are the "new" organized crime anyhow). Therefore a quick path to cash that does not include a large enough volume is not necessarily a win for organized crime.

Another important issue to consider is keeping the attack as "clean" as possible, in order to make collecting and retaining the cash as easy as possible. A good example of this is how financial firms created Credit Default Swaps as a way to hedge high risk investments. This instrument allowed the potential for a large return on the chance that those who took out those crazy loans on overpriced homes (and such) would default. Well, as it turns out, those who purchased Credit Default Swaps seem to have done quite well. It was essentially a low risk method of shorting the entire financial system, and it is perfectly legal under today's laws.

So now this brings me to what became an interesting part of the lunch discussion. I postulated that if a large stakeholder in the Smart Grid ecosystem (in other words, a large publicly traded utility or AMI product vendor) was vulnerable to a major Smart Grid related attack, and an attacker held onto a 0-Day vulnerability, he could potentially sell the 0-Day vulnerability for a lot of money to a large criminal enterprise, who could then short the stock of the utility or product vendor, and then publicly announce the vulnerability. Granted, this would require some coordinated effort, but if done correctly, one could make a killing when the stock plummeted on the bad news. The news alone would probably drop the price enough to make a lot of money with a high enough volume. The news immediately followed by an actual attack would probably lead to a very big win for the criminal enterprise.

As we continue to have lunch, we discussed a few more ideas, and I thought of a few more over the last several weeks (I am not going to go into them here), and I came to the conclusion that Smart Grid Hackenomics may indeed be an interesting discipline for criminal organizations to investigate...and they probably already are.

Hopefully, the C-Level people at stakeholder organizations have thought of this as well.

Mobile Application Insecurity

Being someone who has develops secure mobile applications, I am consistently dumbfounded at large enterprises (who should know better) that fail to secure their mobile applications. A recent article in The Wall Street Journal highlighted some findings by viaForensics which pointed out several banking applications for mobile devices that store passwords unencrypted on devices.

The banking industry is no stranger to security concerns. They are indeed one of the largest purchasers of security products and services globally. The rush to bring mobile applications to the marketplace by enterprises has not overlooked financial firms, however, and they are simply not applying basic principals of secure application development - such as build security in from the very beginning, and test the security before deploying the applications. I am absolutely floored by the number of financial applications available on the iPhone (for example) that do not require something as simple as a PIN to enter the application after storing the password (let alone encrypting the password).

It is carelessness at best, and completely irresponsible at worst. Banks, Large Enterprises, and Health Care organizations should make maximizing security a priority with any and every application that deals with ANY potentially sensitive information...and they consistently fail to do so often enough to convince me that there will be a lot more breaches before things get better.

What I also find remarkable is how a company like Apple, who scrutinizes application submissions and regularly rejects applications that use foul language, show nudity, or (God forbid) replicates Apple functionality. Yet Apple does not bother to reject applications submitted by banking and health care organizations (the latter being something I am personally well aware of) that fail to encrypt information. Is this their responsibility?

Yes it is!

Security is everyone's responsibility, and until we understand that, we will continue down the same path with every new technology, platform, and latest and greatest thing that comes down the pike.

You can bank on that.

"Smart Grids Don’t Present Any New Security Threats" (According To At Least One Man's Opinion)

I read an interesting interview on TMCnet this morning. It was an interview with Chris King, who is the Chief Strategy and Regulatory Officer at eMeter. One of the questions he was asked...well, let me just quote it directly:

Q: Don’t smart grids potentially present a major security threat?

A: Smart grids don’t present any new security threats. Utilities have controlled millions of customer-owned air conditioners, water heaters, and other devices for decades with no security breaches. In fact, the technologies being deployed today are more secure than ever.

Hmmm....

I would suggest that Chris King might consider taking a look at NISTIR 7628, Volume 3, Chapter 7.

Let me quote from that specific section:

7.1 Scope

...First, we have identified a number of evident and specific security problems in the Smart Grid that are amenable to and should have open and interoperable solutions but which are not obviously solved by existing standards, de facto standards, or best practices. This list includes only cyber security problems that have some specific relevance to or uniqueness in the Smart Grid. Thus we do not list general cyber security problems such as poor software engineering practices, key management, etc., unless these problems have some unique twist when considered in the context of the Smart Grid. We have continued to add to this list of problems as we came across problems not yet documented...

This chapter then continues on for a bit over 30 more pages (including references) to articulate the specific security issues identified in the Smart Grid (so far). You know, the ones that Chris King essentially says are not there.

Perhaps Chris King has not read NISTIR 7628, or he simply does not agree with more than 400 people who contributed to NISTIR 7628, let alone the plethora of "unofficial" discoveries made by security consultants worldwide. I would strongly suggest that he takes a good hard look at NISTIR 7628 (at least at Volume 3, Chapter 7) and then revisits his last statement.

I am sure he is a very smart person, and perhaps he was misquoted (that can happen). I would love it if he would comment on this.

NISTIR 7628 Is Final...So Now What?

The entire Smart Grid deployment and cyber security world has been waiting for NISTIR 7628 to move from "Draft" status to "Final" status for nearly one and a half years. This magnificent effort, which included over 400 participants from many industries, government agencies, public and private groups, and just plain interested individuals, has culminated in 3 volumes that essentially read like an encyclopedia of cyber security best practices and technical jargon, complete with tables, drawings, and lots of arrows pointing all over the place. It is an impressive compendium of knowledge, and you can get your very own copy by going here.

So what does this all mean to the world of Smart Grid security? Does this make us more secure?

Well, as things stand right now, not exactly.

First of all, let's understand something about NIST and NISTIR 7628. The title is both prescient and potentially misleading. Here is the title for Volume 1:

Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements

Look carefully at the first word and the title and bear in mind that, for all legal intents and purposes that is all that matters. It is a "Guideline". I know it says "Requirements" at the end of the sentence, but understand that NIST does not dictate requirements to anyone who has the authority to enforce anything. The only requirements NIST has any authority over is the requirements NIST sets forth to comply with NIST standards (i.e. there are certain specific requirements that an entity must meet in order to become FIPS certified).

Why do I say this is potentially misleading? Well, because unless an authoritative body passes a rule, law, or mandate of some sort that requires the adoption of all or part of the recommendations in NISTIR 7628, it is nothing more than a magnificent exercise.

The simple existence of Smart Grid security guidelines does not make the Smart Grid more secure. The correct implementation of Smart Grid security standards, however, can.

Yet simply pointing at the NISTIR 7628 and saying "do this" will not suffice. This is because NISTIR 7628 is a collection of NIST standards and recommendations. While this may seem sufficient for some, it is still too open ended to serve as anything close to prescriptive. In fact, NISTIR 7628 is not intended to be prescriptive, and it says so in section 2.2 of Volume 1:

"This list of technologies and services is not intended to be prescriptive; rather, it is to be used as guidance."

This leads to the obvious conclusion that NISTIR 7628 is not intended to serve as "the rulebook", but to assist the rulemakers in writing "the rulebook".

So who are the rulemakers?

Well, that is a good question, and one that is not so easy to answer without first understanding that it all depends on what part of the Smart Grid we are talking about.

To try to simplify this as much as possible, and forgive me if this is oversimplified (or overly complicated as the case may be).

We can break the power Smart Grid into three categories:

1. Generation - Where the power is generated (i.e. the power plant)

2. Transmission - How the power gets from the power plant to the substations that send it to those who use it.

3. Distribution - The part of the organization that the user directly interfaces with (the ones who read your meter and send you a bill and shut off your power if you do not pay your bill).

So Generation and Transmission are generally not considered part of AMI (Advanced Metering Infrastructure). AMI is the part of the Smart Grid where smart meters live. Generation and Transmission currently fall under the jurisdiction of the Federal Government, and are therefore subject to the whims of the Federal Energy Regulatory Commission (FERC) and the North American Electric Reliability Corporation (NERC). NERC is not a Federal agency, but is given authority by FERC to conduct audits, levy fines, and all sorts of interesting stuff that tends to keep utilities in various stages of insomnia and cold sweats.

Distribution, on the other hand, falls under the jurisdiction of the individual States, and consequently the Public Utility Commission (PUC) of a given state.

So what this means is that FERC, NERC, and the State PUC's must now take a long and hard look at NISTIR 7628 (not to say they have not already been doing so) and try to synthesize some specific regulations based upon what is contained in this very verbose 3 volume set. This is no easy task, as one can imagine. Let's examine one particular section, taken from Volume 1:

4.2.1.8 Physical Security Environment

...In determining the appropriate level of physical protections required for a device, it is important to consider both the operating environment and the value and sensitivity of the data protected by the device. Therefore, the specification of cryptographic module physical protections is a management task in which both environmental hazard and data value are taken into consideration. For example, management may conclude that a module protecting low value information and deployed in an environment with physical protections and controls, such as equipment cages, locks, cameras, and security guards, etc., requires no additional physical protections and may be implemented in software executing on a general purpose computer system. However, in the same environment, cryptographic modules protecting high value or sensitive information, such as root keys, may require strong physical security...

If, for example, you are the CPUC (California Public Utility Commission) and are attempting to create a requirement based upon this section for physical protection of cryptographic modules (and the data contained within them), one must first define what "high value or sensitive information is". The root key mentioned is a good example, but what about other information stored on the device? What is the information? Is it also sensitive? Who determines if it is sensitive or not?

If the CPUC then determines that the information stored is not overly sensitive (i.e. not a root key), then it is important to ensure that the scope of the information stored on such modules does not "creep" to a point where it may indeed become sensitive. This is no easy task, because sometimes what is deemed safe today does not always remain safe going forward. A good example of this is a Social Security Number. There was a time when nobody had a problem sharing their Social Security Number with anyone. Heck! In many cases it was your ID number for school, work, military, etc. What happened, however, is that the scope of the Social Security Number expanded, and it was soon discovered that if you knew someone's number you could do all sorts of bad things with it.

If the CPUC determines that the information is indeed sensitive, then they are tasked with determining what standard for protection of such information must serve as a baseline (i.e. FIPS 140-2).

Providing they can accomplish these tasks, they must then determine if and how they are going to audit (and potentially certify) such requirements.

...but first they have to determine what is in scope and what is not in scope, and why. This in and of itself requires the PUC's (and FERC and NERC) to have an intimate understand of what parts of NISTIR 7628 (and potentially other guidelines, such as the excellent work done by the UCAIUG AMI-SEC Task Force, which is specifically credited for their contributions to NISTIR 7628 within Volume 1) apply to their purview. Looking at this at the Federal level, one might conclude that they have enough resources to tackle this task, but having listened to FERC Commissioner Philip Moeller's keynote address at my Smart Grid Cyber Security Summit last month, in which he stated "We don't have all the answers, we need all of you to help.", I am led to believe that we still have a long way to go.

...and it is even more challenging for State PUC's. The CPUC is a fairly well staffed organization, being that California is indeed a very large State. Nonetheless, the CPUC does not currently have anything close to a comprehensive understanding of cyber security. To be fair, why would they? In its many years of existence they have never had to deal with cyber security issues with respect to regulation of utilities, and up until the passage of California SB 17 it has never been their responsibility. However, being staffed with some very intelligent (and diligent) people, and now being responsible for making decisions relating to cyber security and the Smart Grid, the CPUC has indeed taken it upon themselves to rise to the occasion. I have personally attended two public hearings at the CPUC where Smart Grid security was discussed, contributed to requests for comments from the CPUC regarding cyber security, and the CPUC is planning a public hearing to specifically discuss NISTIR 7628 with the NISTIR 7628 team at the CPUC at the end of September, 2010 (currently planned for September 28th and 28th), as well as additional workshops to hash out the details of Smart Grid security.

This is all good stuff!

...but what about other PUC's? Some States (from what I have been told by members of the CPUC) have PUC's that could fit into a small room with plenty of space to spare for filing cabinets, chairs, and tables. In other words, they are woefully understaffed and underfunded. How are they going to manage cyber security?

Well, one answer is contained in one of my favorite sayings "As goes California, so goes The Nation." Their eyes are on California, and what California decides is quite likely to serve as a template for the rest of the nation. Some have also argued that Texas is also serving as a template. While this may be true, I have a sneaking suspicion that California will likely prevail as a trendsetter. Only time will tell, I imagine.

The great news is that there seems to be no shortage of people who are willing to volunteer their time in working through these challenges. It may not be entirely altruistic in nature (hey, everyone wants a piece of the Smart Grid security market pie, including yours truly), but the fact remains that we are indeed well served by some of the great minds working on the effort. PG&E has a cyber security team currently led by CISO Dave Tyson (who came from the security team of eBay) and PG&E has been dealing with Smart Grid security for longer than just about any utility in the world. The UCAIUG AMI-SEC Task Force is still working hard and growing stronger with every meeting (I try to attend and contribute as often as possible). Many AMI vendors are currently specifically dedicating resources to cyber security efforts, and are working together in a spirit of "coopetition", where they cooperatively share information with each other despite being competitors. Anyone who attended my conference is well aware of just how many organizations are involved in this effort, and the list keeps growing.

We still have a lot of work to do, but we have come a long way, and I am not even close to tired yet! NISTIR 7628 is worthy of being celebrated for finally being completed, but now the real work begins.

The Top Level Disconnect

The first Smart Grid Cyber Security Summit has come and gone, and was much more successful than I ever imagined it would be (especially for being the first of its kind). Being the conference chairman, I was thrilled at all the attendees who took the time to come up to me during networking breaks and thank me for holding the conference, and consistently asking me "When are you holding the next one." I was amazed at the attendees who traveled from Europe and Asia, and all the government defense contractors, AMI vendor security specialists, utility representatives, consultants, members of the media, and FERC Commissioner Moeller...all who came to take part in what many felt was a fantastic opportunity for stakeholders at many levels of the Smart Grid security ecosystem.

What struck me as interesting, however, was a point that was raised by Dr. Fred Cohen, who delivered the keynote address on the 2nd day of the conference. His presentation focused on the lack of (and need for) security expertise in the ever expanding cyber world, and some proposed solutions (which included a bit of self promotion, since Dr. Cohen is currently operating a school specializing in security related academics). Something he said struck a chord in me, and while I have been aware of the situation for quite some time, I have been pondering it quite a bit the last several days. What Dr. Cohen did was posed a question to the audience, asking how many attendees were CEO's (or top level executives) of either AMI vendor organizations or utilities. Nobody raised their hand (and, in fact, nobody at that level signed up to attend the conference), and Dr. Cohen proceeded to point out that until management at that level takes an active role in dealing with security, we will continue to witness a shortfall in security.

Okay, in all fairness this was the first Smart Grid Cyber Security Summit, and CEO's are busy people, and who the heck am I anyhow? Yet his point still rings true in the security world.

The fact is that CEO's simply do not participate in the cyber security ecosystem at any appreciable level, and that leads to the obvious question "Why should they?"

In a word...MONEY!

A CEO's job, after all, is to make sure the organization's income level goes up and the amount of money leaving the company does not go up faster than what is coming in. That is the essence of what being a successful CEO is all about. If the company is publicly traded, then it is all about keeping the stock price from falling. No matter what anyone tells you, that is the name of the game, and always has been, and always will be.

So that brings us back to security. One of the most difficult expenditures to justify to a CEO is the cost of security. Trying to demonstrate a return on investment for security is next to impossible. Security is simply not considered a feature a customer is willing to pay for. Rather, it is something that customers expect to be part of "the package". Customers of AMI vendors, for example, want a decent meter at a low price that also happens to be secure because there are enough people "out there" making enough noise about Smart Grid security to get their attention. This noise includes the government, bloggers, the media, security "hobbyists", security professionals, and privacy proponents...to name just a few. While this may be enough to get the attention of decision makers, it is generally not enough to get decision makers to dedicate any more resources than necessary to divert the attention from their organizations to someone else's. If a top level decision maker believes the attention is (or may) negatively impact the bottom line, more resources are generally expended. Now I have to say that I may be painting the corporate world with a very broad brush, and I am sure that there are some high level executives that want to do the right thing because it is the right thing to do, but their ultimate survival depends on keeping the company cash flow positive and profitable. Stockholders simply do not reward any other behavior.

...and security can be very expensive. It is especially expensive if it is poorly done, and really amounts to a waste of time and money in such cases. If it is not part of the design, it can mean lost revenues due to customers going to a competitor, or it can amount to outright devastating losses in the event of a serious malicious attack. Imagine an AMI vendor that installs 20 million meters and it is later determined that the meters are vulnerable to a very serious security related threat that requires an outright replacement of meters. I am not talking about something theoretical, but rather a vulnerability that turns into a real world exploit. An attacker does not need to, for example, shut down power to millions of people in order for the exploit to prove effective. A few thousand is plenty (maybe even less). It does not take a massive failure of all systems to negatively impact the reputation (and market cap) of a company.

Just look at what happened to both Toyota and BP. It only took a few failures for Toyota to lose billions in market cap, and 1 major failure for BP to lose so much market cap that it dramatically impacted the retirement accounts of millions of British citizens. If a major publicly traded utility should become the victim of such unfortunate circumstances, what potential economic impact could this translate to? The answer is really a big unknown.

It seems prudent, at this point, for CEO's (and other top level executives) of organizations involved in the Smart Grid to become a bit more involved in actively participating in the world of Smart Grid security. One utility representative at the conference mentioned that the high level executives literally pour money into security when they discover that they are about to be audited by NERC, but other times are not so willing to open the coffers. This really does not make sense, and is not indicative of due diligence. If high level executives had a better understanding of the ecosystem, and the concerns of stakeholders, and the dynamic environment surrounding Smart Grid security, then they could make better and more informed decisions on where and how to dedicate resources. It comes down to being proactive rather than reactive.

I am planning to hold another Smart Grid Cyber Security Summit in the near future. I will make sure to reach out to the CEO's of utilities, AMI vendors, and other stakeholder organizations involved in building the Smart Grid. I am hoping they will view this as an opportunity to become part of the solution.

...because otherwise they may indeed be part of the problem.

The Importance of Trusted Relationships

As a security professional, I have had the opportunity to work with many different companies in the ever expanding world of security. Some of these companies have been very large (multi-billion dollar companies), and other have been quite small. The larger companies have the dubious distinction of being able to pour enormous amounts of marketing dollars into convincing the world that they are at the leading edge with respect to security. Unfortunately, this is absolutely no indicator whatsoever of the security posture of a company. In fact, as I have discovered on more than one occasion, some companies will opt to spend enormous amounts of money on everything EXCEPT building better security, hoping to convince their potential customers that they are the right choice to go with.

I think it is no big secret that many corporations seem to have no problem "embellishing" when it comes to the information they choose to share with the world. We have all seen enough of this at this point in our lives to know it is "just the way it is" in the world of business. We simply accept the fact that some companies choose to create their own versions of reality, and make choices to do business with them despite what we may believe about them. For example, we may not believe that an oil company is as committed to safety or environmental soundness as their public relations department may say they are, but we still choose to buy their petroleum products.

The fact is, most of us are not overly concerned about an oil company's safety record or what they are doing to make our environment better when we purchase fuel. If an company does not have a good safety record or destroys our environment we simply do not make the connection between that and our lives when we are at the fuel pump. We have other things on our minds.

With other products, it is perhaps a bit different. If a company that produces food or drugs is found to be acting in a scandalous manner, we tend to become a bit more nervous (perhaps more with drugs than food). Finding out that a drug company is being run by a bunch of corrupt and non-trustworthy people may indeed be cause for concern (at least it would be with me). At a more granular level, finding out that my personal physician is seedy lowlife would certainly make me ask my HMO to provide me with a new doctor. The fact is that when we are forced to trust our lives to a company or person, we want to make sure we are dealing with PEOPLE who can be counted on.

You see, dear reader, an organization is portrayed as being an entity (i.e. a corporation), but we all know that the organization is ultimately a collection of people. Despite the attempt by such organizations to make it about the entity, it is always the people who make or break it.

This certainly holds true in the world of security. When it comes to security products (i.e. security hardware), there are many companies to choose from. In fact, most of the security hardware available today (such as security chips) have become a commodity. When I speak to vendors of AMI (Smart Grid) products, or to organizations interested in implementing security products in health care organizations, one of the first questions that comes up is "How stable and reliable is the company making the security products?".

Organization who are making decisions about security products are transitioning from those who simply wanted to look like they were doing something to ones who are expending resources on products and services that do what they are supposed to do. This is largely driven by the nearly insatiable appetite the hacking community seems to have for breaking down security systems. When I present a security product line to a company, they ask a lot of questions. This is a welcome departure from several years back, when a company simply asked us what they could buy that fit within a given budget. Today, they want to be sure they are making the right decision for the long haul.

What I have found is that is seems to be very important that the organizations making security decisions trust the organizations they do business with at a much deeper level than ever before. I have intimate one-on-one discussions with security professionals and decision makers in companies who literally want my opinion of the companies I represent. They ask questions like "Do you think these guys are going to be around a while?" and "Are they trustworthy?" and "How do you find them compared to Company B?".

While remaining as tactful as I can, I always tell the truth, because these days most people I speak to in the security world VERIFY what I tell them. I know this because on more than one occasion I have had them return to me and say "I checked out what you said, and found out it was true." At first, I was taken aback by this (at least momentarily), but now I find it absolutely refreshing. In fact, sometimes I take the time to send citations for the claims I make, in order to make it easier for them to verify what I tell them.

You see, ultimately security is built on trust. The character of the people who make up an organization is as important (if not more important) as the products they build. Once I begin questioning the integrity of the people who make up the team of a security organization, I question the stability of the company, and ultimately the products they build. Anyone can build a security product line, given the right resources. However, it is only companies with integrity can build a security product line they can stand behind, and no matter how big or small the company may be, that is what I believe everyone should look for, and it always starts with the people.

Sorry Health Care...Game Over!

Back in the day when pinball machines were all the rage at game arcades (and the only video game was pong), one could bear witness to a room full of pre-pubescent boys and girls (mostly boys as I recall) pumping quarters into machines and batting steel balls with rubber coated "flippers" in order to prevent the ball from falling into the shoot. The longer you could keep batting that ball the more points you would score. If you were particularly well versed in the art of pinball machines you could shake and tilt the machine to a degree (avoiding the inevitable "tilt" caused by being over-zealous) and perhaps score more points by making the ball move where you wanted it to move.

Nonetheless, this mastery of batting the ball and shaking and gyrating the machine came to an end for even the most skilled of pinball wizards. Many players would continue to shake and gyrate the machine after their last steel ball (back than you got at least 3 balls) had fallen, but there was simply no denying the reality of what the scoreboard prominently displayed in bold letters...GAME OVER !

Sure, those with paper routes or other sources of quarters could keep pumping legal tender into the system to give it another go around, but the result was inevitably the same. Eventually you have to give into reality. You can't bat the ball around forever.

The idea of health care organizations having to take responsibility for security and privacy in an ever expanding digital age is certainly not new. The first HIPAA regulations passed in 1996. I am no math genius, but that is about 14 years by my calculations. In 14 years, however, health care organizations and providers have been lax in dealing with security. I currently serve on the CalPSAB security steering committee, and that seems to be something we all agree on (actually, we seem to agree on a lot more than that). Having just returned from the Safeguarding Health Information: Building Assurance through HIPAA Security conference in Washington DC, it seems quite clear that the Office of Civil Rights (OCR) and Federal Trade Commission (FTC) are also aware that a lack of due diligence on the part of health care practitioners (and business associates) with respect to security and privacy has gone on long enough.

Nonetheless, we still see organizations (such as The American Medical Association, American Osteopathic Association and Medical Society of the District of Columbia) fishing for more quarters to pump into the machine.

Hey! Why not? They have plenty.

In an article published on the excellent Health Data Management Blog, the author references a lawsuit filed by the aforementioned entities. The essence of the lawsuit is that health care organizations do not want to fall under the authority of the FTC with respect to the "Red Flags" rule the FTC currently requires creditors to abide by. The (ridiculous) claim being made by the filers of the lawsuit is that (from the article):

Among other factors, the medical associations argue that physicians are not commonly referred to as "creditors," nor are patients ordinarily thought of as "account holders" or "customers."

Wow! Am I understanding this correctly? This is coming down to a definition of what a "creditor" or "customer" is?

At the Washington DC meeting one of my takeaways was that OCR is really putting the hammer down, and perhaps they should consider less "stick" and more "carrot" in dealing with organizations that have to comply with the rules. However, when I witness the equivalent of a bunch of pinball wizards banging on a machine as they fish for more chances to avoid the inevitability of owning up to the fact that batting balls around eventually loses its charm, I shed some of my sympathy.

The Health Care Industry simply cannot keep playing this game forever. It is time to focus their energy on ways to address security and privacy concerns in a meaningful way, and stop fighting what is inevitable.

GAME OVER!