Tag Archives: hitech

Compliance mandates do not make up your enterprise security program (PCI, SOX, GLBA, etc.. included)

A challenge for large businesses is addressing their own information security needs to manage their operations in a manner that allows them to be resilient and adaptable in an ever competitive market place.  Each organization is different – the risks and the needs to mitigate.  A painful evolution of the past decade has been the mistaken direction organizations have taken to build / address singular compliance instances.  Meaning, organizations develop programs to address single compliance requirements – vendors, SEC, industry, etc …  Not that these are not important, but a natural effect of this is the perception that the security “controls” (even the word doesn’t lend itself in the right non-audit light) are there to achieve compliance.

The mistake is achieving compliance to compliance requirements alone.  There is a gap in the business’ OWN needs.  Over the past year I have spoken on this topic publicly at conferences and my book  has a huge focus on aligning and establishing business requirements cohesively.

To elaborate on the graphic … the CxO office must be aware and share their strategy – typically easy to find, as I generally begin building these programs from the 10-k reports over last two years.  These feed the information security program elements and form the decision framework against all technology, security controls, risk frameworks, sourcing considerations, recovery timelines, etc…  In addition, the compliance elements must be addressed – but with the understanding these are risk transfer activities by third parties.  Not to be the basis of the enterprise program, but a singular consideration.

The capability of the organization to address market competitive requirements is based upon the proper balance.  Here you can see the target is 85% of the program is made up by the business’ own innovative and market driving / supporting activities.  15% of the program to meeting these ‘license to operate’.

The takeaway is to challenge your organization’s singular managed compliance initiatives and a deep dive on budget alignment to business revenue generation.  There must be rationalization to the safeguards to make the business efficient and effective – that includes safeguarding and enabling the business to conduct business, everywhere.

Thoughts?  Challenges?

James

Advertisements

Enforcement of HIPAA / HITECH violations and how to improve

A great challenge with gaining massive industry adoption of a set of standards – regardless of security, privacy, or operational effectiveness measures is making it worthwhile.  Some aspects of regulation and industry led practices are obvious and clear.  Others are strikingly similar (duplication in many instances) and can be adopted simply by communication and adjustments.  Unfortunately there are specific requirements that are not sufficient alone as self-evident, and these are then made necessary through fines and punitive actions.

HIPAA / HITECH components are absolutely valuable to the consumer, the individual enterprise, and the industry as a whole.  This is true when the directives are merged into the existing culture, and the business is able to remain competitive.  There are challenges of course when a business tries to bolt-on a set of requirements, as these are seldom done efficiently, effectively, and are generally unsustainable.

The financial damage to industry is clear – the most recent studies show over the past 5 years data breaches have cost victims $139 billion (Digital Forensics Association).  In addition there is a growing trend of enforcement by state and the federal agencies, such as the California DPH actions (audio teleconference file).

When these enforcements are released though there is always valuable intelligence released highlighting what is expected – today.  This perspective reinforces that security mandates’ intent are to secure the data, and businesses must shift and respond as the attack vector shifts and evolves.  The recent Rite Aid $1,000,000 penalty enforced by the OCR and FTC provided the following direction:

  1. Implementation of complete and sufficient Policies and Procedures is critical – specifically must include safeguarding PHI during the disposal process (dumpsters, shredding, disk wipe management, third party terminations)
  2. Develop complete training related to all aspects for protection of sensitive information – job specific training
  3. Develop, implement, and maintain sanctions policies

A nice article regarding Rite Aid is available here from Information Week.

As has been consistent with prior Federal enforcement, a 20 year expectation of independent security assessments is required with sufficient monitoring and triggering.  Here is the link to the Federal press release.  Other case examples and resolutions are available here.

As the data suggests that 395,000 individuals’ data files are being stolen daily, this is not a focus on the Healthcare sector but to provide lessons learned from others.

Highlights and interesting mentions within the HHS Health Information Technology Implementation Guidance Documents

The Human Health Services (HHS) released two lengthy documents outlining the final rules for applicability to security and privacy.  The two documents reviewed are:

  1. Medicare and Medicaid Programs: Electronic Health Record Incentive Program
  2. Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology

The length is deceiving (1,000+ pages) – the final rules are not very long comparatively, but these documents contain the comment response sections.  These are massively important for understanding the intent and thoughts behind each requirement.  This public feedback and public response is a welcomed process – especially within the complex world of information technology.

While diving through these documents several sections struck me as helpful and insightful.  I have included those below for reference and comment:

“This means that to qualify for incentives, an eligible professional or eligible hospital must both adopt Certified EHR Technology and demonstrate meaningful use of this technology.”

Interesting clarification on the scope of this publication:

“The purpose of this final rule, therefore, is to adopt standards, implementation specifications, and certification criteria to test and certify that a Complete EHR or EHR Module provides certain capabilities, and where applicable, to require that those capabilities be implemented in accordance with adopted standards and implementation specifications. The adopted standards, implementation specifications, and certification criteria were not intended to impose independent requirements on the entities using Certified EHR Technology.”

A request was made to provide clarity in moving forward guidance and mandates. This was a timely question given how often the final rule and responses provided reference future publications and related legislation.  The question submitted to HHS:

“…timelines for making changes to HIT, that it would benefit the HIT industry if we could provide a roadmap, framework, or more descriptive “glide path” for future standards adoption activities…”

Response:

“We plan to work closely with the HIT Standards Committee to develop a forward looking agenda and to make known in advance the types of standards, implementation specifications, and certification criteria on which we will seek
recommendations from the HIT Standards Committee.”

The concept of Complete EHR was clarified and provides useful guidance on what is included and what is excluded from the implied completeness of the term:

“…however, does not in any way preclude any additional capabilities from being included in a Complete EHR or implemented in a complementary fashion.  The definition sets forth a floor, not a ceiling, and serves to signify that once tested and certified to all applicable certification criteria, a Complete EHR meets the definition of Certified EHR Technology.”

A comment was proposed to HHS regarding the scope and legality of these new standards as they are promoting better security and equally more detailed requirements than are mandated within HIPPA.

“What a HIPAA covered entity must do to remain in compliance with the HIPAA Security Rule is separate and distinct from the capabilities that a Complete EHR or EHR Module must include in order to be certified. We do not believe that we are precluded by the HITECH Act from adopting certification criteria that go beyond the requirements specified by the HIPAA Security Rule. We believe that the HITECH Act, while directing that standards, implementation specifications, and certification criteria be consistent with the HIPAA standards, authorizes the Secretary to adopt certification criteria more broadly for the electronic use and exchange of health information. Section 3004(b)(1) of the
PHSA, as added by the HITECH Act, requires the Secretary, for instance, to adopt an initial set of standards, implementation specifications, and certification criteria to enhance the interoperability, functionality, utility, and security of health information technology.”

A distinction was made regarding encryption, but can provide insight onto the broader intent of these certification technologies that is a key understanding to practitioners. The question is of capability versus necessary. This concept highlights the importance of a thorough and accurate risk management process holistically across the enterprise. The referenced quote is below:

“Certified EHR Technology must include the capability to encrypt and decrypt information regardless of the transmission method used. This certification criterion and related standard do not specify the circumstances under which encryption and decryption must be performed; they simply require the capability.”

As interesting documents surface during my research into these mandates and technology controls I will post them.

James DeLuccia

Symantec’s 2010 State of Enterprise Security

The 2010 survey is complete and I have dug through and have the following thoughts to offer.  First off though – thank you to Symantec for making the information so readily available.  They have provided the slides via slideshare, the PDF report, and the press release.  My efforts below are not to reproduce the report, but instead to carry the ideas and findings one step further.  In addition, my hopeful final goal is to challenge the report and certain aspects of the findings in the spirit of relative context.

“Enterprise security is IT’s top concern” – when compared to the other options listed in the survey I do not find this impressive, as digital threats are the most direct concerns.  On page 5 of the report though the detail about 94% of businesses expect to change their cyber security efforts and 48% are planning major changes is impressive.  That highlights the intelligent repositioning of enterprises and the continued focus on remaining engaged with the threats and not passive.  This also likely has correlation to businesses increased focus on deploying greater information technology throughout the business, and throughout the expanding consumer / business markets.  Major changes are a natural result in these cases.

“Enterprises experiencing frequent attacks” – 75% of business experienced a cyber attack within the past 12 months is a significant figure.  If a cyber attack is considered an event that “activates” the incident response teams and / or forensic groups that is a significant cost and concern.  Attacks, as every firewall administrator and Grandmother who gets a virus, occur non-stop online, so it is important to qualify and scale these attacks by crtiicality.  This is an important fact in the survey, but more important in the enterprise.  The help desk of most organizations is ably suited to respond to malware infections and queuing systems for remote desktop configuration refreshes.  For situations that involve a lose of trust for a specific system resulting from extended malware infection, odd behavior, or log evidence of unauthorized access – these systems should activate the appropriate resources to address these risks directly.

Most problematic IT initiatives from a Security standpoint:

  • Infrastructure-as-a-Service
  • Platform-as-a-Service
  • Server Virtualization
  • Endpoint virtualization
  • Software-as-a-Service

The common thread of these initiatives is the abstract nature of the actual computing system.  Whether virtual or processed within a distributed computing environment the necessity to translate information security safeguards is not automatic.  In fact, most conversions into these initiatives highlights the inherent weaknesses that are present in the existing infrastructure, but were addressed through compensated / ad-hoc controls.  Therefore, while difficult the net risk posture will improve.  Another perspective is the organizational shift that occurs when network/system operators become service delivery specialists.  This cultural swing away from computing system management to application procurement and service management requires careful attention, training, and tight feedback cycles.

The report concludes with some strategic recommendations that are worth reviewing and confirming are currently in operation.

Overall the statistics and findings are in-line with concerns and challenges enterprises have been addressing last year.  The survey provides a nice update and is certainly useful.  As in any survey, consider the source and recognize that your environment is unique.  Such individuality of computing systems by its very nature requires a custom and reflective approach to managing risk and security within the organization.

Best regards,

James DeLuccia