RisknCompliance Blog

Thoughts On Delivering Meaningful Outcomes in Security and Privacy

Tag: Consulting

Docs turn up the heat on ONC! – Security Commentary

HealthcareITNews reported yesterday on this letter that was written by several physician organizations to the ONC.

I wanted to write a couple of quick thoughts on the security aspects raised in the letter. I highlighted relevant parts on pages 1 and 2 of the letter with annotations #1, #2 and #3.

Here then are my thoughts on the three items…

#1

#1

We agree with this point. We have talked about our security related concerns around the EHR Certification process and the Meaningful Use program previously. Here and here are a couple of posts for example.

The first link has our commentary we published on the OIG report being referred to in the letter.

The second linked post on Patient Portals has specific details of our thoughts on the security criteria in the MU and Certification programs. We also discussed specific due diligence recommendations for providers. These recommendations should also apply to Electronic Health Records (EHRs) for the most part.

 

#2 and #3

#2

#3

These two paragraphs in the letter speak to the Identity and Access Management (IAM) related concerns, in particular around stronger authentication and usability.

We couldn’t agree more on these points. I am also glad the letter highlights the need for strong authentication.

It is no secret that IAM programs in general haven’t lived up to the promise and expectations. Healthcare provider settings in particular provide specific challenges, primarily because of the need for IAM to really be “transparent” and support clinical workflows seamlessly. We know this continues to be a challenge at most healthcare provider organizations. The point being made in the letter should come as no surprise to anyone.

In our view, an effective solution to this problem requires the IAM/HealthIT product vendors as well as IAM/Security consultants to “up” the game.

And then,  healthcare providers (especially the larger ones who have the power and influence to move their vendors to act) have an important role to play in bringing the IAM and HealthIT vendors to the table so we have viable technology options available to us. We first talked about it  at this webinar back in 2013, but I don’t think we are anywhere close to seeing viable technology options yet in leading vendor solutions.

 

In summary, I think these security related arguments being made in the letter are very valid. However, I am not sure how much ONC can do to move us forward. At best, I think the ONC can only “take the horse to the water” as it were. I really think we need both the IAM and HealthIT vendors to step up and collaborate actively to deliver viable solutions. And the healthcare providers need to push the vendors to do it.

I hope this has been a helpful read. Please don’t hesitate to leave your thoughts below, good or bad.

Beware of Security Best Practices and Controls Frameworks

What could be possibly wrong with “Best Practices” or “Leading Practices” that your favorite security consultant might be talking about? Or for that matter, how could we go wrong if we used the “leading” security standards or controls frameworks?

It is of course useful to have a benchmark of some sort to compare yourself against your peers. The problem comes up (as it so often does) when we start to take these so called best practices and standards for granted. This often drives us to a state of what I like to call as template mindsets and approaches in security. More often than not in my experience, this leads to us making incorrect security decisions because we didn’t consider all the facts and circumstances that may be unique to each of our settings.

Let me explain with an example.

Let us say that you are using a leading security framework such as the HITRUST CSF for healthcare. To take the example of password controls, Control Reference 01.d on Password Management has a fairly restrictive set of password controls even at Level 1, which is HITRUST CSF’s baseline level of controls. Level 1 includes requirements for password length, complexity, uniqueness of the current password as compared to the last certain number of passwords and so on. However, there is no requirement in Level 1 around the standard to be used for hashing passwords. In fact, there is not a single mention of the words “password hash” or “salt” in over 450 pages of the CSF framework even in its latest 2014 version.

Now, if you are a seasoned and skilled security practitioner, you should know that these Level 1 password controls are mostly meaningless if the password hashes are not strong enough and the password hash file was stolen by some means. It is fairly common for hackers to steal password hash files early and often in their hacking campaigns. Reported breaches at Evernote, LinkedIn and Adobe readily come to mind. We learned about what appears to be this fairly unprecedented scale of stolen passwords just yesterday.

So, if you see a consultant using a so called best practice set of controls or one of the security controls frameworks to perform your risk assessment and he/she doesn’t ask a question on password hashes (or some other control or vulnerability that may truly matter), you should know the likely source of the problem. More than likely, they are simply going through the motions by asking you questions from a controls checklist with little sense of understanding or focus around some of the threats and vulnerabilities that may be truly important in your setting or context. And as we know, any assessment without a clear and contextual consideration for the real world threats and vulnerabilities is not really a risk assessment. You may just have spent a good amount of money on the consultant but probably do not have much to show for it in terms of the only metric that matters in an assessment – the number of “real” risks identified and their relative levels of magnitude –  so you can make intelligent risk management decisions.

In closing, let us not allow ourselves to be blindsided by the so called “Best Practices” and Security Controls Frameworks. Meaningful security risk management requires us to look at the threats and vulnerabilities that are often unique to each of our environments and contexts. What may have been considered a best practice somewhere else or a security framework put out by someone may at best be just a reference source to double-check and make sure we didn’t miss anything. They should never be the sole source for our assessments and certainly not the yardstick for our decision making in security.

I welcome your thoughts and comments.

Important notes and sources for reference

  • I used HITRUST CSF only for an example. The idea discussed in this post would apply to any set of Best Practices or Security Control Frameworks. After all, no set of Best Practices or Security Controls Frameworks and no matter how good their “quality” may be, they can’t keep up with the speed at which today’s security threats are evolving or new vulnerabilities are discovered.
  • If you are interested in learning some really useful information on password hashing and password management, I would strongly recommend this post (Caution: It is not a quick read;  Allow yourself at least 30 minutes to read and absorb the details especially if you are not a experienced security professional)

A Second Look At Our Risk Assessments?

I came across this Akamai Security Blog post recently which I thought was a useful and informative read overall. As I read through the blog post however, something caught my attention. It is the phrase “The vendor considers the threat posed by the vulnerability”.  That prompted me to write this post …. on the need for extreme due diligence in security risk assessments and the critical importance for the engagement sponsors to keep the assessment teams on their toes. (Note: Just to be doubly clear, the objective here is not to pick on the Akamai post but to discuss certain key points about Security Risk Assessments)

When it comes to Security Risk Assessments (or Security Risk Analysis if the HIPAA Security Rule is of any relevance to you), I believe that terminology is extremely important. Those of us who have performed a “true” risk assessment know for a fact that the terms threat, vulnerability, likelihood, impact and risk mean specific things. In the case of this specific Akamai post, I think the author may have used the word “threat” instead of “risk” somewhat inaccurately. While it may not be significant in the context of this particular blog post, I believe that using these terms inaccurately can mean all the difference in the quality and usefulness of actual risk assessments. In my experience, more often than not, such misplaced terminology is a symptom of the lack of due diligence on the part of the person or the team doing the assessment. Considering that risk assessments are so “foundational” to a security program, we strongly recommend addressing such redflags very early in a Risk Assessment engagement.

In fact, I would like to suggest that the sponsors ask the following questions of the consultants or teams performing the risk assessment as early as pertinent in the engagement:

  • Have you identified the vulnerabilities accurately and do you have the evidence to back up your findings?
  • Have you identified all the relevant threats that can exploit each vulnerability?
  • How did you arrive at the likelihood estimation of each threat exploiting each vulnerability? Can you back up your estimation with real, known and published information or investigation reports on exploits over the recent past (say three years)? Did you consider the role of any and all compensating controls we may have in possible reduction of the likelihood estimates?
  • Does your Risk Ranking/Risk Statement clearly articulate the “real” risk (and not some imagined or assumed risk) to the organization, supported by the Likelihood and Impact statements?
  • When proposing risk mitigation recommendations, have you articulated the recommendations in actionable terms? By “Actionable”, we mean something that can be readily used to build a project plan to initiate the risk mitigation effort(s).

If answers to any of the above questions seem negative or even tentative, the assessment may not be serving the organization’s risk management objectives. In my experience, most risk assessments turn out be no more than mere Control or Gap Assessments, which don’t need to be conducted by the often “Highly Paid” consultants, quite frankly. 

A “true” risk assessment requires to be performed by a security practitioner or team that has the inquisitive mind, depth and breadth of relevant security skillsets as well as the knowledge of current security threat/vulnerability environment.

You may also find the following posts from our blog relevant and useful:

Top 10 Pitfalls – Security or Privacy Risk Assessments
Compliance obligations need not stand in the way of better information security and risk management
Next time you do a Risk Assessment or Analysis, make sure you have Risk Intelligence on board

Please don’t hesitate to post your feedback or comments.

Focus On What Really Matters – Outcomes and Results

Here is something to think about as a security/privacy consultant or consulting team, big or small …

When you work on client consulting engagements, what are you really focused on? 

  • Is it just your methodology, the “quality” of your documentation deliverables or implementing a piece of technology?  
  • Are you also thinking about the immediate and long term value to the client in terms of definite outcomes? By outcomes, I mean the results that should really matter in security/privacy profession (i.e.) specific reduction in security or privacy risks

Based on what I see of the Information Security and Privacy engagements, most consultants are so fixated on the former and just don’t get themselves to think much of the latter. 

Here is something I would urge all consultants to do – Go back and talk to your clients that you have worked with over the past few years. Do a honest evaluation of how useful your engagement  deliverables have been to the client, in terms of the outcomes that really matter (i.e.) the extent to which the deliverables have helped the client reduce security/privacy risks (risk of regulatory non-compliance included).  Assuming that the client has indeed benefitted by way of the outcomes, do you honestly think the benefits were worth the dollars the client paid you?

I see one too many engagement deliverables of even “big name” consultants ending up as just “shelf-ware”. I have noticed this trend especially with engagements related to risk assessments and development of specific security or privacy strategies. In almost all cases, I would attribute the failure to a lack of understanding by the consultant regarding what “really matters” to the client. I also suspect in some cases that the consultant didn’t bring the “right” people to the engagement and perhaps failed to provide a quality oversight or leadership to the Engagement Team. In some extreme cases, I believe the consultant was trying to blindly leverage template deliverables from elsewhere. In other words, they were trying to fix a square peg in a round hole, as it were.

Now..  I know there are many consultants or consulting teams that would argue that it is not (at least not entirely) their responsibility for all of the client outcomes once they were no longer working with the client. While that may be true, I would argue that it is your responsibility to leave the client buyer or sponsor with a list of actionable objectives that the client needs to work further if he/she were to realize the expected outcomes.  And of course, your deliverables should have been good and conducive enough in the first place for the client to execute effectively towards those outcomes.

So, what do we need to do to stop this trend? Here are some thoughts:

  • Right from the first conversation with the client, focus on client outcomes and how the client may measure those outcomes
  • Based on the outcomes, agree upon appropriate deliverables. Don’t include deliverables for the sake of deliverables
  • When signing the engagement letter, make sure to include a section on measurable outcomes and how your engagement deliverables may help the client in realizing those outcomes subject to the client taking some specific actions.
  • Coach your engagement team to always have a keen eye on how every task they perform during the engagement is going to help what “really matters” to the client (i.e.) achieving the outcomes
  • Don’t be wedded to your methodology and deliverable templates. They are only as good  as how much they will help the client realize the outcomes.
  • As part of each deliverable, include a section on next steps that are required to be taken to realize one or more agreed outcomes identified in the engagement letter. Make sure to arrive at an agreement with the client sponsor regarding next steps before finalizing the deliverable.
  • At the end of the engagement, leave the client with a mutually agreed “Plan for Realization of Outcomes”, a set of actionable tasks that everyone agrees will be essential to achieve the outcomes identified in the engagement letter

Following these steps has served us well over the years. I’ll be interested in readers’ feedback.