Monday Nov 09, 2009

Best Practices for the IAM/Compliance Journey

As explained in my recent post, I am awaiting final publication of a white paper I recently authored, entitled, “Identity and Access Management – Enabling HIPAA/HITECH Compliance.”  This post is a excerpt from that paper.

In the thirteen years since the initial passage of the HIPAA act, practical experience in the field has yielded several recommended best practices for implementing IAM systems to enable HIPAA/HITECH compliance. We recommend the following:

  1. Understand requirements. By developing a better understanding of compliance requirements, how compliance affects information technology (IT), and how IT in general and IAM specifically can help support the privacy, security and notification requirements of HIPAA/HITECH, companies can establish efficient, cost-effective, and sustainable programs that address all of these complex requirements within a holistic compliance framework.

  2. Recognize IT's critical role. In many companies, IT has evolved to become the critical backbone behind almost every operation, but many people still view technology as a cost rather than an investment or asset. By understanding the key roles that IT plays in support of HIPAA/HITECH compliance, enterprises can maximize the value of their technology investment.

  3. Understand the role of IAM. IAM plays a critical role in compliance with HIPAA/HITECH privacy, security and notification requirements.. However it does not automatically satisfy all HIPAA/HITECH requirements. Recognizing the value and the limitations of IAM in the entire spectrum of HIPAA/HITECH compliance is essential.

  4. Think program, not project. HIPAA/HITECH compliance is a journey, not a short term event. Enterprises must begin to approach compliance as a long-term program, not a single project. An effective and holistic compliance program should also incorporate governance and risk management. Boards of directors and executives are frequently being held to higher standards than ever before as they are expected to be knowledgeable about, and held liable for, everything going on within the enterprise.

  5. Establish privacy and security policy. A success privacy and security program requires a documented set of principles, policies, and practices. Using the Nationwide Privacy and Security Framework for Electronic Exchange of Individually Identifiable Health Information as a guide, the enterprise's privacy and security principles should be documented as a foundation upon which to build policies, practices and strategies.

  6. Develop a strategy. The only way to effectively address the wide spectrum of compliance requirements is to integrate them into a common compliance strategy that is intertwined with the business itself. A business-driven, risk-based, and technology-enabled compliance strategy can help create enterprise value by rationalizing unnecessary complexities, driving consistency and accountability across the enterprise, and identifying opportunities for a possible enhancement of operational performance and information quality.

  7. Collaborate. HITECH extends compliance responsibility and penalties to all business associates. Work closely with your vendors and business partners to form an overall security and privacy framework, including updating legal relationship documents as ncessary.

  8. Establish a governance process. Compliance efforts affect a broad spectrum of an enterprise. Stakeholders from many organizations, often with conflicting priorities, have vested interests in the outcomes of a compliance strategy. The governance process must provide representation from the impacted functional areas of the organization. A governance board should have appropriate representation from IT, security, audit, application owners, human resources, business process owners and applicable business associates. The board should be accountable for the project objectives and be vested with authority to make program decisions. The board should be empowered to 1) establish a statement of purpose for the program, 2) promote and give visibility to the program throughout the larger organization, 3) act as a mechanism for quickly making decisions regarding program scope, issues, and risks, and 4) monitor the program health on an ongoing basis.

  9. Implement your strategy in phases. By segmenting the overall solution into manageable parts, an organization can realize quick, visible business benefits and progressively realize overall program objectives in an orderly, measurable way. Implementing in manageable phases also makes it easier to battle issues such as scope creep or requirements drift.

  10. Standards. Follow the NIST and other applicable standards for electronic healthcare records. Adjust to form a compliance model with this emerging standard. Focus on open standards and vendors that are open standards compliant to insure long-term flexibility of computing platforms and security frameworks.

  11. Give real-time visibility. Real-time views into the functioning of controls across these systems and across the enterprise, through job-specific dashboards or portal views, can provide insight into compliance status, progress, and risks. Effective communications with all stakeholders is essential.

  12. Unify disparate compliance efforts. Many companies are beginning to realize the potential of technology to support sustained compliance and are actively looking to combine existing fragmented, reactive, and inefficient governance and compliance efforts into a single sustainable compliance program. Bringing together compliance, governance, and risk management under a holistic framework, can result in a centralized compliance organization with the understanding, structure, and ability to help optimize the company’s compliance efforts in a sustainable, strategic, and cost effective manner.

  13. Assess progress and adjust as necessary. Each phase of the progressive implementation of the compliance strategy will yield more in-depth understanding about the compliance process as it pertains to the specific enterprise. Implementing methods of continual process improvement will yield progressively refined results.

Please let me know what you think.  What have you found that really works in this IAM/Compliance Journey?

The Role of IAM in HIPAA/HITECH Compliance

I recently authored a white paper entitled, “Identity and Access Management – Enabling HIPAA/HITECH Compliance.”  The paper is now in the final editing and formatting process.  As we awaiting the final publishing date, let me share an excerpt from the paper, focused on the key ways IAM enables HIPAA/HITECH compliance.

HIPAA/HITECH requirements for privacy, security, auditing and notification are supported directly by IAM. By streamlining the management of user identities and access rights and automating time-consuming audits and reports, IAM solutions can help support strong privacy and security policies across the enterprise and throughout Health Information Networks while reducing the overall cost of compliance.

IAM provides the following key enablers for HIPAA/HITECH compliance:

  1. Assign and control user access rights. Securely managing the assignment of user access rights is critical to HIPAA/HITECH compliance, particularly in distributed and networked environments typical of modern healthcare business. Decentralized provisioning is not only inefficient and costly, it also increases the risk of security and privacy violations. Automated provisioning allows centralized control of resources and applications that have historically existed in silos. This provides a much greater level of control over access to those resources. Checking audit policy at the time or provisioning ensures regulatory compliance, thus preventing audit policy violations.

  2. Adjust user access rights when responsibilities change. Business risk is introduced when employees change jobs and access isn’t appropriately adjusted or removed. Failing to appropriately adjust or remove users’ access when job changes occur can result in superuser-access and SOD violations. Automated provisioning effectively eliminates many of these risks, especially when combined with auditing and role management capabilities.

  3. Revoke user access upon termination. IAM systems can automate the process of immediately revoking user access rights upon termination or suspension. This eliminates a commonly-exploited security gap and opportunity for policy violation that may occur after an employee or contractor has been dismissed.

  4. Manage allocation of user credentials. Managing user names, passwords and other user access credentials is essential to assuring that only authorized users are granted access to information systems. IAM technology can provide enterprise-wide control of user credentials, including the enforcement of uniform password policies (e.g. password strength, periodic change).

  5. Enforce segregation of duties (SOD) policies. Segregation of duties (also known as separation of duties), has as its primary objective the prevention of fraud and errors. This objective is achieved by disseminating the tasks and associated privileges for a specific business process among multiple users. IAM methods can prevent, detect, and resolve access rights conflicts to reduce the likelihood that individuals can act in a fraudulent or negligent manner. Once violations are identified, notification and remediation steps are automatically initiated based on corporate policies.

  6. Provide uniform access policy. IAM can provide administration and enforcement of common user access policies across a wide span of diverse systems, improving executive confidence in how the enterprise complies with HIPAA/HITECH requirements.

  7. Manage access based on business roles. Provisioning and auditing at the business role level, rather than just at the IT access control level, ties user access rights more closely to business processes. With a role management solution, managers can approve access rights that have a meaningful business context, thus reducing the risk of managers inadvertently creating SOD violations by granting carte blanche access to their direct reports.

  8. Enforce secure access policies. While automated identity administration, provisioning and auditing are essential to HIPAA/HITECH compliance, these methods don't actually enforce the use of security policies when a user accesses the controlled systems. IAM Access Management technology can enforce user access policy at the point of entry to an application or other system, in harmony with established policy. Examples of such enforcement include Web access management (including single sign-on or SSO), enterprise single sign-on (ESSO), and Web service security.

  9. Enforce informed consent principles. Informed consent principles (e.g. opt-in, opt-out, notice) can be enforced, based on identities of individual patients and potential users of personal information associated with such data.

  10. Extend access control to business associates. Identity Federation can extend access control beyond enterprise boundaries to enable secure access to electronic records while safeguarding the privacy of sensitive information. This is essential to complied with extended requirements of HITECH.

  11. Verify access rights. While automated user access provisioning is designed to accurately assign access rights, such access rights should be confirmed by audit. IAM can provide the ability to both assign access rights according to established polices and then periodically verify that access rights are still compliant with those same policies.

  12. Conduct periodic compliance assessments. Periodic audits of access rights and privileges can assure that security and privacy policies are consistently enforced. Re-certification is a process where managers approve direct reports’ access to enterprise resources and applications. IAM can provide the ability to automatically present managers with the correct information to attest to each employee's access rights needs. By applying role management principles, this re-certification process can enable the approving manager to work at the business-role level, attesting to those entitlements quickly and accurately because they are given in a meaningful business context.

  13. Provide automated reports. The delivery of accurate, timely and complete reports can assess compliance with established requirements. IAM can provide scheduled and ad-hoc compliance reports, including automated violation notifications, comprehensive work flow processes, and audit assessment reports. Such reports can generated across multiple systems and enterprise applications and be submitted to appropriate people within the enterprise, to business associates and to appropriate regulatory agencies.

I’ll share more excerpts soon and let you know when the full paper is ready for download.  Please stay tuned.

Friday Sep 11, 2009

Privacy Principles Depend on Context

It is an interesting exercise to Google the term “Privacy Principles” and review the different definitions of privacy and different lists of fundamental privacy principles established by various enterprises, organizations and government agencies.  While there are threads of commonality throughout these different lists, it is intriguing to see how different perspectives can emphasize different issues.

For example, at the Burton Group Catalyst Conference in July, Bob Blakley proposed the following list of privacy principles (further described in the white paper, “Privacy” by Ian Glazer and Bob Blakley, which is available by subscription):

  1. Accountability
  2. Transparency
  3. Meaningful choice
  4. Minimal collection and disclosure
  5. Constrained use
  6. Data quality and accuracy
  7. Validated access
  8. Security

In December, 2008, The U.S. Department of Health and Human Services issued guidance on how to conform with HIPAA privacy and security requirements. This guidance consists of the Nationwide Privacy and Security Framework for Electronic Exchange of Individually Identifiable Health Information, which also sets forth eight Privacy Principles:

  1. Individual Access. Individuals should be provided with a simple and timely means to access and obtain their individually identifiable health information in a readable form and format.

  2. Correction. Individuals should have a way to timely question the accuracy or integrity of their individually identifiable health information and to have erroneous information corrected or to have a dispute documented if their requests are denied.

  3. Openness and Transparency. There should be openness and transparency about policies, procedures, and technologies that directly affect individuals and/or their individually identifiable health information.

  4. Individual Choice. Individuals should be provided a reasonable opportunity and capability to make informed decisions about the collection, use, and disclosure of their individually identifiable health information.

  5. Collection, Use, and Disclosure Limitation. Individually identifiable health information should be collected, used, and/or disclosed only to the extent necessary to accomplish specified purposes and never to discriminate inappropriately.

  6. Data Quality and Integrity. Persons and entities should take reasonable steps to ensure that individually identifiable health information is complete, accurate, and up-to-date to the extent necessary for the person's or entity's intended purposes and has not been altered or destroyed in an unauthorized manner.

  7. Safeguards. Individually identifiable health information should be protected with reasonable administrative, technical, and physical safeguards to ensure its confidentiality, integrity, and availability and to prevent unauthorized or inappropriate access, use, or disclosure.

  8. Accountability. The Principles in the Framework should be implemented, and adherence assured, through appropriate monitoring and other means and methods should be in place to report and mitigate non-adherence and breaches.

You can see both similarities and differences in these lists. 

Ian and Bob observed in their report that privacy is highly dependent on the context in which it is applied:

Privacy is, fundamentally, contextual. Any question about privacy must be understood in the context of:

  • The starting assumptions and principles of the parties
  • The relationship between the parties
  • The interaction between the parties among which private information is shared
  • The domain (e.g., sector, nation, etc.) in which the parties are interacting
  • The societal norms to which the parties adhere

Minor variations in any one of these contextual aspects of the situation can lead to major differences in the
privacy practices that should be applied.

So, while on the surface one might expect that a standard set of privacy principles would apply in all cases, each enterprise, market or agency must view privacy from their own slightly different perspective, based on the context within which privacy principles are applied.  Normalized lists of privacy principles may provide a valuable foundation, but it is critical for each enterprise or organization seeking to implement an effective privacy program to establish their own list, depending on their context.

Technorati Tags: ,

Thursday Sep 10, 2009

"Anonymized" Data Really Isn't

I enjoy watching re-runs of the television drama, NCIS, where a dysfunctional little group of crime-fighting superstars often analyze divergent bits of data to solve seemingly unsolvable mysteries.  Last night, Agent McGee correlated data from phone records, automobile registrations and police station activity records to pinpoint a bad cop in collusion with an international drug lord.  Far fetched?  Perhaps not.

I have been spending much of my time recently preparing a white paper addressing the issues of HIPAA privacy and security compliance, particularly in light of expanded regulations emerging from the “stimulus bill” signed into law earlier this year.  As I have explored privacy issues related to electronic health records, I was particularly intrigued by an article by Nate Anderson entitled “’Anonymized’ Data Really Isn’t and here’s why not”, published in Ars Technica earlier this week.

On the surface, it would seem that removing obvious identifiers such as name, address and Social Security Number from a person’s data record would cause that record to be “anonymous” – not traceable to single individual.  This approach is commonly used by large data repositories and marketing firms to allow mass data analysis or demographic advertising targeting.

However, work by computer scientists over the past fifteen years show that it is quite straightforward to extract personal information by analyzing seemingly unrelated, “anonymized” data sets. This work has “shown a serious flaw in the basic idea behind ‘personal information’: almost all information can be 'personal' when combined with enough other relevant bits of data.” 

For example, researcher Latanya Sweeny showed in 2000 that “87 percent of all Americans could be uniquely identified using only three bits of information: ZIP code, birthdate, and sex."

Professor Paul Ohm of the Colorado School of Law, in his lengthy new paper on "the surprising failure of anonymization, wrote:

As increasing amounts of information on all of us are collected and disseminated online, scrubbing data just isn't enough to keep our individual "databases of ruin" out of the hands of the police, political enemies, nosy neighbors, friends, and spies.

If that doesn't sound scary, just think about your own secrets, large and small—those films you watched, those items you searched for, those pills you took, those forum posts you made. The power of re-identification brings them closer to public exposure every day. So, in a world where the PII concept is dying, how should we start thinking about data privacy and security?

Ohm went on to outline a nightmare scenario:

For almost every person on earth, there is at least one fact about them stored in a computer database that an adversary could use to blackmail, discriminate against, harass, or steal the identity of him or her. I mean more than mere embarrassment or inconvenience; I mean legally cognizable harm. Perhaps it is a fact about past conduct, health, or family shame. For almost every one of us, then, we can assume a hypothetical 'database of ruin,' the one containing this fact but until now splintered across dozens of databases on computers around the world, and thus disconnected from our identity. Re-identification has formed the database of ruin and given access to it to our worst enemies.

I won’t ask what your “blackmail-able facts” might be, and won’t tell you mine.  But it is sobering to think what abuses might emerge from the continued amassing of online data about all of us.  This certainly casts new light on the importance of privacy and security protections for all of our personal data.

Friday Jul 31, 2009

Catalyst Conference, Day 3 (Friday, July 31)

This morning's Privacy Track was the most intellectually stimulating set of sessions for me in the Catalyst Conference.  The blend of theoretical background and practical application of privacy principles was a good combination.  I certainly don't consider myself a privacy expert, so I learned much and and gained valuable perspective, both the point of view as an Identity Management practitioner and as a person who values personal privacy. Hats off to Burton Group for assembling an excellent set of speakers.

Here are the high points for me:

Privacy: Principles Yield Practice
Bob Blakley (Burton Group)
  1. Privacy is not about data, it is about people
  2. Protecting privacy means putting oneself in the place of another and understand the consequences of your actions
  3. Privacy means different things in different contexts
  4. Privacy principles:
    1. accountability
    2. transparency
    3. meaningful choice
    4. minimal collection and disclosure
    5. constrained use
    6. data quality and accuracy
    7. validated access
    8. security
  5. Put principles into context - then derive set of rules
  6. IdM systems have much personal data in them.  Are we protecting the dignity of the people I know things about?


Privacy Issues Related to Healthcare and Identity
Speaker: David Miller (Covisint)
  1. IAM is not a security thing.  It is a privacy thing.
  2. Security is about keeping people out; privacy is about letting the right people in.
  3. Electronic Medical Records (EMR) are being dictated by legislation, but have challenges to overcome, including:
    1. authentication
    2. authorization
    3. data exists in many places
    4. patient access to records depends on many factors
    5. many organizations want access to information
    6. regulatory issues
    7. legal/tort issues
  4. One solution is a central Health Information Exchange (HIE).
  5. Several different organizations at the national, state and health care organization level approach HIE's differently.


Privacy - how to have a productive multi-stakeholder discussion
Robin Wilton (Future Identity Ltd.)
  1. Privacy is usually a multi-stakeholder discussion
  2. It is difficult for stakeholders to articulate their view of privacy problems in a way that other stakeholders understand
  3. Use the "Onion Model" to explore and use levels of importance of personal information
  4. Use the "Ladder Model" to facilitate different viewpoints about privacy
  5. We are doing all this technical interaction in online networking as if it works the same way as face to face interaction, but it does not.
  6. "Privacy management" implies being aware of relationships and contexts, and acting accordingly.
  7. Technology is not an automatic answer to privacy.


A Dual Mission: Identity Management and Privacy Protection in the Federal Government

Bob Mocny, Director, DHS-VISIT Program - Department of Homeland Security
  1. Identity management is critical to national security
  2. US VISIT - check credentials for visitors into
  3. 100 million biometric records used for authentication, 200K transactions/day - largest in the world
  4. Built privacy into architecture of system
  5. Secure facilities and networks are in place to protect privacy
  6. Redress process to correct personal information in the system is essential
  7. No more important condition between the government and the people it protects than trust
  8. US VISIT built trust into the biometric system


Joint Q&A
Bob Blakley (Burton Group)
Bob Mocny (Department of Homeland Security)
Robin Wilton (Future Identity Ltd)
David Miller (Covisint)
  1. Privacy-enhancing governance is difficult (e.g. if you request that your PII be deleted from a list, is your PII still on the audit trail?)
  2. Much explicit effort and systems are necessary to avoid unitended consequences of amassing large amounts of personal information.
  3. People who have grown upon in a hyper-connected, pervasive-surveillance world have tend to have different perspectives of privacy than older people for whom personal information was secret by default.


Partnering via Privacy
Ian Glazer (Burton Group)
  1. Increased regulatory action, higher penalties, more people looking at privacy - all increase the attention companies must focus on privacy.
  2. Increased reliance on partners requires companies to understand privacy practices of partners.
  3. Preform Privacy Impact Assessments (PIA) to determine where we are, how we got here, and how changes can impact risks.
  4. PIA - opportunity to look at mission goals, design goals and privacy principles - are they in alignment?
  5. Reduce privacy risk by "cleaning your basement"
    1. Scary basements (something might be illegal)
    2. Messy basements (policy in place, but not well-applied)
  6. Procurement process is the best place to ask tough questions about partner privacy practices.


The Watchmen: UCLA & Georgetown Protect and Defend Privacy and Data Security
Heidi Wachs (Georgetown University)
  1. Although Georgetown University and UCLA have significant differences in size, organization and operational practices for privacy policy, the incident response process is quite similar
  2. Both suffered significant privacy breaches
  3. Response depends on what data is actually "acquired" vs. how much was "exposed"
  4. Privacy breaches triggered much public press and discussion
  5. New policies implemented quickly as a result of the breach have been difficult to implement


How Google Protects the Privacy of Our Users

Shuman Ghosemajumder (Google)
  1. Google global design principles: transparency, choice, security.
  2. End to end security is an essential part of every Google Service.
  3. Google Latitude: make privacy choices very visible and easily assessible, with opt-out at multiple levels.
  4. Street view: blur faces and license plates automatically, but allow individuals to request blurring if automated process fails.
  5. Interest base advertising: give users control over categories and opt out at different levels of granularity.
  6. Gmail: contextual ads caused concern - because of its proximity to and dependence on personal email.
  7. Data retention: Google anonymizes IP addresses in logs after 9 months.
  8. Google chose paradigm of "opt-in after the fact", rather than offering "opt-in beforehand" to not disrupt the user experience or advertising ecosystem.

Technorati Tags: , , , , , ,

About

Discovering Identity was founded on blogs.sun.com in May 2005 as a means of documenting my exploration of the field of Identity and Access Management. In February, 2010, I switched to hosting the blog at DiscoveringIdentity.com. In March 2012, I began posting Oracle-related information in both places.

Thanks for stopping by.

Please connect with me in cyberspace at LinkedIn or Twitter.


The views expressed on this blog are my own and do not necessarily reflect the views of my employer, Oracle Corporation, or any other person or organization.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today