RisknCompliance Blog

Thoughts On Delivering Meaningful Outcomes in Security and Privacy

Tag: Audit

Is your auditor or consultant anything like the OPM OIG?

The OPM breach has been deservedly in the news for over a month now.   Much has been written and said about it across the mainstream media and the internet1.

I want to focus here on a topic that hasn’t necessarily been discussed in public,  perhaps not at all – Could the OIG (and their audit reports) have done more or different than what they did,  year after year of issuing the reports? Specifically,  how could these audit reports have driven some urgently needed attention to the higher risks and perhaps helped prevent the breach?

Let us look at the latest  OIG’s Federal Information Security Management Act (FISMA) audit report issued in November 2014 (pdf) as a case in point. The report runs over 60 pages and looks to have been a reasonably good effort in meeting its objective of covering the general state of compliance with FISMA.  However,   I am not sure the report is any useful for “real world”  risk management purposes at an agency that had known organizational constraints in availability of appropriate security people or resources;  an agency that should have had some urgency in implementing certain safeguards on at least the one or two critical system(s) for the nature and quantity of sensitive information they had.

We have talked about this problem before, advising caution against “fixation” with compliance or controls frameworks and not focusing on priority risk management needs. In the case of this particular report,  the OIG should have discussed the risks as well (and not just the findings or gaps) and provided some actionable prioritization for accomplishing quick-wins in risk mitigation. For example,  recommendation #21 on page 25 could have called out the need for urgency in implementing multi-factor authentication (or appropriate compensating controls) for the one or two “high risk” system(s) that had upwards of 20 million sensitive records that we now know were breached.

I also believe providing a list of findings in the Executive Summary (on page 2) was a wasted opportunity. Instead of providing a list of compliance or controls gaps,  the summary should have included specific call-to-action statements by articulating the higher risks and providing actionable recommendations for what the OPM could have done over the following months in a prioritized fashion.

OPM-OIG

Here then are my recommended takeaways:

1. If you are an auditor performing an audit or a consultant performing a security assessment,  you might want to emphasize “real” risks,  as opposed to compliance or controls gaps that may be merely academic in many cases. Recognize that evaluation and articulation of risks require a more complete understanding of the business, technology and regulatory circumstances as compared to what you might need to know if you were merely writing gaps against certain controls or compliance requirements.

2. Consider the organizational realities or constraints and think about creative options for risk management. Always recommend feasible quick-wins in risk mitigation and actionable prioritization of longer term tasks.

3. Do not hesitate to bring in or engage with specialists if you aren’t sure you can evaluate or articulate risks and recommend mitigation tasks well enough. Engage with relevant stakeholders that would be responsible for risk mitigation to make sure they are realistically able to implement your recommendations, at least the ones that you recommend for implementation before your next audit or assessment.

In closing, I would strongly emphasize a focus on meaningful risk management outcomes, not just producing reports or deliverables. A great looking deliverable that doesn’t convey the relative levels of real risks and the urgency of mitigating certain higher risks is not going to serve any meaningful purpose.

References for additional reading

1.  At the time of this writing,  I found these two links to be useful reading for substantive information on the OPM breach.

Information about OPM Cybersecurity Incidents

“EPIC” fail—how OPM hackers tapped the mother lode of espionage data

2.  You may also be interested in a quick read of our recommendations for agile approaches to security/privacy/compliance risk assessments or management.  A pdf of our slide deck will be emailed to you after a quick registration here.

Patient Portals – Make or Break

Like many other Health IT initiatives today, the primary driver for patient portals is regulatory in nature. Specifically, it is the Meaningful Use requirements related to view,  download or transmit and secure messaging. However, the biggest long term benefit of the portals might be what they can do for patient engagement and as a result, to the providers’ business in the increasingly competitive and complex healthcare marketplace in the United States.

The objective of this post is to discuss the security aspects of patient portals, specifically, why the current practices in implementing these portals could pose a big problem for many providers. More importantly, we’ll discuss specific recommendations for due diligence actions that the providers should take immediately as well as in the longer term.

Before we get to discuss the security aspects, I think it is important to “set the stage” by discussing some background on patient portals. Accordingly, this post covers the following areas in the indicated sequence:

1. What are patient portals and what features do they (or could) provide?

2. Importance of patient engagement and the role of patient portals in patient engagement

3. The problem with the current state in Health IT and hence the risks that the portals bring

4. Why relying on regulations or vendors is a recipe for certain failure?

5. What can/should we do (right now and in the future) –  Our recommendations

1. What are Patient Portals and what features do they (or could) provide?

I would draw on information from the ONC site for this section. Here is the pertinent content, to quote from the ONC site:

A patient portal is a secure online website that gives patients convenient 24-hour access to personal health information from anywhere with an Internet connection. Using a secure username and password, patients can view health information such as:

• Recent doctor visits

• Discharge summaries

• Medications

• Immunizations

• Allergies

• Lab results

Some patient portals also allow patients to:

• Exchange secure e-mail with their health care teams

• Request prescription refills

• Schedule non-urgent appointments

• Check benefits and coverage

• Update contact information

• Make payments

• Download and complete forms

• View educational materials

The bottom-line is that patient portals provide means for patients to access or post sensitive health or payment information. In the future, their use could expand further to include integration with mobile health applications (mHealth) and wearables. Last week’s news from EPIC should provide a sense for things to come.

2. Importance of patient engagement and the role of patient portals in patient engagement

As we said above, the primary driver for patient portals so far has been the Meaningful Use requirements related to view,  download or transmit and secure messaging. However, the biggest long term benefit of the portals might be what they can do for patient engagement and becoming a key business enabler for providers.

The portals are indeed a leading way for providers to engage with patients, as can be seen in this graphic from the 2014 Healthcare IT Priorities published by InformationWeek1.

image

Effective patient engagement of course can bring tremendous business benefits, efficiencies and competitive edge to providers.

From a patient’s perspective, the portals can offer a easier method for interacting with their providers which in turn has its own benefits for patients. To quote from the recently released HIMSS report titled “The State of Patient Engagement and Health IT”2

A patient’s greater engagement in health care contributes to improved health outcomes, and information technologies can support engagement.

In essence, the importance of patient portals as a strategic business and technology solution for healthcare providers doesn’t need too much emphasis.

3. The problem with the current state in Health IT and hence the risks that the portals bring

In my view, the below quote from the cover page of the 2014 Healthcare IT Priorities Report published by InformationWeek1 pretty much sums it up for this section.

Regulatory requirements have gone from high priority to the only priority for healthcare IT.

We all know what happens when security or privacy programs are built and operated purely to meet regulatory or compliance objectives. It is a shaky ground at best. We talked about it in one of our blog posts last year when we called for a change in tone and approaches to healthcare security and privacy.

4. Why relying on regulators or vendors is a recipe for certain failure of your security program?

It is probably safe to say that security in design and implementation is perhaps not the uppermost concern that HealthIT vendors have (certainly not the patient portal vendors in my opinion) today. To make it easy for them, we have lackluster security/privacy requirements in the regulation for certifying Electronic Health Records.

Consider the security and privacy requirements (yellow in this pdf) that vendors have to meet in order to obtain EHR certification today. You will see that the certification criteria are nearly not enough to assure the products are indeed secure enough before the vendors can start selling them to providers. And then, the administration or enforcement of the EHR certification program has been lacking as well in the past.

If you consider a risk relevant set of controls such as the Critical Security Controls for Effective Cyber Defense, you will see that the certification criteria are missing the following key requirements in order to be effective in today’s security threat landscape:

· Vulnerability assessments and remediation

· Application Security Testing (Including Static and Dynamic Testing)

· Security training for developers

· Penetration tests and remediation

· Strong Authentication

Think about using these applications to run your patient portals!

If you are a diligent provider, you will want to make sure that the vendor has met the above requirements even though the certification criteria do not include them. The reality though may be different. In my experience, providers often do not perform all the necessary due diligence before purchasing the products.

And then, when providers implement these products and attest to Meaningful Use, they are expected to do a security risk analysis (see the green highlighted requirement in the pdf). In my experience again, risk analysis is not performed in all cases. Of those that perform them, many are not really risk assessments.

The bottom-line? … Many providers take huge risks in going live with their patient portals that are neither secure nor compliant (Not compliant because they didn’t perform a true risk analysis and mitigate the risks appropriately).

If you look again (in 1 above) at the types of information patient portals handle, it is not far-fetched to say that many providers may have security breaches waiting to happen. It is even possible that some have already been breached but they don’t know yet.

Considering that patient portals are often gateways to the more lucrative (from a hacker’s standpoint) EHR systems, intruders may be taking their time to escalate their privileges and move laterally to other systems once they have a foothold in the patient portals. Considering that detecting intrusions is very often the achilles heel of even the most well-funded and sophisticated organizations,  it should be a cause for concern at many providers.

5. What can/should we do (right now and in the future) –  Our recommendations

It is time to talk about what really matters and some tangible next steps …

What can or must we do immediately and in the future?

Below are our recommendations for immediate action:

a) If you didn’t do the due diligence during procurement of your patient portal product, you may want to ask the vendor for the following:

· Application security testing (static and dynamic) and remediation reports of the product version you are using

· Penetration testing results and remediation status

· If the portal doesn’t provide risk based strong (or adaptive) authentication for patient and provider access, you may insist on the vendor committing to include that as a feature in the next release.

b) If you didn’t perform a true security risk analysis (assessment), please perform one immediately. Watch out for the pitfalls as you plan and perform the risk assessment. Make sure the risk assessment includes (among other things) running your own vulnerability scans and penetration tests both at network and application layers.

c) Make sure you have a prioritized plan to mitigate the discovered risks and of course, follow through and execute the plan in a timely manner.

Once you get through the immediate action steps above, we recommend the below action items to be included in your security program for the longer term:

a) Implement appropriate due diligence security measures in your procurement process or vendor management program.

b) Have your patient portal vendor provide you the detailed test results of the security requirements (highlighted yellow in the attachment) from the EHR certifying body. You may like to start here (Excel download from ONC) for information on the current certification status of your patient portal vendors and the requirements they are certified for.

c) Ask the vendor for application security (static and dynamic) and pen test results for every release.

d) Segment the patient portal appropriately from the rest of your environment (also a foundational prerequisite for PCI DSS scope reduction if you are processing payments with credit/debit cards).

e) Perform your own external/internal pen tests every year and scans every quarter (Note : If you are processing payments with your payment portal,  the portal is likely in scope for PCI DSS. PCI DSS requires you to do this anyway).

f) Conduct security risk assessments every year or upon a major change (This also happens to be a compliance requirement from three different regulations that will apply to the patient portal –  HIPAA Security Rule, Meaningful Use and PCI DSS, if processing payments using credit/debit cards).

g) If you use any open source modules either by yourself or within the vendor product,  make sure to apply timely patches on them as they are released.

h) Make sure all open source binaries are security tested before they are used to begin with.

i) If the vendor can’t provide support for strong authentication,  look at your own options for proving risk based authentication to consumers. In the meanwhile, review your password (including password creation, reset steps etc.) to make sure they are not too burdensome on consumers and yet are secure enough.

j) Another recommended option is to allow users to authenticate using an external identity (e.g. Google, Facebook etc. using OpenID Connect or similar mechanisms) which may actually be preferable from the user’s standpoint as they don’t have to remember a separate log-in credential for access to the portal. Just make sure to strongly recommend that they use 2 step verification that almost all of these social media sites provide today.

k) Implement robust logging and monitoring in the patient portal environment (Hint : Logging and Monitoring is not necessarily about implementing just a “fancy” technology solution. There is more to it that we’ll cover in a future post)

In summary, there is just too much at stake for providers and patients alike to let the status quo of security in patient portals continue the way it is. We recommend all providers take priority action considering the lasting and serious business consequences that could result from a potential breach.

As always, we welcome your thoughts, comments or critique. Please post them below.

References

1 2014 Healthcare IT Priorities published by InformationWeek
2 The State of Patient Engagement and Health IT(pdf download)

 Recommended further reading

Patient engagement – The holy grail of meaningful use
Patient portal mandate triggers anxiety
MU Stage 2 sparks patient portal market

How useful is the HHS OIG report published this week?

I am sure some of you saw this news report about HHS OIG finding some security related deficiencies in the EHR certification program.

I was keen to read the full OIG report (pdf) which I did get a chance to do this evening. I know HHS OIG does great work overall but I must say I didn’t come away feeling very good about the quality or usefulness of this particular report, for the following couple of reasons:

  1. The report was really of an audit performed in 2012 of the 2011 EHR certification program which doesn’t even exist in 2014. What value does it provide if OIG has ONC providing responses to this audit report in 2014? Shouldn’t OIG have sent this report to ONC soon after they did the audit in 2012 so the report could have led to changes in the program when it still existed? It appears this OIG audit and the report could have been a better use of taxpayer dollars had it been timely.
  2. I am not sure OIG has done a good job of substantiating why they don’t agree that the 2014 certification criteria addresses their concerns. They provide an example of multi-factor authentication not being included in the 2014 criteria. While multi-factor authentication would obviously provide for better security, does OIG think all access to EHRs must be protected by multi-factor? Or is it perhaps only remote access (meaning access from outside the trusted network say a hospital facility)? Security in healthcare can’t come at the expense of user experience of providers and clinicians. Requiring multi-factor at all times is going to impact clinician productivity and hence patient care. Also, OIG should have known that multi-factor technologies are still not (or at least were not when ONC finalized the 2014 criteria) at a point where they can be used as the mandatory baseline authentication mechanism in EHRs without compromising user experience. If I remember correctly, the HealthIT Standards Committee (HITSC) did consider 2 factor authentication for inclusion in the 2014 criteria but decided to exclude it for “practicality” reasons. To sum up on this point, I think OIG could have been more objective in their opinions on 2014 criteria.

In closing, I am not sure what process or protocols does OIG follow but it appears this audit report could have had better impact if it had been more timely, objective and actionable.

Top 10 Pitfalls – Security or Privacy Risk Assessments

Risk Assessment is a foundational requirement for an effective security or privacy program and it needs to be the basis for every investment decision in information security or privacy. To that extent, we strongly recommend it as the very first thing that organizations do when you they set out on implementing or improving a program. It is no surprise then that most regulations also include them as mandatory requirements (e.g. HIPAA Security Rule, Meaningful Use Stages 1 and 2 for Healthcare Providers,  PCI DSS 2.0). Yet, we continue to see many organizations do not perform it right, if they perform one at all. This is true at least in the Healthcare sector that we  focus on.  They see it as just another compliance requirement and go through the motions.

So, we thought about a list of “Top 10 Pitfalls” related to Risk Assessments. We present them here and will be looking to expand and discuss each of these pitfalls in separate posts to follow.

    1. Performing risk analysis without knowing all the locations the data you are looking to safeguard (PHI, PII etc.) is created, received, stored, maintained or transmitted
    2. Approaching it with a compliance or audit mindset rather than a risk mindset
    3. Mistaking controls/gap assessment for risk analysis. Hint: Controls/Gap Assessment is but one of several steps in risk analysis.
    4. Focusing on methodologies and templates rather than outcomes; We discuss the idea here
    5. Not having a complete or holistic view of the threats and vulnerabilities and hence failing to articulate and estimate the likelihood adequately
    6. Not realizing that no security controls framework (e.g. NIST 800-53, HITRUST CSF etc.) is perfect and using the security controls in these frameworks without a sense of context in your environment
    7. Poor documentation – Reflects likely lack of due diligence and could lead to bad decision making or at the very least may not pass an audit
    8. Writing Remediation or Corrective Action Plans without specialist knowledge and experience in specific remediation areas
    9. Inadequate planning and lack of curiosity, investigative mindset or quality in engagement oversight
    10. Not engaging the right stake holders or “owners” throughout the risk assessment process and especially in signing off on remediation recommendations or Corrective Action Plans

We’ll be delighted to hear your feedback and will look to perhaps even grow this list based on the feedback. After all, this is about being a good steward of the security or privacy program dollars and managing risks to our organizations, customers or partners.

Verizon 2010 Data Breach Investigations Report – Key takeaways for Security Assessors and Auditors

The Verizon 2010 Data Breach Investigations Report (DBIR) released last week has some interesting findings, just as it did last year. What makes it special this year is that Verizon partnered with the United States Secret Service in developing this report. I don’t intend to discuss all the statistics in this blog (will do so in another upcoming blog) but as you will see explained in the report, the Secret Service’s involvement has thrown new light into some of the findings.

My intention here is to highlight the significance of such a report to security and audit practitioners with the objective of improving the quality of their risk assessments or audits and more importantly, help make the right recommendations to management.  From my experience as a security practitioner and an occasional auditor, I can tell that we may not always be using all the available information to help improve the quality of our risk assessments or audits. And, I think reports such as the Verizon DBIR can provide some valuable help from that standpoint.

Let me explain what I mean… Deliverables for any risk assessment or audit typically include a list of findings and for each finding, we provide an explanation of the risk, the risk severity  (High, Medium, Low) and suitable recommendations for risk mitigation or remediation.  The management would then proceed to remediate various gaps in priority based on our risk rankings. Considering that risk is a product of likelihood and impact (I like the OWASP risk rating methodology, so will use it here), it is important that we get the impact and likelihood right.  Impact is largely a function of the organization’s characteristics including various technical and business factors seen in the methodology. On the other hand, likelihood is a function of threats and vulnerabilities.  I think the DBIR can be a useful reference in estimating the likelihood.

For example, the DBIR says that external agents were responsible for about 78% of the breaches whereas about 48% were caused by insiders. These numbers can be used to arrive at a better objective estimate  of the likelihood that these threat agents may cause any harm. Similarly, the DBIR also says that  48% of the breaches involved privilege misuse, 40% resulted from hacking  and 38% utilized malware. These numbers can be used for objective estimation of the likelihood that associated vulnerabilities could be exploited. The OWASP methodology has an illustration for such objective risk estimation.

These are but a couple of examples. The DBIR has a wealth of information that can be useful to auditors and security practitioners alike, both in improving the quality of their work as well as in being able to defend their risk rankings. We all realize that risk rankings almost always have a level of subjectivity in them but I think reports like the DBIR can be leveraged to make them as objective as possible. A very good example is the risk level one might normally assign to a case of unpatched vulnerability versus a configuration issue.  It may not be readily obvious that one might need to be assigned a higher risk level over another until you read the DBIR. The DBIR tells us that the likelihood of exploitation of an unpatched  vulnerability is far less as compared to a vulnerability caused by a configuration issue. If we didn’t leverage the DBIR (and assuming both issues had equal impacts), we might assign equal risk levels to both the findings or worse, we might assign the unpatched vulnerability a higher risk level.

Over the next couple of weeks, I plan to be blogging with a detailed commentary on some of the findings in the report including a special post on how the report can be leveraged to enhance the effectiveness of PCI DSS programs.

Hope this is useful! As always, we welcome your thoughts and comments.

RisknCompliance Services Note

We at RisknCompliance track about a dozen of such reports every year and maintain a up-to-date database of the current security threats and vulnerabilities at a detailed level. We are able to leverage this knowledge in  providing our clients with  a much-wanted third-party assessment of their risk management or audit methodologies and  programs. After all, security risk assessments and audits form the very foundation of risk management or audit programs, so we believe it is critical that every organization fine-tunes its methodologies and  knowledgebase.

Please contact us here if you would like to discuss your needs. We will be glad to talk to you with the details and how we might be of assistance to you.