By Paul Kearney, Chief Security Researcher, BT Innovate & Design

This article continues a discussion of how to create cost-effective compliance based on a talk I gave at last year’s Information Security Forum World Congress in Berlin. The first instalment outlined the challenges, and the second considered how to judge how much you should be spending on security. But to be cost-effective, first you need to be effective, so now we turn to issues of measuring and managing compliance.  The ideas outlined here draw upon work done in MASTER, a three-year European collaborative research project I participate in, which ended in February 2011.

Compliance is about ensuring that you fulfil your commitments and providing evidence that you are doing so. These commitments can be mandatory (e.g. imposed by legislation), voluntary (e.g. abiding by industry guidelines or standards), contractual, or internal (e.g. policy decisions). Whatever the source, you can only really talk about compliance if you are able to measure or otherwise assess your success in fulfilling the relevant commitments. A first step towards this is to express the commitments in a form that can be tested practically against observation.

In MASTER, we called this testable form of commitment a Control Objective. The test for fulfilment of a Control Objective is expressed in terms of patterns of observable events, such as might be emitted by various IT systems and stored in log files. As an example, consider a policy that states only authorised users may access certain services. This could be rewritten as a Control Objective, requiring that every access event must be preceded by a successful authorisation check with the interval between the two being no longer than, say, 30 minutes.

A related MASTER concept is the Key Assurance Indicator (KAI), a performance measure expressed in terms of Control Objective violations or fulfilment. In our authorisation example, an appropriate KAI might be the proportion of access events not preceded by a corresponding authorisation event, weighted by a factor reflecting the sensitivity of the service. Notice that a KAI of this form is effectively an operational measure of risk.

Typically, one or more thresholds will be associated with KAIs, indicating degrees of acceptability of violation. Although you might expect that only 100-percent compliance is acceptable, this is not necessarily the case. Consider, for example, a healthcare context where taking short cuts through normal procedures is tolerated in emergency situations. Also, logging may be less than perfect, manual alternative procedures may be available, and so on.

In addition to measuring compliance, we should take steps to prevent non-compliance and to limit its impact. In MASTER, we do this by defining Control Processes. Again, patterns of events play an important role. A Control Process enforcing a policy will typically be triggered by an event pattern indicating that opportunity for violation is approaching, while processes triggered by actual violations can be used to limit their consequences. For example, an access request without a preceding confirmation of authorisation could be used to trigger an authorisation check with access being blocked in the meanwhile. Similarly, an ‘emergency override’ of denied access could trigger a message to a supervisor who could investigate later to make sure it was justified.

Control Processes also give rise to events that can be monitored, and we can define patterns that we would expect to see during and as a result of correct execution of a Control Process. We can use these to construct a second type of indicator, the Key Security Indicator (KSI), that is a measure of whether the Control Processes are functioning as designed. KAIs and KSI can be compared to determine whether a compliance problem is due to incorrectly designed, implemented or operated controls, or because, for example, an important threat vector has been overlooked.

Documenting the Control Objectives, KAIs, Control Processes and KSIs, and also the relationships between them and rationale for their choice, allows an auditor to assess whether controls and indicators have been chosen appropriately to the business context. Evaluating the KAIs and KSIs during operation provides evidence that the controls are working effectively in practice and that commitments are being fulfilled. Where this is not entirely the case, the information can be fed back as part of a continuous improvement process.

In addition to defining the concepts outlined above, the MASTER project produced a Methodology Handbook, a prototype Design and Verification Workbench, and a prototype run-time infrastructure consisting of Signalling, Monitoring, Enforcement, and Assessment components. Control Processes and indicators defined using the workbench can be published to the run-time infrastructure via a repository.

The results were demonstrated and assessed by means of two case studies in the healthcare and financial services domains. The healthcare study concerned compliance of a hospital drug prescription and dispensation business process with Italian regional regulations. The second study dealt with compliance of a credit rating evaluation business process with Spanish national regulations.

While the various software tools developed are still at a research prototype stage, we believe the fundamental approach has proved to be sound. There is interest in applying the methodology in practice, and the project partners are incorporating the technical developments in various software products.

In order to be PCI compliant It is required that customers scan their networks quarterly and for their external presence to be scanned by an Authorized Scanning Vendor program (ASV).

In 2011 the PCI Council changed the ASV program significantly. ASVs have always been required to conduct network security scanning against a test network with predefined vulnerabilities operated and configured by the PCI SSC. ASVs are expected to produce a sample report and document all of the predefined vulnerabilities.

Authorized scanning vendors were, however, criticized for not always understanding their role or being able to advise their customers appropriately, especially in the scoping arena and on how to best identify and eliminate false positives.

So, last March the PCI SSC changed the program to require that ASVs have at least two qualified ASV employees who have done the online training program and passed a multiple choice exam. The training program ensures that the authorized personnel doing the scan are not only able to do the scan but understand the PCI DSS standards and are able to act as a trusted advisor to the customer in the area of vulnerability management, much like QSA act within the security control audits.

The objective is to bring a consistent understanding on how to evaluate network segmentation and really understand the requirements of the standard. ASV organizations are also required to have a quality assurance process in place to ensure that the reports produced, and the analysis of the results, are consistent and accurate.

The requirement for a QA program to be in place has been a requirement for QSA organizations for some time. The scan customer is ultimately responsible for defining the appropriate scope of the external vulnerability scan and must provide all Internet-facing IP Addresses and/or ranges to the ASV. If an account data compromise occurs via an externally facing system component not included in the scan, the scan customer is responsible. It is critical to work with an ASV that works as a trusted advisor, scoping is a critical components in being compliant and often merchants are confused about which systems are in scope for external scans. The ASV should be able to advise on not only which systems are in scope but also how to handle anomalies and systems that are failing the scan.

Organizations that are not guided by PCI but are conducting vulnerability scans as part of best practices or other regulatory requirements would be well advised to use the ASV certification as a method of being able to select a good scanning vendor. The fact that the vendor has passed exams, has qualified staff on board and has a QA process in house and this has been validated makes a great screening process and is a definite indicator that the organization would meet the needs of any organizations concerned about vulnerability management.

This was the first time SIG topics were chosen through member elections. Close to 500 votes were cast by merchants, financial institutions, service providers and associations for the initiatives they want to prioritize in 2012. According to the PCI Security Council, a quarter of all Participating Organizations voted, which shows a high amount of interest. A third of the votes came from outside North America, which showed that concern surrounding how to secure the payment chain is truly a global endeavor. SIGs focus on providing recommendations to the Council which often results in guidance for interpreting and implementing the PCI Standards. The SIGS are not about creating new versions of the standard but, rather, clarifying existing controls and how they apply to specific technologies.

Any member of the PCI SSC community interested in participating in one of these SIG projects needed to indicate their interest by emailing sigs@pcisecuritystandards.org before November 30, 2011. However, the council has welcomed late comers. The Council SIG leads are now convening each group to formalize the group charter and precise scope of work project. This will be shared with the Community by the end of the year,  and all the SIGs now have started to meet.

The Cloud SIG no doubt will focus on the different responsibilities for companies that choose to use cloud-based security. The standards have begun to give consideration to virtualized environments with the release of the guidelines released last year. However, the standard currently does not clearly guide QSAs or those involved in the payment process with some of the more specialized threats that exist in cloud environments, including division of responsibilities, forensics, and the complexity understanding the law in distributed environment.

The e-commerce security group should cover some of the issues specifically around e-commerce for Level 3 and 4 merchants, including issues such as detailed guidance on how best to implement hosted order pages, shopping carts, and dedicated payment workstations.

Requirement 12.1.2 emphasizes the need for a formal and structured risk assessment methodology and calls out examples such as OCTAVe and ISO 27005. The need for a formal risk assessment methodology also has been moved to milestone 1 in the new prioritized approach, which shows the criticality that the Security Council regards this control. This is the group that I am most interested in as traditionally risk assessments in IT have been lacking in consistency and yet they under pin the selection of every single control and priority. The risk assessment SIG is not about to turn PCI DSS into a risk-based standard as the standard by its nature is a defined set of requirements. The standard, however, does require a risk assessment methodology and specifically within patching that the standard requires that organizations follow a risk-based methodology.

The SIGS, unlike previous incarnations, run for a defined period of one year, and the results should be available this time next year.

Mobile payment technologies have been around for quite some time and yet it has never really burst into common place use…until now.

In 2012, I suspect that mobile payments will be more commonly used in theU.S. as many of the major technology players are putting on their gloves and getting ready to duke it out to be a leader in this market.   It will be fascinating to see who comes out on top.

TheBattle: Google vs. Apple vs. PayPal

One of the major contenders is Google.  The Google Wallet uses Near Field Communication (NFC) with special NFC capable point-of-sales (POS) device and phones. NFC allows for data exchange and wireless connections which are in close proximity to each other. The NFC forum that consists of 130 countries and many large organizations control the specifications, which is also an ISO standard ISO/IEC 18092.  Currently only the Nexus S 4G supports Google Wallet, but next year should welcome a host of new Google Wallet-enabled devices.

The sheer size and weight of Google may enable the collaboration of card issuers, mobile device manufacturers and merchants.New Yorkyellow cabs already accept Google Wallet, enabling riders to pay fares with any enabled technology. OfficeMax also upgraded over 100 of its stores to support Google Wallet and SingleTap, which provides payment and automatic location of coupons.

Apple is the other contender in the market.  The iPhone 4S does not support NFC and there has been no word from Apple on what future models may support.  However, Apple has already dipped its toe into mobile payments.  As part of its upgrade to the Apple Store app, the company introduced a new service called EasyPay. This service lets a user look up information about a product based on the barcode and then charge the product to his or her iTunes account. At the moment, EasyPay is extremely restricted; it only works in theU.S.and only in Apple stores and does not include the purchase of big ticket items. However fascinating because it makes iTunes a payment vehicle and really displays how consumers expect mobile payments to function.

PayPal Mobile announced a 511% increase in global payment volume compared to Thanksgiving 2010. Consumers have wholeheartedly embraced mobile shopping this year with iPhones generating the majority of the traffic and Androids not being far behind. PayPal is working hard to maintain its position as a payment processor and to being a big player in the mobile arena.

PayPal has an in-store mobile payment system that does not require NFC technology. The system allows shoppers to scan bar codes and to authorize payment through their PayPal mobile accounts. The benefit, of course, is vendors do not have to replace their POS and consumers do not need to replace their phones.

But it is not just the big players that are hedging bets on the adoption of mobile payments.  There are also third-party vendors specializing in payment who are in this space. Square’s card case promises to let customers pay by having their smartphone in their pocket. It functions using GPS-style technology and appeals in part to the market move towards instant deals. The service provides merchants with a wealth of information on the consumer and encourages transparent spending for consumers.

Creating a tie-in between payment choices, location-based service, deal-of-the-day vendors and adding enhancements to loyalty programs and coupons is really what mobile payments are about. It is stretching the phone past just being a payment choice, it is about making the consumer experience different. Companies that invest in these technologies have a far better chance of surviving the challenging economic times ahead by wooing the consumer in every way possible.

By Paul Kearney, Chief Security Researcher, BT Innovate & Design

In the first installment of this blog post, I commented on the major challenges public and private sector organizations are facing in complying with security-related standards and regulations. I cited a 2011 survey by Ponemon, which reports that the average cost of compliance is more than £2 million, but the cost of non-compliance is almost £6 million. Studying the results of the survey led me to some interesting observations about the economics of security that I would like to share before moving on to describe our work towards a methodological framework and accompanying software toolset in a subsequent posting.

Forty-six organizations in a variety of sizes and market sectors responded to the Ponemon survey, providing figures on what they are spending on compliance programs and what they are losing due to compliance failures. The majority of the latter costs related to the impact of security breaches – business disruption, lost productivity and revenue, etc. – rather than fines and penalties. Most organizations spent much less on compliance than they lost, though in six cases the amounts were roughly equal, so there is certainly scope to reduce losses by increasing spend.

The study authors also calculated Security Effectiveness Scores for the participating organizations. As expected, they found that high security effectiveness correlated well with low per capita losses. Interestingly, security effectiveness was not correlated with per capita spend. Taken together, these suggest that compliance budgets are not always spent wisely and that adopting the risk governance principles required by standards and legislation is more important than checking boxes.

So, what is the right amount for an organization to spend on compliance?

Economic theory would suggest trying to minimize total costs, i.e. the sum of spend and losses. We would expect losses to decrease as we spend more on security, rapidly at first, but with diminishing returns, so that eventually additional spend outweighs incremental benefits and total costs begin to rise. There will be an optimal point where a pound of additional compliance spend yields a pound of reduced losses. Where this sweet spot occurs depends on the shape of the curve relating security spend to losses.

I was reminded of a conversation with a colleague who works in risk management. He had sketched a graph with axes of security risk and spend, with points plotted on it corresponding to different risks. He had speculated that you could draw a straight line through the origin of this graph dividing the risks on which too much was being spent from those to which more budget should be allocated. Having been a theoretical physicist in the past, I leapt for my pencil and paper and soon satisfied myself that there was indeed a simple mathematical function relating risk to cost that ‘looked right’ and for which the optimal solution for spend is a straight line through the origin. The function I found was characterised by a single free parameter that I imaginatively name “k”.

If my function is on the right lines, choosing a value for “k” would enable you to estimate your optimal security spend and, indeed, to work out which of the Ponemon respondents (if any) had got it right. I am not claiming my function is correct. Furthermore it is quite likely that different types of organizations would be characterized by different values of “k.” Nevertheless, it would be interesting to use it as an analytical lens through which to view risk estimates or security control cost-effectiveness figures.

Regardless of absolute correctness, the equation can be used to get an intuitive feel for the dynamics of security economics. For example, a risk frontier separating acceptable from unacceptable levels of risk appears as a horizontal line on the graph. Varying the security spend up or down allows you to move your risk point along a curved trajectory from top-left to bottom-right on the plot. If this trajectory crosses the optimal line at a point above the risk frontier, then you are only going to mitigate the risk by spending over the odds on controls.

What we would all like to do, of course, is to maneuver our risks at right angles to this trajectory, decreasing spend and risk simultaneously. To do this, you need to change the value of “k” governing the trajectory, which means working smarter rather than harder and changing the type of controls you are using.

Following this little diversion into the economics of risk, security and compliance, I will return the trajectory of this article to its originally intended path. In the next instalment, I’ll discuss the importance of closing the loop linking policy to selection and deployment of controls by measuring the operational effectiveness of the controls and using the results to update policy. I’ll then outline the results of a project I’ve been part of recently that addressed such issues. However, that’s a topic for another day.

The PCI Security Standards Council’s (PCI SSC) Special Interest Groups (SIG’s) leverage PCI SSC Participating Organizations’ (PO) valuable business and technical experiences, to collaborate with the PCI SSC on any supporting guidance or special projects relating to the PCI Security Standards.

A SIG’s objective is to recommend clarifications to the PCI Standards and the programs that support them. To-date, the SIG collaboration and PO participation has resulted in the following guidance:

• Wireless
• Virtualization
• PCI DSS Applicability in an EMV Environment v1.0
• Initial Roadmap: Point-to-Point Encryption Technology and PCI DSS Compliance v1.0

Any Participating Organization (PO), Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV) is invited to propose a Special Interest Group during an open proposal period that runs annually between July 1 and August 29. The topics are gathered and a short list is discussed at the PCI SSC annual convention.

The idea behind the development of SIGs is interesting. It involves parties that are impacted by PCI DSS but don’t have a direct relationship to the Council and allows them to provide industry expertise in specialized areas.

But is this really effective?

It is interesting to note that the SSC recently has made a structural change to the SIGs so that a PCI SSC representative will chair, lead and project manage SIG work. Undoubtedly this is aimed at ensuring the large SIGs stay on target and “everyone plays nice”.  The SIGs also will only run for a year, whereas in the past a SIG ran for was undetermined and the virtualization SIG ran for 28 months. The challenge for SIGs, which are often comprised of vendors, is to provide knowledge and guidance in a non-product specific manner that is unbiased.

The question becomes can the information collated by these large groups actually state more than what is absolutely obvious.

It would seem that the guidance released has come up with a few surprises and has not simply stated the self-evident. The Tokenization SIG calling out high-value tokens and the fact that these will not reduce scope came as a surprise to quite a few organizations. The Virtualization SIG,  however, seemed to produce more mundane guidelines perhaps because the technology is better understood and really seemed not to have any surprises in their guidance. The appendix in the guidelines produced by the virtualization SIG has advise on a control by control basis was originally meant to be a spreadsheet for QSA’s which would have been exceedingly useful however for unspecified reasons this was changed to a PDF with much more generic advise. The pre authentication and the scoping SIG never released any findings at all which is very disappointing for members but also those volunteers that participated in the SIG.

The guidance itself is a clarification and not meant to introduce new controls so bringing real value whilst clearly staying within the requirements of the standard can also be challenging.

This week, presentations from PO’s, QSA’s and ASV’s on shortlisted SIG proposals will be given at the North American and European Community Meetings. Following this Participating Organizations will be asked to electronically vote on which proposals to move ahead with. Only three SIGs will be selected this year and the current seven shortlisted proposed areas of clarification vary from cloud to payment gateways.

It will be fascinating to see what areas are chosen as the focus areas for the year ahead and with the SIGs being chaired by a member of the SSC one wonder if the outcomes may move more towards more tangible advice.

The PCI DSS’ release of the long-awaited tokenization guidelines seems to have been well received but it has also raised some questions.  With varied types of tokenization, merchants need to understand how each type works and which solution is best for their particular environment.

Initially, the document outlines the use of tokens and its function.  Tokens are defined as a surrogate value which is used in place of the primary account number (PAN). The function of tokenization is to reduce the scope of PCI DSS ensuring fewer systems come into contact with the PAN.

The guidelines further reinforce that you cannot store sensitive data sensitive authentication data (including magnetic stripe data or equivalent on a chip, CAV2 / CVC2 / CVV2 / CID data, and PINs/PIN blocks) even if they are tokenized. The focus of any tokenization system is to ensure that tokens have no value so that the scope of the systems impacted by PCI DSS is reduced.

Interestingly, the guidelines broaden the discussion of tokenization to specifically mention high-value tokens. Many of the special interest group (SIG) members found issue with this addition from the Council, stating that it caused confusion about scope reduction.

High-value tokens allow you to conduct a financial transaction using just the token and not the PAN. If the token is able to be used to conduct any kind of transaction then it is functioning like a PAN and is therefore subject to any of the same restrictions as a PAN. Merchants sometimes use tokens as a mechanism to enable one click transactions and these high-value tokens are of value to any hacker and therefore do not reduce the scope of PCI DSS.

The other danger within tokenization is back channels, channels that allow the merchant to access the original PAN. This may commonly arise in loyalty schemes or merchandise returns.

So before you get started on evaluating tokenization solutions, it is important to keep a few things in mind. 

• Clearly articulate the plan: the goal of tokenization must be defined and you must understand that tokens need to be used as surrogate data and must have no value in themselves.
• Understand the channels: clearly draw a dataflow diagram with PAN entry and exit points, along with what possible triggers there are for detokenization. Monitoring for any detokenization activity is crucial to understanding if there are any hidden channels.
• Control the access points: any access to the token repository should be tightly controlled and closely monitored.
• Hide the PAN: there must be no way of being able to derive the PAN from the token. The token must be generated in such a way that access to the token does not in any way allow the PAN to be derived. This really will be the focal point of any form of attack; if there is a possibility of deriving PAN from tokens then the entire system will be easily compromised.
• Monitor, Monitor, Monitor: As with any new technologies, a good monitoring solution is critical to ensure that the solution is functioning as designed and undoubtedly will be one of the focus points of QSA’s as they learn to work with the new technology.

Clearly the loudest message to be heard in the guidelines is that not all tokens are equal.   They can range from high-value tokens to encrypted PANs and a merchant must determine which solution best fits their needs and then properly put the controls in place to secure the system.

ISF Annual World Congress is just around the corner. It is an opportunity to exchange ideas and discuss the challenges of the key information security issues that we all face around the globe.

This year I’ll be discussing how public and private sector organizations are facing an escalating challenge in achieving compliance with the number of mandates and requirements that exists.

Most multi-national corporations are struggling to keep up. They are faced with a range of regulations and standards that are recommended or mandated by various groups in different regions.  And they need to demonstrate effective corporate governance and accountability to shareholders or the equivalent dictates that security policies that are in line with the prevailing threat environment and risk appetite must be established and enforced, and their performance and effectiveness monitored.

In a security context, compliance involves ensuring that the ‘in scope’ aspects of the organization’s processes, infrastructure and human and technical resources satisfy the various confidentiality, integrity and availability requirements while continuing to perform their functional role effectively. Where the risk of failing to meet the requirements is too high, controls must be introduced to mitigate the risk.

Compliance is the process of ensuring that the right controls are in place to ensure that this is the case and providing evidence to satisfy the various internal and external stakeholders. This evidence typically includes documentation showing that the controls used derive logically from the requirements and threat models, that they are deployed and functioning as designed and that operational measurements confirm the requirements are met.

The fact is that failure of compliance it too high.  A 2011 survey by Ponemon reports that the average cost of compliance is more than £2 million, but the cost of non-compliance is almost £6 million. While compliance programs are expensive in time, money and effort, the benefits are substantial.

Its been reported by Ovum and others that the costs of Governance, Risk & Compliance GRC programs are increasing as legislation becomes more demanding. Not only this, but the evolving threat environment and increasing pace of innovation mean that controls and compliance must be continually reviewed.

So, enterprises are faced with the considerable challenge of reducing the costs and resources consumed by compliance programs while increasing control sophistication and review frequency.

In my next post, I will present a methodological framework and accompanying software toolset addressing this challenge, drawing on the results of internal and collaborative research projects.

In my earlier post on healthcare breach notification, I discussed the impact of breach notification laws on the industry and more specifically, HITECH and the fiscal implications. 

But one could argue that this has freed the industry from the shackles of having to do security the government’s way and implement security that is more in-line with their unique environment. It’s less about having a control because regulation demands it, and becoming more about a control that has a meaningful role in the protection of private information.

So what should the healthcare industry be doing now?

First, recognize that although regulatory oversight on security controls remain in some form, implementations moving forward must directly relate to the protection of private information in your unique environment. In other words, focus on what works best for your company’s structure, organization, and infrastructure.   Second, understand what constitutes a breach. The term breach – its meaning – is now different. Avoid confusion with traditional security definitions and recognize this term is specific and plan accordingly. There are conditions where private information is exposed but not considered a breach as defined by law.  Below are some additional thoughts:

• Build it and Test it: build a comprehensive incident response capability and test it regularly. Develop scenario-based testing methods and, more importantly, focus efforts on learning from the scenarios for improvement, not simply the scenario itself.
• Visualize the Network: Identity management will become increasingly important, but not simply just for access control and authorization. It will provide the much needed and important visibility into who is accessing what and when. Secondarily, the management of passwords, policies, clear governance of moves, adds, and changes and the employment of two-factor authentication will require on-going tenacity.
• Monitor, Monitor, Monitor: Security monitoring will become paramount, and to be crystal clear, this is not an option. More importantly, be very astute to the scope of your monitoring capability. Don’t just monitor firewalls and IDS. Although important, monitoring applications, servers, switches, routers, databases, and the like will broaden the spectrum of available information helping to quickly discover nefarious activity, which is especially important with the existence of today’s advanced persistent threats (APT).
• Encryption is your best friend: However, there are two things you must come to grips with. First and foremost, key management. Do not become complacent with key management and place intense focus on creating a well-defined model. Failure to cover your bases will undermine the control and therefore become a liability in the courts. Secondly, with increasing complexity of computing systems and cloud models, you must be aware of encryption demarcation in information processing. For example, although you’ve implemented encryption in your SAN, this does not free you from encryption up and down stream, such as backup in the rears, or transport security, web-services encryption, database encryption, and transaction protection.
• Get to the End: End-point security has always been important, but with evolving regulation combined with the rapid adoption of mobility substantiated by more mobile-capable business applications, this represents one of the more significant challenges. Regardless of your current strategy and business position concerning mobility and end-point security, this is something that must be addressed.
• Make it Legal: Finally, security organizations need to collaborate regularly with the legal department. Gain clarity on liabilities, responsibilities, jurisdictions, and case law so that you can better protect your company. Of course, build similar relationships with audit. Overall message, don’t go this alone.

For better or for worse, the healthcare community and their partners, providers, and vendors were put in the dubious position to be the first sector to have to address comprehensive breach notification. While they were the first sector, they won’t be the last.  There is no avoiding this and eventually, other sectors will also face comprehensive breach notification.  My advice:  start developing a strategic plan now.  By doing so you ensure that current and future projects in security will provide equity to the business as the breach notification wave crests for your industry.

In February 2002, California enacted SB-1386, a law requiring companies to disclose security breaches affecting the privacy of their customers. Although other, distantly similar conditions existed in EU privacy laws and with GLBA in the US reaching back to the late 90’s, few predicted that SB-1386 would become the catalyst for the massive wave of breach notification laws we see today.

The most noteworthy occurred within days of President Obama entering into office when he signed the American Recovery and Reinvestment Act (ARRA) of 2009. Tucked beneath the mountain of legalese was Title XIII Health Information Technology, or more commonly known as the Health Information Technology for Economic and Clinical Health Act (HITECH), a relatively small section that has changed everything.

In short, HITECH is a breach notification law that has now been integrated into HIPAA. Among its many proclamations, it forces the healthcare industry to reissue Business Associate Agreement’s (BAA) with all their business partners and providers to specifically address breaches. By doing so, any organization coming in contact with protected healthcare information is responsible, and liable. It ultimately gives teeth to HIPAA.

Now, the healthcare industry, which had just reached a point where HIPAA was fully integrated and manageable, is faced with a new challenge.  It is no longer enough to protect data, now the industry must have assurance, solid event detection capabilities, well-defined incident response, and, of course, notification processes.  Moreover, healthcare vendors, partners, and providers are now faced with meetings these expectations or risk losing their healthcare customers.

Breach notification has created an interesting dynamic and represents a shift in regulatory strategy. The shift in government is the redirection from protective and preventative measures to response measures. Essentially, they are setting the penalties and fines in the event of a breach as opposed to the specific controls to avoid such catastrophes. The government is simply saying, “Your controls are not as effective as we’d hoped or intended. Therefore, we are focusing on the fall out with hopes that will encourage better controls.”

This change in strategy is resonating throughout the healthcare industry in a fascinating way. Prior to HITECH organizations were provided security control expectations to achieve compliance. Unfortunately, compliance does not always equal security, but based on how the industry was regulated, compliance was of superior importance, and understandably so.

However, now armed with clarity on the fiscal impacts of a breach, organizations are more interested in meaningful security controls as opposed to simply what is expected of a compliance audit. 

In my next post, I’ll discuss the best practices that healthcare organizations are putting in place to address the unique environment that they face.