I have blogged for years that model-driven security is an ideal approach for the management of policies that are relatively intuitive for humans, but cumbersome to technically implement across large, interconnected IT landscapes. Privacy policies are perfect examples of such policies – easy to say for example that “I only want my personal information to be collected if necessary for the purpose, only to be used for the purpose, and irrevocably deleted when the purpose has been completed”. However, ensuring this technically involves a major access control infrastructure that, based on rich, contextual policies, controls information flows between applications and systems.

Over the last years, we have discussed the need for an open privacy framework (OPF) that brings together the requirements and the technical implementation, and that is based on the principles of Privacy by Design (PbD) (as well as NIST 800.53a, Appendix J and others).

This blog post discusses the big picture, and details can be found in an IEEE CE magazine article we recently co-authored (“A Cybermodel for Privacy by Design“, Michael H. Davis, Dr. Ulrich Lang, and Sid Shetye).

Our main approach revolves around the idea that:

  • a pure top-down approach to implementing privacy requirements is unrealistic, because privacy requirements are extremely complex and fuzzy (“further processing of personal information should be unsurprising and appropriate” etc.). In a pure top-down approach, non-technical people specify “something”, but there is usually no technical basis or a mapping to implementation. Kind of like a pipe-dream…
  • a pure bottom-up approach to implementing privacy requirements is unrealistic, because privacy implementations require many different technical mechanisms, and a clear understanding of the requirements is needed to choose and integrate the right technologies (and people/processes correctly). Kind of like hacking with no plan…

What organizations need is technology to traceably bridge the gap both ways (usually iteratively) between these human-intuitive PbD policies and concrete technical implementation. Technically, the devil is in the details with making this happen, and the product landscape out there (for example identity & access management – IAM, and attribute based access control – ABAC etc.) doesn’t really meet these requirements well.

Turns out that model-driven security is an ideal technology approach to traceably bridge the gap between these human-intuitive PbD policies and concrete technical implementation. In other words, model-driven security and security policy automation help bridge the gap between the “top” (requirements) and the “bottom” (technologies) well. It is important to go both ways (in iterations) until “top” and “bottom” are aligned.

As part of our privacy efforts (esp. VACLRI), we have set up an open community initiative called privacyontology.org which aims to bring a community together that develops models of privacy requirements and mappings to technical implementations. And if you are interested in reading up on a well-suited example product, check out ObjectSecurity OpenPMF, a security policy automation product which you can easily trial and use as a cloud SaaS, and deploy on-premises.

Here are a few details in the context of model-driven security for privacy:

1) Policy management

Privacy by Design needs a manageable intuitive, user-centric privacy policy authoring feature for users to set their privacy policies governing users, systems, applications, and interactions (information flows). It needs to allow users and administrators to author and/or select privacy policies captured in intuitive models (OMG-style Domain-Specific Languages, DSLs). Model-driven security takes the privacy model, the generated system description, and other information as inputs into the MDS “model transformations” and automatically generates configurations for the various other components of the solution, and fine-grained access rules (which are information-flow based and attribute-based). To solve the management challenges of attribute-based access control (ABAC), and to turn human-intuitive, generic PbD policies into technically enforceable policy rules, we recommend the use of “model-driven security” (MDS) policy automation approaches: MDS helps simplify and automate security policy authoring and management, and automatically generates/updates fine-grained technical policy rules for the full technology stack. MDS is the tool supported process of modeling security requirements at a high level of abstraction, and using other information sources available about the system (produced by other stakeholders).

2) Policy enforcement

Privacy by Design needs a tool that enforces the generated technical privacy rules and configurations across the IT landscape (e.g. using attribute based access control (ABAC) b), across the information lifecycle and software development lifecycle. Model-driven security solves one of the main challenges around ABAC’s various management and implementation challenges. It also needs to alert the proper people that something is happening that needs attention, or take action.

3) Policy compliance

Privacy by Design needs a user-centric tool that lets users verify (audit) that their policies are enforced correctly. This feature analyzes the traceable correspondence between technical security policy implementation (e.g. ABAC) and the information assurance requirements captured in “undistorted” requirements models (e.g. Common Criteria, control objectives). It also documents “supporting evidence” for accreditation/compliance purposes. It helps audit “as-is” processes & controls against the defined security policies for privacy. It uses “model-driven security” accreditation automation approaches to automatically correlate, analyze and document the traceable correspondence between technical security policy implementation and information assurance requirements captured in “undistorted” requirements models.

Please contact us if you have any further questions about model-driven security or Privacy by Design. And please check out the article and the privacy ontology  website and OpenPMF (there are quite a few interesting blog posts and a FAQ on that page).