Monday, December 17, 2012

Creating a Mature Security Program

Last Wednesday I was in Washington DC speaking at the ONC annual meeting and the speaker who preceded me was Leon Rodriguez, Director of the Office of Civil Rights.  On Thursday, I was in Boston speaking at the HIMSS Privacy and Security Forum and the  speaker who preceded me was Leon Rodriguez.  Now that Leon and I are doing roadshows together, I have a broader understanding of the privacy and security enforcement goals of the Obama administration.

As background, here are a few slides from Leon's Washington presentation.

In the past, as an operational CIO, an academic studying approaches to healthcare information exchange, and as co-chair of the HIT Standards Committee, I've focused on security technology (FIPS 140 encryption, ASTM audit trail standards,  two factor authentication, remote access, intrusion detection, zero day defense etc.) and the enabling policies that support best practices.

While this has been effective, as measured by downtime, breaches of devices under IT control, and a balance between ease of use/access restriction, the entire healthcare industry is still on a journey toward security program maturity.

What do I mean?

A mature program uses a framework such as NIST 800 to serve as rubric for stakeholder analysis of risk.   Such a framework ensures that stakeholders consider all the elements of risk and not just the ones that are top of mind for experts in the room.    Risks can be physical security, mobile devices, human factors including staffing levels that concentrate expertise in too few people, configuration policies, and timeliness of audit log reviews.    In the past, many CIOs in healthcare have been given enough security staff to support operations but not enough staff to create the processes, policies, and documentation that reflect a mature, optimized program.

If you take a look at Leon's slides, you'll see that the Office of Civil Rights wants to ensure organizations have done a thorough risk analysis.  I would recommend doing this yearly.  Once the risk analysis is done, stakeholders including Boards and senior management should prioritize risk, develop mitigation action plans, and document their decisions.

Leon and the OCR understand that breaches can occur in effective and mature security programs i.e. no technology can stop an authorized user from using a digital camera to take a photo of protected healthcare information on a computer screen then sharing that photo inappropriately.

OCR wants to ensure organizations have created a culture of compliance that goes beyond security technologies.  It includes education, incident responses, and documented discussion that demonstrate an organization and its staff consider security and privacy as part of their duty and daily work lives.

Leon made very thoughtful comments at both venues.     Although the press has called the HHS log of reported privacy breaches the "Wall of Shame", Leon does not use this term.  A breach is investigated to ensure that the right processes were in place at the affected organization to mitigate risk.    The findings are used to educate the entire industry.  Fines are issued when organizations did not follow the compliance requirements of HIPAA and HITECH, not because of the breach itself.

My take away from this is that all IT organizations should spend the next few years adding polish to their policies, procedures, documentation, education, and process efforts.  BIDMC has embraced NIST 800 for this effort and thus far it is going well.

A final thought.  This work takes resources, both capital and operating.   However, Boards and senior management are likely to be receptive to security resource requests in 2013, since the cost of non-compliance can easily exceed the cost of the additional people needed to create a mature security program.

No comments: