Model Driven Security Policy Automation

On this blog, ObjectSecurity co-founder and CEO Ulrich Lang discusses security policy automation and model-driven security. The aim of this blog is to advocate advance the state of the art in this area through exchange of ideas. www.modeldrivensecurity.org - www.policyautomation.org - www.objectsecurity.com

Friday 29 July 2011

Analysis Series: HIPAA Security Rule & Privacy Rule and “minimum necessary” access

Today I would like to discuss what the “minimum necessary” access control in the Health Insurance Portability and Accountability Act (HIPAA) of 1996 really means and how such least privilege technical access control can be effectively implemented. The US government's HIPAA website explains:
  • The “HIPAA Privacy Rule” establishes regulations for the use and disclosure of Protected Health Information (PHI),in particular it requests the implementation of least privilege: “A central aspect of the Privacy Rule is the principle of “minimum necessary” use and disclosure”. A covered entity must make reasonable efforts to use, disclose, and request only the minimum amount of protected health information needed to accomplish the intended purpose of the use, disclosure, or request. A covered entity must develop and implement policies and procedures to reasonably limit uses and disclosures to the minimum necessary, i.e. a covered entity may not use, disclose, or request the entire medical record for a particular purpose, unless it can specifically justify the whole record as the amount reasonably needed for the purpose.“
  • The “HIPAA Security Rule” also limits uses and disclosures of PHI to the "minimum necessary," the Security Rule’s administrative safeguards section requires a covered entity to implement and periodically assess policies and procedures for authorizing access to e-PHI only when such access is appropriate. Interestingly this administrative (i.e. non-technical) section specifically states that this should be implemented “based on the user or recipient's role (role-based access)”. The technical safeguards section mandates access control “A covered entity must implement technical policies and procedures that allow only authorized persons to access electronic protected health information (e-PHI), and must “record and examine access and other activity in information systems that contain or use e-PHI.”
To technically implement least privilege access based on the “minimum necessary” for the particular “use, disclosure, or request”, technical access control must be fine-grained and contextual (e.g. based on the context of the access, the business process the requester or the patient is in, the way information is aggregated across interconnected IT systems etc.). Role-based access control (which is mentioned in the administrative section, not the technical section!) is an insufficient technical mechanism because it is not contextual enough to only grant access when needed for the particular use.
Instead, fine-grained, contextual authorization management (AM) is needed to enforce such policies. The challenge with AM is that policies are hard to author and maintain - there are simply too many technical rules, and maintaining those is too time-consuming, expensive, difficult, and error-prone. Also these technical rules will often not directly match with the human thinking about business security policies.
To solve that policy maintenance show-stopper, model-driven security (MDS) policy automation is also needed, which automatically generates technical security rules from generic security policy requirements (models) that capture, for example, HIPAA security & privacy requirements. MDS takes these models, analyzes information sources such as business processes, applications and interactions, user information and other sources, and automatically generates the technical policy rules enforced by the AM. Most importantly, MDS can automatically update the rules when users, business processes, and applications change.
Model-driven security (MDS) policy automation with fine-grained authorization management (AM) are a critical unique combination to make this happen. The award-winning ObjectSecurity OpenPMF   is the only MDS + AM product in the market. It is adopted by organizations with the most stringent security requirements, including US Navy. We are currently completing a study and a scientific publication where a number of regulations have been analyzed in a similar fashion. Please contact us if you would like further information or if you have any questions/comments.
In conclusion - better adopt effective technical mechanisms to implement the requirements effectively. Just because "best" practices for HIPAA currently do not implement “minimum necessary” effectively does not mean that your organization will get away with it when things go wrong!

Friday 15 July 2011

Analysis Series: PCI DSS - what it says & what it means

I am delighted to announce a new "Analysis Series" on this blog: Over the next couple of months I will publish numerous insights from a recent gap analysis of security standards and guidance documents. The gap analysis is currently being carried out as part of ObjectSecurity's cloud security gap analysis project.

Today I would like to share my view of what Payment Card Industry (PCI) Data Security Standard (DSS) version 2.0 has to say about access control and technical policy implementation. It says that "restricting access is crucial!", and the main point is covered here

Requirement 7: Restrict access to cardholder data by business need to know
To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job.
7.1 Limit access to system components and cardholder data to only those individuals whose job
requires such access.
7.2 Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.


This clearly states that access policies need to be contextual by the job (not job role!) - so for example, if someone ("Alice") needs access to some customer's ("Bob") payment information for the job of charging Bob, the technical access policy implementation needs to make sure that Alice is actually involved in a sales transaction related to Bob, and that Alice is at the "charge the customer" step in the sales business process. This is called "context". It is important to understand that Alice should not have blanket access to all customer's payment data because she might potentially have a transaction with any customer when they call and buy something. In that case, "need to know" would not be fully implemented.

This example makes clear that role-based access control (RBAC) and user account management are not suffient technical mechanisms to implement PCI-DSS. Instead, fine-grained, contextual authorization management (AM) is needed to enforce such complex policies. The challenge with AM is that policies are hard to author and maintain - there are simply too many technical rules, and maintaining those is too time-consuming, expensive, difficult, and error-prone. Also these technical rules will often not directly match with the human thinking about business security policies.

To solve that policy maintenance show-stopper, model-driven security (MDS) policy automation is also needed, which automatically generates technical security rules from generic security policy requirements (models) - for example captured in models close to the understanding of PCI-DSS Requirement 7. MDS takes these models, analyzes information sources such as business processes, applications and interactions, user information and other sources, and automatically generates the technical policy rules enforced by the AM. Most importantly, MDS can automatically update the rules when users, business processes, and applications change.

In conclusion - start solving the real challenges instead of "something else". Don't wait until CISO means "Career is suddenly over". Better adopt effective technical mechanisms to implement the requirements. Just because "best" practices for PCI-DSS do not implement PCI-DSS correctly does not mean that your organization will get away with it when things go wrong.

Model-driven security (MDS) policy automation with fine-grained authorization management (AM) are a critical unique combination to make this happen. The award-winning ObjectSecurity OpenPMF is the only MDS + AM product in the market. It is adopted by organizations with the most stringent security requirements, including US Navy. Please contact us if you would like further information or if you have any questions/comments.