At first read, the security risk analysis (SRA) provisions of the proposed Stage 2 “meaningful use” regulations appear to have changed only slightly from those in Stage 1. The language in the draft rule is nearly identical to Stage 1, with one notable addition highlighted below:

“Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1), including addressing the encryption/security of data at rest in accordance with requirements under 45 CFR 164.312(a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the provider’s risk management process.

Covered entities and eligible providers must now address the issue of encryption of “data at rest” as part of their security risk analysis process. This shines a spotlight on the existing encryption references within the HIPAA Security Rule. Encryption of ePHI is specifically covered under 45 CFR 164.312(a)(2)(iv) which reads; “Implement a mechanism to encrypt and decrypt electronic protected health information.” However, since it is categorized as an “addressable control,” it is not specifically mandated.

As part of Stage 2 Meaningful Use, encryption of “data at rest” must be considered as an addressable control. As such, providers need a process by which they evaluate whether the control is “reasonable and appropriate” and would likely contribute to protecting its health information.   If the control is deemed “reasonable and appropriate,” then it must be implemented.

However, if the provider decides “encryption of data at rest” is not reasonable and appropriate, then it must 1) document why it is not reasonable and appropriate, and 2) Implement an equivalent alternative measure if reasonable and appropriate. Despite a little remaining wiggle room, it has become increasingly difficult to justify not encrypting ePHI under the “reasonable and appropriate” caveat.

Turning to the new rules for EHR software certification, Stage 2 also requires the main software application ‘to be able to demonstrate the capacity to encrypt [data on] mobile devices in circumstances where the EHR technology manages the data flow on the mobile device,”

In our view, these provisions stop just short of a mandate. Determining reasonableness is not just about the cost of hardware and software or the complexity of implementation. It is more about whether or not the organization can execute the requirement consistently and effectively.

Given that the majority of significant breaches to date have been the result of lost or stolen devices containing unencrypted data, and the increasing mobility of data itself, it will be difficult to find “equivalent alternative measures.” That said, Redspin can provide a framework for considering the issue within our overall SRA roadmap and expert guidance on how to reasonably and effectively protect patient information.

Every IT department faces the challenge of having to apply limited resources (headcount, technology, 3^rd party assessments) against a plethora of potential security risks. Choosing wisely is often the difference between an effective security strategy and an ineffective one. With that in mind and a number of possible assessment approaches available, what benefits can be gained from an internal penetration test?

First, since security terminology is often misunderstood, let’s first define internal penetration testing. An internal pen test is a very specific scope of work where a security engineer connects to your internal network, or portion thereof, and with nothing other than an internal network connection, attempts to gain access to sensitive organizational resources. In an internal pen test the security engineer is network level connected but has no other credentials, such as a user account on the domain or on a corporate software application. Such a test can be conducted on-site with the engineer working from a conference room with an Ethernet drop, or done remotely via VPN connection. It is from this restricted vantage point that the engineer attempts to gain unauthorized access to internal systems and data.

The results of an internal penetration test typically demonstrate what information or other assets might be exposed to an unauthorized user who has network level access to your corporate IT environment. Extrapolating further, it also shows what a hacker could access if they were to compromise your gateway. But, an internal pen test is not designed simply to expose risk from external hackers. There are a number of internal risks as well. Here are some other important considerations:

• What confidential info might an employee obtain by gaining access to your internal HR database

• What about vendors or visitors who are allowed on your internal network by an employee, and/or they are left alone in a conference room where they plug into a live Ethernet port?

• What information could a rogue employee exploit?

• Can partner companies that have network level connectivity access more internal resources than you intended?

An internal penetration test can help answer these questions and educate others in your organization about this kind of risk. With limited resources to work with, it’s important to clarify what your organization wants to accomplish as you embark on any type of security assessment. We hope we’ve clarified above the most important benefits of an internal penetration test.

In any complex, cross-functional business challenge, responsibility and authority must be distributed intelligently while at the same time prove a process of internal dispute resolutions. An information security program is one such complex and multifarious business necessity. At its heart, information security is a method of managing risk to information and information systems, and reducing uncertainty relative to organizational objectives; it is a balance.

But the success of an information security program depends upon the ability of an organization to establish a set of controls based on a thoughtful and consistent design that was developed against carefully analyzed internal and external requirements. Relatively few companies approach the problem this way, so we thought we’d offer some guidance based on Redspin’s 10+ years of IT security experience.

The following describes an accountability-driven and risk-based approach to address the information security expectations of leaders, customers, citizens, partners, and investors.

Creating an environment where operational units coordinate to achieve consistent and appropriate information security controls helps to ensure that the operation and security objectives of the organization are met. One way to do this is to assign accountability and responsibilities in a way that makes internal parties accountable to one another, with guidance and input from subject matter experts. The following mutual accountability can be used to drive decisions that align with your organization’s mission and goals:

A Data Steward is a single person accountable for establishing policies for internal uses and conditions of internal and external disclosure. There is one steward for each domain of data across the entire organization. Domains are generally broad and easily identifiable, organizations having on average between 10 to 15 core domains.

A Process Owner is a single person accountable for general processes (such as workforce acquisition and termination). These individuals establish the minimum process control requirements, which may then be implemented in a centralized or decentralized manner. Each implementer is responsible for meeting the process owner’s control requirements and one or more data steward’s control requirements.

System Sponsors are assigned to each application and system, from the department specific applications to general utility applications such as email. These system sponsors are responsible for meeting the availability and processing quality requirements of the process owners (e.g. up time and stability), and the data confidentiality and integrity requirements of the data stewards (e.g. patching and access controls). They are also responsible for justifying the continued existence of an application or system.

Data Gatekeepers are accountable for disclosures to a particular audience. Some of these roles are historically well established. For example, the senior public-relations official is accountable for responding to inquiries from the public and the press, and the senior legal official is accountable for addressing inquires from the courts and, depending on the organization, perhaps for inquiries from regulators and governments. Extending this concept to each unique audience creates internal accountability. Audiences may include consumers, vendors, business customers, partners, local and foreign governments, and law enforcement and intelligence agencies. The data gatekeeper is answerable to one or more data stewards.

Let’s run this through an example to see how it works. USB thumb drives are prevalent, with organizations taking stances that range from very loose to very tight. Policies commonly ban the devices, don’t mention them, or put IT in the role of deciding who gets one. The first two positions generally fail to serve the organization, and the last requires IT to make a business operations decision. To address this let’s step back to ask ourselves a few questions. Which process do the USB drives support and are the USB drives inherently required by those processes? Will the USB drive contain controlled information and are the data stewards requirements met?

Sales might use thumb drives to display presentations on client’s equipment. This is clearly a sales process, and would be under the purview of the most senior sales management position, perhaps a VP of Sales. The VP of Sales could responsibly and reasonably take a position that USB drives are required for external sales presentations. So long as that drive contains only sales information, then the data in question is also under the purview of the VP of Sales.

Changing the scenario for a moment, let’s say a salesperson wants to include very sensitive discount information. In this case, the VP of Sales may have a policy that discount data is only shared with key members of the client decision team. The VP of Sales in a process owner role still approves the use of USB thumb drives for sales presentations, but the VP of Sales in a data steward role requires that the data be distributed in a limited and controlled manner.

Changing the scenario even further, let’s say that the client requests key financial information. Again the use of USB drives is already approved by the VP of Sales. However, in this scenario the data in question is subject to the policies of the CFO, who has the requirement that key financial data be stored only on company owned equipment and be encrypted at all times when not within company facilities. In this case, the sales person must use a company owned and encrypted laptop for the presentation. If the VP of Sales doesn’t like this and still wants to use USB drives, the issue is not between Sales and IT, it’s between Sales and Finance. We are effectively taking IT out of  the middle, to a role where IT implements the decision of the parties who have the greatest stake in the decision.

IT organizations in the healthcare industry are being asked to make increasingly complex and subtle decisions. IT everywhere is being asked to do more and be responsible for more. Enabling the business to meaningfully engage IT, and creating a way that provides the businesses with the right information to make decisions is key to the perceived and actual success of an IT department. The road to engaging all parts of the business is difficult, but it has also been shown to be a hallmark of successful organizations.

IT has been put in the role of making business decisions, because organizations lack a framework for making data and system decisions. Providing a framework for decision making can become a key value that IT can provide. Even if your organization is not ready to formally adopt these concepts the thinking process, and the line of questions that result, will help you facilitate better security decision making within your organization.