All about the HIPAA Risk Analysis — from the Department of Health & Human Services Office of Civil Rights (OCR).

Posted on May 16, 2010 by Caroline Ramsey-Hamilton • 0 Comments

An amazing development in HIPAA compliance took place on May 7th. What a great surprise for a Risk Analysis/Risk Assessment Person! The Department of Health and Human Services, Office of Civil Rights finally came out with their draft guideline for the HIPAA Risk Analysis on May 7th!

While hospitals and health plans, business associates, technical service providers and physicians have struggled to understand the original HIPAA risk analysis requirement, the Health & Human Services Department finally published the draft guidance to help healthcare providers understand what is expected of them in doing a risk analysis of their protected patient health information (ePHI).

This is a critical part of the HIPAA Security Rule, but there was never any ‘official’ guidance of exactly what was expected and how they should accomplish the risk analysis.

Why the Office of Civil Rights? Because the new HITECH Act (February 2010) directed that OCR oversee health information privacy including the enforcement of the HIPAA requirement. And the guidance is long overdue. I have had dozens of conversations with individuals at hospital and, discussing what a risk analysis is, what are the basic elements, and I am THRILLED to report that the OCR agrees with my methodology.

The draft guideline on risk analysis also takes the same track that the financial institutions have given as guidance to banks and credit unions. That is risk analysis is a foundational document that should be used (and referenced) as the organization evaluates and implements appropriate controls.

OCR refers to the risk analysis, not as a one-time drill, but instead, as an ongoing process to help organizations evaluate their risk focusing on the confidentiality, integrity and availability of protected health information. The Risk Analysis Report, creates the blueprint that an organization will follow as they improve their compliance – for example, deciding what data should be authenticated in particular situations, deciding, when, if or how to use data.

A risk analysis is also the basis for an understanding by organizations of the technologies they will need to secure protected health information, OCR said in the draft guidance May 7.

To quote directly: “We begin the series with the risk analysis requirement in § 164.308(a)(1)(ii)(A). Conducting a risk analysis is the first step in identifying and implementing safeguards that comply with and carry out the standards and implementation specifications in the Security Rule.

Therefore, a risk analysis is foundational, and must be understood in detail before OCR can issue meaningful guidance that specifically addresses safeguards and technologies that will best protect electronic health information.”

Among the basic elements of a risk analysis, OCR said, organizations must identify data collections, document threats to information that could create a potential for inappropriate disclosure and assess current security measures the organization uses to protect patient information. This was great to read because it follows the elements I have built our solutions around.

Those elements, which were reinforced by the draft guideline include the following five elements of risk analysis (and risk assessment).

1. Identify and characterize the assets that need protection, including the databases, the applications, etc.

2. Analyzing the relevant threat data – focusing on what could adversely affect the assets (ePHI) in this case.

3. Modeling the potential losses that could result from the threat actually materializing.

4. Finding the existing vulnerabilities in the current security situation that would increase the odds of the loss actually occurring.

5. Developing appropriate controls to reduce potential loss, reduce existing vulnerabilities and make sure the controls are cost effective.

The OCR also referenced the NIST 800-66 to show sample questions that need to be part of the risk analysis. Luckily – we totally agree with them and have included the NIST 800-66 Guidance in every HIPAA Risk Analysis software solution.

Here’s another short excerpt from the OCR:

“Risk Analysis Requirements under the Security Rule

The Security Management Process standard in the Security Rule requires organizations to “[i]mplement policies and procedures to prevent, detect, contain, and correct security violations.” (45 C.F.R. § 164.308(a)(1).)

Risk analysis is one of four required implementation specifications that provide instructions to implement the Security Management Process standard. Section 164.308(a)(1)(ii)(A) states:

RISK ANALYSIS (Required).

Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the [organization].

OCR went on to cite NIST 800-66: “The following questions adapted from NIST Special Publication (SP) 800-66 are examples organizations could consider as part of a risk analysis. These sample questions are not prescriptive and merely identify issues an organization may wish to consider in implementing the Security Rule: Have you identified the e-PHI within your organization? This includes e-PHI that you create, receive, maintain or transmit. What are the external sources of e-PHI?

The publication of this first draft guideline gives healthcare organizations and other affected organizations a hint about which direction the OCR enforcement is going to go. As I mentioned previously, the regulators are likely to follow the example of financial audits and ask for the current copy of the organization’s risk analysis and use that as the blueprint to measure how well the organization used the risk analysis to prescribe and dictate all other actions which were taken to protection the organization’s protected health information.

In the words of the OCR –

“In Summary, Risk analysis is the first step in an organization’s Security Rule compliance efforts. Risk analysis is an ongoing process that should provide the organization with a detailed understanding of the risks to the confidentiality, integrity, and availability of e-PHI.

For a complete copy of the 8 page OCR guideline, please send an email to chamilton@riskwatch.com.

Building a Model for Security Governance, Risk and Compliance

Posted on April 3, 2009 by Caroline Ramsey-Hamilton • 0 Comments

I recently began to think about how to integrate security seamlessly into an organization — without having security activities and processes pigeonholed into a stovepipe like physical security (the 3 Gs, guns, guards and dogs); or in the rarified atmosphere of the IT Department.

Other business processes are already thought of as an integral part of a business. Think personnel, finance, shipping, sales. All basic parts of any organization, including government agencies (which are another kind of business), have these different categories but security is never mentioned as one of these basics.

Of course, my readers know that none of the other pieces would get very far without good, or even great security. You can’t run an organization without locks on the doors. You can’t run a network with security controls or it would just collapse into a heaping pile of spam within a few hours and become totally useless.

So if we wanted to integrate security and use the risk assessment process to do it — what are the pieces we would integrate? One night over dinner with other security people, we started to build a security model, which could then by assessed and each category would have steps which could be combined to create THE PERFECT INTEGRATED SECURITY GOVERNANCE MODEL!!

I am open to suggestions about other aspects but here’s the list of the ones we started off with:

1. Access Controls

2. Accountability

3. Budget/Fiscal Responsibility

4. Compliance

5. Information Technology

6. Investigations

7. Measurement/Evaluation

8. Personnel Management

9. Policies & Procedures (Ps & Ps)

10. Risk Assessment & Management

11. Security Planning

12. Training and Awareness

In the model I’m proposing, each of these areas could by quantified into a 5-step program with zero meaning no progress in that area, and five meaning it has been integrated into the organization as a standardized, budgeted process.

Send me an email if you’d like to see a graphic of the model. The point of a model is to get an idea of where you are on the pathway to integration of the security model into the business process. For example, you could find out that you doing great on access control and technology, but not so good on accountability or awareness. Then you could put more emphasis, or resources into those deficient areas.

If you’ve ever read this blog before, you know that my mantra is, “if you can’t measure it — you can’t manage it” (quote by the late, great Dr. Peter Drucker).

While listening to talk radio people discussing the problems of AIG, I heard another great line, “Companies that are ‘to big to fail’ … are probably ‘to big to manage’. And that’s probably right, because those companies, with tentacles out into industries all over the world, are probably ALSO TOO BIG TO MEASURE!

So having metrics applies to all these corporate processes and managing security using metrics must be an idea whose idea has come. Often the security departments in companies are isolated from the C-level and may not be included as often as other corporate or department managers are. This is why the breakdown occurs that leads to weakness in compliance with regulations, which can destroy the entire organization, or, if you’re a bank, can lead at a CDO (Cease and Desist
Order).

Often these twelve critical security elements are absolutely essential to the running of the organization and that is why it is important to create a management model to measure how they are working in YOUR organization!

Assessing PCI Compliance — World’s Biggest Standard

Posted on June 27, 2008 by Caroline Ramsey-Hamilton • 0 Comments

Everyone has a credit card these days. Ever take it out and take a good look at that little magnetic strip on the back of a credit card? It’s only about 2 1/2 inches long and quite thin. That little strip contains all the personal information about you — your name, address, password, mother’s maiden name, perhaps your social security number and your financial account number and even more information about your account.

Who wrote the program that ended up on that magnetic strip? Are there copies of that magnetic strip information stored somewhere? And this is only ONE card; you probably have a wallet full of them.

These payment cards (PC= Payment Card Industry) are the biggest deal in information security these days because of a new standard call the PCI-DSS standard (Payment Card Industry- Data Security Standard). The PCI Security Standards Council, which created the standard, was founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc.

Credit card companies want you to charge it and they know that concerns about identity theft might possibly slow down your card use — so it is in their best interests to make sure that a solid security standard is in place to protect you. The standard has turned into a requirement for everyone who takes a credit card and that turns out to be literally millions of grocers, retailers, online retail outlets, government agencies, convenience stores, utilities — almost everyone. So the PCI-DSS standard may be the most widely applied information (data) security standard in the world.

With such a widespread and critical standard, there is confusion about how to meet the standard because just doing a self-assessment isn’t enough — you are also required to do penetration tests on your systems that handle and transmit this electronic customer information and ATTEST that you use the standard in your information systems.

This includes having strong firewalls that protect cardholder data and making sure to remove
the generic vendor-supplied passwords; using good storage devices for sensitive customer information and encrypting data that flows over your network. In addition, the card manager has to use anti-virus software, and also build secure systems. Once proper controls are in place, these controls need to be monitored and tested.

Doing a full compliance and vulnerability assessment annually is the best way to make sure that you can prove you have done all the specific activities required in the PCI-DSS standard. The assessment actually breaks the entire standard down into smaller, manageable chunks and then each one is monitored, or validated, with an audit trail, so that is easy to prove that you have evaluated your organization’s compliance with the PCI-DSS standard.

The PCI-DSS standard is actually mild, as information security standards go, and not as far-reaching or intrusive as, for example, the HIPAA standard (Healthcare Insurance Portability and Accountability Act) which has completely revised the way healthcare organizations do business. Nor is it as complicated as the BSA (Bank Secrecy Act) or the International Standards Organization’s 27001 standard (ISO 27001 and 27002).

After the infamous TJMAXX identify theft incident — consumers should welcome the PCI standard and retailers and others affected by it should be grateful that is just another way of encouraging good information security practices.

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

Fear of Risk Assessment!

Posted on June 17, 2008 by Caroline Ramsey-Hamilton • 0 Comments

Why are people INTIMIDATED by risk assessments? Is it because they seem overwhelming with their arrays of lists and categories? (At last count – I categorized over 1.572 million combinations of the 44 asset categories, 58 threat categories, 55 vulnerability categories, 7 loss categories and 160 control categories)!

Part of the trepidation of manager tasked with a risk assessment seems to be that they are anxious about making key assumptions and assigning importance to different areas of the business or agency. Of course, part of this is political – the risk analyst has the power to build up the importance of one part of an organization and reduce the stature of another – or EVEN AFFECT THEIR BUDGETS!!

In practice however, it seems like the exercise of doing a risk assessment affords a level of protection which is related to how many other people actually contribute to the risk assessment results. Using the compliance survey as a participatory measure takes the onus of absolute responsibility away from the manager and distributes it throughout the organization where it belongs.

Besides – how can one person know enough to do the entire risk assessment by their self? They would have to be everywhere at once – in the morning, late at night, on the weekends, and also be able to channel the work of everyone from the newest tech support person to the director of the data center. And the inclusion of a variety of individuals adds weight and power to the risk assessment.

While the analysts may be accountable for the report of potential risk, the responsibility for any action that needs to be taken is up at the C level, or with the Board. In fact, in the FFIEC IT Handbook, they spell out, “The Board is responsible for holding senior management accountable”. Often we have found that the actual President of a bank or credit union doesn’t always KNOW that he is going to be held responsible – this information is down another level in the organization.

The analyst should not be afraid of making assumptions in the risk assessment; auditors make assumptions all the time. One could say that the world runs on assumptions. So making an assumption about how long it would take to replace the personnel or web applications of a specific part of the organization is not too difficult. Always remember that each component of the risk assessment can be vetted before with relevant management so that senior management does take the responsibility for validating the choices the analyst makes.

Personally, I advocate getting management to sign off, in writing, on the assumptions they accept, in the course of completing the risk assessment – and of course, on the final reports. There’s nothing like a signature on piece of paper to foster a climate of accountability.

Caroline R. Hamilton is the Founder of RiskWatch, Inc., the original top-rated risk assessment software. Hamilton served on the NIST Model-Builder’s Workshop on Risk Management from 1988-1995 and on the National Security Agency’s Network Rating Workshop. In addition, she was a member of the U.S. Department of Defense’s Defensive Information Warfare Risk Management Model and has worked on a variety of risk assessment and risk management groups, including the ASIS Information Technology Security Council and the IBM Data Governance Council, created by Steven Adler. Hamilton also received the Maritime Security Council’s Distinguished Service Award and has written for a variety of books and magazines including the CSI Alert, the Computer Security Journal, the ISSA Newsletter, The HIPAA Compliance Handbook, Defense News, Security & Design, Cargo Security and many other publications. Based in Annapolis, Maryland, Hamilton is a graduate of the University of California.

Threat Assessments & the Maryland Storms

Posted on June 5, 2008 by Caroline Ramsey-Hamilton • 0 Comments

June 4, 2008, Annapolis, Maryland

Threat Assessments are one of the key areas of a security risk assessment. Whether it’s information technology or physical security — having good threat information is a major component of any risk assessment.

Threat data is also very difficult to get and to keep updated. Part of the problem is that if you look at ‘current’ threat data — you will find that this year, for example, we have had an unusual amount of rain and an unusually high number of storms and ‘conditions that are favorable for tornado (tornadic sp?) activity in Maryland.

Take yesterday for example. I had to take one of my beagles to the vet. As I got into my car, my son called to say there was a very severe storm with a possible tornado heading toward us. (He is in Virginia so he gets the storms first). I actually saw the storm in my rear view mirror as I headed across the 4 mile Bay Bridge and rode out the storm in the vet’s office. All my power was out when I finally got home and hundreds of trees were down. There was so much flooding that I had to take off my shoes and pull up my dress to get to my car in the parking lot of the vet’s office.

So with these storms, tornados, rain and flooding, should I increase my threat of storms, flooding and water damage? NO. In this case, as in others (like hurricanes), as a risk analyst, you are looking at long term trends. Remember 2005? It was the busiest hurricane season on record, with 27 named storms and 11 federal disaster declarations and the unforgettable trio – Katrina, Wilma and Rita? Everyone thought this was the signal of a new problem with hurricanes, but 2006 was quiet. In fact, no hurricanes made landfall in the U.S. in 2006; and in 2007 there was only 15 named storms.

What insurance companies have known for years is that these things occur in cycles, and if you change your disaster plans to focus on hurricanes, next year you may instead get wind, or wildfires. So the smart risk assessor will look at 20 or even 50 year cycles, and will normalize those cycles into an annual number and that annual number will be a better predictor of what actually happens year by year.

For a risk assessment, I always look at what is called an “All-Hazards” threat approach. Even for an IT risk assessment, you need to look at the statistics for natural disasters, and related crime stats, as well as IT threats such as disclosure, viruses, malware, phishing, etc. The impact of a hurricane or flood on a data center is just as damaging, if not more damaging, than a virus brought in by an employee.

There are several threat sources you can refer to, if you are attempting to create your own threat matrix for a risk assessment. In the U.S., the National Weather Service (www.noaa.gov), has good threat data for natural phenomena, and the FBI publishes good crime data — the uniform crime reports (http://www.fbi.gov/ucr/ucr.htm). For looking at IT threat data, there is a wide variety of sources including the CERT at Carnegie Mellon (www.cert.org).

Of course, the best, and most localized is either from your internal data, or from industry data. This includes incident response tracking, incident reports, penetration and scanning test results which can be combined to give a good overall threat profile for your organization to in the risk assessment. The threat assessment probabilities are going to contribute to the risk calculation by seeing what level of protection different assets need according the threats that can impact them.

Climate Change & Compliance

Posted on May 30, 2008 by Caroline Ramsey-Hamilton • 0 Comments

It’s a risky world now. Mostly fueled by twenty-four hour media transmission so that Annapolis was on CNN a few weeks ago, when a dead construction worker dangled on a crane for over an hour. And since then — we have watched the earthquake in China, the cyclone in Myanmar, the crane collapse in NYC, and much more.

That being said — IT management worries less about natural disasters and more about their web site being hacked, phishing attacks, associates bringing viruses in from their home offices, and the regulators visiting them. Regulators are often more feared than a cyclone or a tornado, because of the expense and havoc they can trigger. As we continue to work with regulators in both finance and healthcare, you can understand why they continue to stress the risk assessment as the foundation of the IT security programs.

The risk assessment by itself does not magical and instant protection against security intrusions, but it does something more important — it provides a metric to measure against. You can call it the cornerstone of a security program because it measures against an existing standard and see how your IT infrastructure stacks up. Although different standards exist, such as FFIEC, SB 1386, FACT, GLBA, BSA, ISO 27001, HIPAA, PCI and many more — they have common components that look at how employees do their jobs, and how they use the security controls they have available to them.

I met Peter Drucker at Claremont University when he was about 88 years old (he died in 2005 at the age of 96), and he was the “father of modern management”. He told me that security assessment should be integrated into the fabric of management because managers need numbers — and “if you can’t measure it, you can’t manage it”. So that’s what the risk assessment provides — it provides a metric so the organization can start to measure its performance in these key areas.

It’s just a plus that the risk assessments incorporate compliance assessments by using the measurement against a standard as the basis for the assessment. This shows you where you are today, where you are going, and (sometimes) how fast, and how expensive it is going to be to get there.

Finishing my Pandemic Flu Preparations

Posted on May 28, 2008 by Caroline Ramsey-Hamilton • 0 Comments

I have heard so much about Pandemic Flu so I decided to set up my own pandemic flu plan for my home. I have everything I need — including food, medicine, dog food, trash bags, extra water. My sister-in-law just moved to southern California and her friends told her to get ready for the next earthquake — and she followed my pandemic flu personal checklist. Now’s she’s also ready for anything. The nice thing about being prepared for one potential disaster means you can be ready for all of them — earthquakes, power outages, hurricanes, OR pandemic flu. We are now including the pandemic flu planning assessments in all our RiskWatch products. But let me know if you’d like to review one of my checklists for your personal continuity plans.

RiskWatch, Inc.

Posted on May 28, 2008 by Caroline Ramsey-Hamilton • 0 Comments

How We Assess Risk & Compliance

Most institutions are now required to conduct formal risk assessments of their IT and online security systems to ensure compliance with regulations such as: FFIEC, NERC, GLBA, BSA, NCUA, ISO 17799, ISO 27001 and many others. RiskWatch software allows the user to evaluate their risks and produces reports and graphs specifically detailing compliance within these regulations, or showing where controls are needed.

Assessment of organizations’ compliance with these risk requirements can be met in up to 80% less time with the use of RiskWatch software and online services:
• An evaluation of threats vs. vulnerabilities for the client
• Simplified data collection with easy-to-use, web-based compliance surveys
• In-depth, graphic reports that detail the recommended controls to mitigate risk including both Return on Investment and Loss Impact Analysis.

Have YOU Completed YOUR Risk Assessment?

Category Archives: Risk Assessment & Compliance

How We Assess Risk & Compliance