Re-Examining Identity & Access Management (IAM)

This article was moved to https://www.objectsecurity.com/re-examining-identity-access-management/.

Access Control in 2016 – What you Need to Know

This article was moved to https://www.objectsecurity.com/access-control-2016-need-know/.

Cybersecurity in 2015: Manage Impact!

This article was moved to https://www.objectsecurity.com/cybersecurity-in-2016-manage-impact/.

Implementing Proximity-Based Access Control (PBAC) using Model-Driven Security

This article was moved to https://www.objectsecurity.com/implementing-proximity-based-access-control-pbac-using-model-driven-security/.

"Internet of Things" and Model-Driven Security - a perfect match!

This article was moved to https://www.objectsecurity.com/internet-of-things-iot-and-model-driven-security-a-perfect-match-2/.

Model-driven security (MDS) for Privacy by Design (PbD)

This article was moved to https://www.objectsecurity.com/model-driven-security-mds-privacy-design-pbd/

Externalized Authorization Management (EAM) in the "trough of disillusionment" - Model-driven security is a way out!

Gartner's "Hype Cycle for Governance, Risk and Compliance Technologies, 2014"* puts "Externalized Authorization Management" (EAM) in the "Trough of Disillusionment", stating that "Gartner clients have reported that maintaining a fine-grained access policy across a large number of custom or complex applications can be a daunting and expensive proposition". In line with this, we have discussed many times in most of our own publications for over a decade) is that authoring and maintaining a large number of fine-grained EAM access policies across many applications is expensive, difficult, time-consuming, error-prone, and non-traceable. This is especially true for attribute-based access control (ABAC), which supports extremely rich and flexible access rules.

However, it is important to note that Gartner's "Hype Cycle for Governance, Risk and Compliance, 2014" category is "Externalized Authorization Management", and not model-driven security (MDS) used with EAM. For over a decade, we have shown that MDS is an ideal candidate to resolve EAM's manageability/complexity challenges. Over the years, we have carried out many MDS deployments  (over EAM & ABAC) over the years, implementing highly complex policies. MDS works best if there is a human understanding of the policy that is general, intuitive, simple, and human-intuitive. MDS (like EAM & ABAC) requires access to a number of attribute sources (and often also attribute mappings) to turn this general human understanding of the policy into the detailed technical rules that can be technically enforced (e.g. by EAM, ABAC). This can be a challenge, however the resulting level of automation,  manageability, usability, support for system agility, and traceable compliance by far outweigh the costs.

An example we have recently designed and implemented for a customer is something we tentatively call "relationship-based access control" (RelBAC, we also call this a highly enhanced, multidimensional "proximity-based access control" model) - humans are usually great at expressing general access policies based on the relationship of themselves (or something they are associated with) with something they are trying to access (or something the accessed resource is associated with). Due to restrictions we cannot post too many details here, but please contact us if you would like to hear more about this.

* Gartner, Hype Cycle for Governance, Risk and Compliance Technologies, 17 July 2014, John A Wheeler

Attribute-Based Access Control (ABAC) adoption 70% by 2020 - Model-Driven Security helps make ABAC manageable!

Gartner (Gregg Kreizmann, at the Identity and Access Summit in Nov 2013) forecasts that by 2020, 70% of all businesses will use attribute-based access control (ABAC) as the dominant mechanism to protect critical assets, up from less than 5% today ABAC is about saying which good stuff should be allowed (whitelisting). This is contrary to most of what the security industry does today, which is saying which bad stuff should not be allowed (blacklisting). Blacklisting suffers from many issues, esp. around accuracy (false positives and false negatives).

However, while whitelisting a la ABAC does not have those problems, it frequently suffers from the complexity overload related to the authoring and maintenance/update of the many, complex, changing fine-grained access rules. As a result, ABAC hasn't taken off as much as it should have by now. Another issue is related to the complexity of the ABAC infrastructure: potentially many attributes have to be aligned, and attribute sources (PIPs) have to be plugged into the ABAC system, and the enforcement end (PEP) also needs to be plugged into the information flow. All in all, this is not a minor undertaking. But it is worth the effort in the long run (the same way IdM and PKI only materialized ROI after a while).

Model-driven security (MDS) policy automation is a critically important part of the ABAC story: It allows the specification of human-intuitive, generic, undistorted policy models, and automatically turns those into the fine-grained, technical ABAC rules. Part of the "secret sauce" is that MDS feeds in other information sources into this process to figure out what rules to generate. MDS also allows the automated checking for compliance/accreditation. See the wikipedia article and our website for details.

In summary, MDS fixes some of the complexity issues that become evident when ABAC gets deployed. Oh, and by the way, we are not the only ones saying that: industry analyst firm Gartner identifies model-driven security as part of "Top 10 Strategic Technologies for 2012", and selected OpenPMF, a model-driven security product, as "Cool Vendor 2008" product.

Model-Driven Security possible without Model-Driven Software Engineering? Of course!

Today I want to clarify that model-driven security (MDS) does not necessarily rely on model-driven development to work - even though it relies on application, system, and interaction models (so-called “functional models”) to achieve significant security policy automation. The traditional MDS approach is that these functional models ideally come from manually defined application models authored during model-driven development (e.g. UML, BPMN). But this is not necessary. We have designed an additional solution for our OpenPMF where the functional models are in fact obtained from an IT asset management tool that is part of our partner’s (Promia, Inc.) intrusion detection/prevention product Raven. This works well, and enables the use of model-driven security in environments which do not support model-driven development or where model-driven development is not desired.

While this may not sound like a big deal, it is in fact a big deal, because it increases the widespread applicability of model-driven security dramatically, and makes adoption a lot easier.

"Policy as a Service"

The financial ROI of Cloud security and compliance is judged by decision makers in end-user organizations by the same measures as is done for Cloud computing in general, i.e. by how much it cuts up-front capital expenditure and in-house manual maintenance cost. However, manually translating security policy into technical implementation is difficult, expensive, and error-prone (esp. for the application layer). In order to reduce security related manual maintenance cost at the end-user organization, security tools need to become more automated. With the emergence of Cloud PaaS, it is therefore logical to move all or parts of the model-driven security architecture into the Cloud to protect and audit Cloud applications and mashups with maximal automation. In particular, policies are provided as a Cloud service to application development and deployment tools (i.e. “Policy as a Service”), and policy automation is embedded into Cloud application deployment and runtime platforms (i.e. automated policy generation/update, enforcement, monitoring). Different Cloud deployment scenarios are possible, which differ from local non-Cloud deployments where model-driven security is conventionally installed within or alongside a locally installed development tool (e.g. Eclipse). Policy as a Service (see ObjectSecurity OpenPMF) involves five parts:

1. Policy Configuration from the Cloud: Policy configurations are provided as subscription-based Cloud service to application development tools. Offering specification, maintenance, and update of policy models as a Cloud service to application developers and security experts has significant benefits: Most importantly, instead of having to specify (or buy and install) and maintain the policy models used for model-driven security on an on-going basis, application developers and security specialists can now simply subscribe to the kinds of policy feeds they require without the need to know the details of the models. The Policy as a Service provider (typically different from the Cloud provider) takes care of policy modeling, maintenance, and update. Other benefits are that the user organization does not need to be a security and compliance expert because the up-to-date policy models will be provided as a feed to them on an on-going basis, that the upfront cost hurdle is minimized thanks to the subscription model, and that there is no need by the end user organization to continually monitor regulations and best practices for changes.
2. Automatic Technical Policy Generation in the Cloud: The automatic policy generation feature of MDS is integrated into the development, deployment, and mashup tools (to get access to functional application information). It consumes the policy feed described in the previous section. Platform as a Service (PaaS) sometimes includes both Cloud hosted development and mashup tools and a Cloud hosted runtime application platform. In this case, automatic technical policy generation using model-driven security (MDS) can also be moved into the Cloud, so that technical security policies can be automatically be generated for the applications during the Cloud hosted development, deployment and/or mashup process. This is in particular the case for mashup tools, because those tools are more likely to be Cloud hosted, are often graphical and/or model-driven, and are concerned with interactions and information flows between Cloud services. If the development tools are not hosted on the PaaS Cloud, then the MDS technical policy auto-generation feature needs to be integrated into the local development tools.
3. Automatic Security Policy Enforcement in the Cloud: Policy enforcement should naturally be integrated into the PaaS application platform so that the generated technical policies are automatically enforced whenever Cloud services are accessed. As described in the previous section, policies are either generated within Cloud using hosted MDS and PaaS development tools, or are uploaded from local MDS and development tools. How policy enforcement points are built into the PaaS application platform depends on whether the PaaS application platform (1) allows the installation of a policy enforcement point (e.g. various open source PaaS platforms, e.g. see case studies below), (2) supports a standards based policy enforcement point (e.g. OASIS XACML), or (3) supports a proprietary policy enforcement point.
4. Automatic Policy Monitoring into the Cloud: Policy enforcement points typically raise security related runtime alerts, especially about incidents related to invocations that have been blocked. The collection, analysis and visual representation of those alerts can also be moved into the Cloud. This has numerous benefits: Incidents can be centrally analyzed for multiple Cloud services together with other information (e.g. network intrusion detection). Also, an integrated visual representation of the security posture across multiple Cloud services can be provided, integrated incident information can be stored for auditing purposes, and compliance related decision support tools can be offered as a Cloud service.
5. Automatic Updating: The described model-driven approach enables automatic updates of technical security policy enforcement and auditing whenever applications and especially their interactions, change. The same automation is possible when security policy requirements change.

 Publications about this can be found in the ISSA Journal October 2010 and on IBM developerWorks. Contact me if you would like to know more information about Policy as a Service.

AuthoriZation Based Access Control (ZBAC) and model-driven security

The article was moved to https://www.objectsecurity.com/authorization-based-access-control-zbac-model-driven-security/

On Resource-Based Access Control (ResBAC) vs. Identity-Based Access Control (IBAC)

This article was moved to https://www.objectsecurity.com/resource-based-access-control-resbac-vs-identity-based-access-control-ibac/

Study estimates 59% accreditation cost saving using automated "Correct by Construction (CxC)" tools (& more for agile SOA/Cloud)

I recently found an interesting technical article by the U.S. National Security Agency's (NSA) Tim Kremann  in "The Next Wave, "The National Security Agency's Review of Emerging Technologies, Vol 19 No 1, 2011", "High Confidence Software and Systems". The article titled "Correct by Construction: Advanced  Software Engineering" (p. 22ff) argues that a correct-by-construction (CxC) methodology, such as model-driven software engineering, can improve assurance and reduce the time and cost to certify assurance (incl. security and correctness). In particular, the article quotes a study by Kestrel Institute, which showed the the automatic generation of certification documents (incl. Common Criteria supporting evidence) as part of a CxC methodology can be estimated to result in "an average overall cost reduction of about 59 percent per certification application due to using CxC methods". Overall, this lead the Kestrel researchers to "conclude that a CxC process will produce a certified product for roughly 30-40 percent of the cost of a conventional process".

These findings are in line with our numerous real-world experiences of using model-driven security approaches to automate both technical security policy implementation (MDS) and accreditation evidence generation (MDSA) (alongside model-driven service orchestration or model-driven development). However, our own empirical research has shown that the cost reduction is much higher than 59% (compared to manual approaches) for agile IT landscapes, especially Service Oriented Architectures (SOAs) "system of systems" and the very related Cloud PaaS mash-up "system of systems". The following argument makes the accreditation/re-accreditation cost reduction evident:
(1) We can save 59% percent during the first-time accreditation as Kestrel researchers mentioned above identified, using an automated model-driven approach (MDS/MDSA);
(2) The manual re-accreditation cost after agile SOA orchestration/Cloud mash-up changes can be significant, because changes across the entire "system of systems" need to be analyzed in order to figure out what impacts re-accreditation and how;
(3) Doing this analysis and change evidence generation automatically based on all the application/interaction/system models, security models, and accreditation requirements models reduces that cost dramatically: it can be close to zero if the automated analysis finds out that the changes do not impact the current accreditation; If manual re-accreditation is necessary, the cost is dramatically reduced because the supporting evidence and a summary of changes and their impacts are automatically produced.

Please contact us if you have any questions about model-driven security or about this blog post.

Analysis Series: "Security Recommendations for Cloud Computing Providers" (German Federal Office for Information Security)

In this post I would like to share my views of the "Authorisation" section (p. 37 in the English version) of the German Bundesamt für Sicherheit in der Informationstechnik (BSI) (Federal Office for Information Security) white paper "Security Recommendations for Cloud Computing Providers (Minimum information security requirements)"(download, German & English). The section states:

"Authorisation
The rights management system must ensure that each role may only see the data (including meta-data) required to achieve the task. The access control should be role-based and the roles and authorisations set up should be reviewed regularly. In general, the least privilege model should be used, with users and CSP administrators only possessing the rights that they require to achieve their tasks. Particular attention should be directed here towards privileged users. If the role is that of a CSP administrator, it should be possible to demonstrate that the only data viewed was that which was required for the task. The rights management system should also be capable of fully documenting and monitoring data exports and imports from and to the CSP. Lastly, any particularly critical administration activities, such as installing patches, should only be performed on the four-eye principle."

As with most other guidance documents previously analyzed on this blog post series, this section makes strong requirements statements at a high level ("only see the data...required to achieve the task", "least privilege"), but at the same time recommends only less-than-optional technical controls ("access control should be role-based"). As previously identified with other guidance documents, the recommendations fail to address the fact that access control needs to be highly contextual to achieve effective "least privilege" for a particular task. Granting role-based access to some particular job function based on everything that job function might ever potentially need to access for all tasks that job function might ever do is not effective "least privilege!

In order to minimize access rights to exactly what is needed to be accessed ("least privilege") in a particular situation ("task"), the context of the task, as well as other environmental context (such as time of day, crisis level, a particular patient checked into hospital of the treating doctor who wants to access that patient's health record etc).

The fact that this (and other) government issued guidance does not address the issue that traditional access controls (incl. role-based access control) are only partly effective to achieve "least privilege" is unfortunate. It allows enterprises to continue to get away with not really solving the real underlying security challenges they are facing, with customers having to pay the price for the damage caused by these only partly effective security measures.

However, real solutions are available today: Model-driven security policy automation (e.g. OpenPMF) together fine-grained, contextual authorization management (e.g. XACML) help implement real contextual, fine-grained access controls in a manageable way. Model-driven security alleviates the main challenge of authorization management, which is that policies for fine-grained, contextual authorization management are hard to manage and maintain, even for dynamically changing (agile) IT landscapes such as Service Oriented Architectures (SOAs) and Cloud mash-ups. Please feel free to read this blog, our website, or contact me.

Model-driven security is now on Wikipedia

We are pleased to report that model-driven security is now covered on the encyclopedia website Wikipedia. Click here to read the Wikipedia article.

Gartner identifies model-driven security as part of "Top 10 Strategic Technologies for 2012"

Industry analyst firm Gartner identifies model-driven security as part of "Top 10 Strategic Technologies for 2012", in the context of "Contextual and Social User Experience". They write "A contextually aware system anticipates the user’s needs and proactively serves up the most appropriate and customized content, product or service. Context can be used to link mobile, social, location, payment and commerce. It can help build skills in augmented reality, model-driven security and ensemble applications." (source: Gartner Identifies the Top 10 Strategic Technologies for 2012). It is great to see that industry analysts continue to acknowledge the significant potential of model-driven security to automate the technical implementation of contextual, rich, and expressive security policies. Read more about model-driven security on this blog, or contact us for more information.

Analysis Series: NISTIR 7628 Smart Grid Security Recommendations

In this “analysis series” blog post, I will focus on US NIST’s 537-page "Guidelines for SmartGrid Cyber Security" (NIST IR 7628). Here are some interesting recommended controls I have analyzed:

1. Least privilege access control: The recommended control “Least Privilege” (NIST IR 7628 - SG.AC-7) requires that “the organization assigns the most restrictive set of rights and privileges or access needed by users for the performance of specified tasks”, and that “the organization configures the smart grid information system to enforce the most restrictive set of rights and privileges or access needed by users”. In other words, a caller should only be granted access to a resource if that caller has a need to do so in the specific context, for example a particular step in a business process, or a particular system situation such as emergency level.
2. Information flow enforcement: The recommended control “Information Flow Enforcement” (NIST IR 7628 - SG.AC-5) requires that the smart grid information system enforces assigned authorizations for controlling the flow of information within the smart grid information system and between interconnected smart grid information systems in accordance with applicable policy. Information flow control regulates where information is allowed to travel within a smart grid information system and between smart grid information systems. As example implementations, the document mentions boundary protection devices that restrict smart grid information system services or provide a packet-filtering capability. This section of the document also offers a number of supplemental considerations. Particularly interesting for the discussion in this paper, the guidance recommends “dynamic information flow control allowing or disallowing information flows based on changing conditions or operational considerations”.
3. Incident monitoring, incident reporting, and auditing: Related to achieving visibility, numerous recommendations for incident monitoring, incident reporting, and auditing are spread throughout the NIST IR 7628 document. For example:  “smart grid Information System Monitoring Tools and Techniques” (SG.SI-4) requires that “the organization monitors events … to detect attacks, unauthorized activities or conditions, and non-malicious errors” based on the organization’s “monitoring objectives and the capability of the smart grid information system to support such activities”. The supplemental guidance states that this can be achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, log monitoring software, network monitoring software, and network forensic analysis tools), and can include real-time alerting. “Incident Monitoring” (SG.IR-6) requires that “the organization tracks and documents … security incidents”, maybe using “automated mechanisms to assist in the tracking of security incidents and in the collection and analysis of incident information”. “Incident Reporting” (SG.IR-7) requires incident reporting procedures about what is an incident, granularity of incident information, who receives it etc., again potentially employing “automated mechanisms to assist in the reporting of security incidents”. “Auditable Events” (SG.AU-2): to identify events that need to be auditable as significant and relevant, requires the development and review of a list of auditable events on an organization-defined frequency, including execution of privileged functions. “Audit Monitoring, Analysis, and Reporting” (SG.AU-6) requires audit record reviews and analyses to find and report inappropriate or unusual activity, potentially employing automated, centralized analysis tools. “Audit Reduction and Report Generation” (SG.AU-7) supports near real-time analysis and after-the-fact investigations of security incidents, e.g. by automatically processing audit records for events of interest based on selectable event criteria. “Audit Generation” (SG.AU-15) recommends audit record generation capability, potentially from multiple components into a system-wide audit trail that is time-correlated.

All this makes sense, but is easier to write about than to actually implement, esp. at the scale of a smart grid. Let’s discuss each on turn to see how model-driven security policy automation can help implement these recommendations effectively:

1. Least privilege access control: What this specifically means is that a dynamic access control “whitelist” (i.e. stating what is allowed, vs. “blacklists” that state what is not allowed) needs to be available that enforces the that policy requirement. Static access control models such as identity-based access control (IBAC) or role-based access control (RBAC) are not sufficient access mechanisms because they do not capture such context in the policy. As a result, virtually all IBAC/RBAC implementations, including traditional Identity and Access Management (IAM) technologies, are insufficient on their own. Attribute-based access control (ABAC), as for example standardized in XACML, help add this missing context and other additional expressions to the policy. The flipside of ABAC is that those fine-grained contextual authorization policies are extremely difficult, time-consuming, and error-prone for human administrators to manually author and maintain. Model-driven security policy automation as implemented in OpenPMF can solve the unmanageability problem of ABAC and ZBAC.
2. Information flow enforcement: As already mentioned above, IBAC and RBAC are insufficient on their own, and due to the inherent changing (“agile”) nature of today’s interconnected IT landscapes (“system of systems”), ABAC policies would need to be constantly manually updated to be correct after “system of systems” changes, resulting in a policy management nightmare. There are a number of other problems with ABAC, e.g. challenges around authorization delegation across service chains and impersonation, which can be solved using authorization-based access control (ZBAC), which uses authorization tokens and federated authorization token servers. Model-driven security policy automation as implemented in OpenPMF can solve the unmanageability problem of ABAC and ZBAC.
3. Incident monitoring, incident reporting, and auditing: In the context of the fine-grained contextual authorization mentioned earlier, incident monitoring, reporting, and audit are intrinsically intertwined with authorization. Monitoring, reporting, and audit tools will need to know the specific authorization policies in order to decide whether behaviour is in fact suspicious or not. This differs dramatically from traditional monitoring approaches which mainly monitor for generic vulnerabilities (i.e. the same vulnerabilities occur for a particular technology, rather than for a particular business) and thus do not need to know any specifics about the organization’s business processes in order to flag an incident. I call control and visibility for generic vulnerabilities “security hygiene” to distinguish them from organization-specific policy enforcement and monitoring. Model-driven security incident monitoring and analysis, as implemented in OpenPMF, can solve the policy-driven monitoring challenge for authorization management compliance.

I hope you enjoyed this analysis, comments are of course always appreciated.

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!

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.

XACML is a machine policy format, not a policy authoring language for humans

We have said it since 2003, and finally we are not alone anymore. Increasingly, industry trade bodies and analysts agree with us that XACML is not a viable policy authoring language for humans. For example, OASIS had a recent webinar where Domain Specific  Languages (DSLs) were mentioned in the "Future directions" part of the presentation. Great, because model-driven security policy automation is inherently based on DSLs, and ObjectSecurity's OpenPMF has full standards-based (Eclipse EMF) support for DSLs. Recently, an analyst who covers the authorization management space wrote that XACML is only good if it is hidden from humans.
Because this is great and shows that the industry is moving towards finally accepting that policy automation as a necessary mechanism to make authorization management work, I would like to explain in a bit more detail that it is not only about "hiding" XACML, but also about automatically generating technical details from generic DSLs. DSLs should express policies in the way human security policy specialists think about policy, which might be different from how the technical enforcement actually makes concrete decisions. ObjectSecurity's award-winning and patent-pending model-driven security policy automation bridges the gap to the actual technical enforcement rules through transformation algorithms that can analyze many information sources (e.g. business processes, application mashups, directory information, sensor information) to automatically generate and update the technical rules.If you want to read up about this, feel free to read our website as an introduction, and get further details here.

Government clouds (G-Cloud) - Security through Obscurity?

We are currently carrying out an R&D project about applying policy automation and ObjectSecurity OpenPMF to cloud. Interestingly, government cloud initiatives worldwide seem to keep their information assurance (IA) architectures confidential (maybe even classified?). For example (just to name one), the UK Cabinet office published a number of G-Cloud documents but deliberately did not publish the Information Assurance document. I have been in the security field for way too long (over 15 years) and have heard and seen evidence over and over again that security through obscurity's disadvantages outweigh the benefits. And I am apparently not the only (e.g. concerns voiced here) one who thinks that related to G-Cloud. G-Clouds are large, interconnected IT landscapes that rely on standards and frameworks. How is this ecosystem ever supposed to come together if it is hidden under a cloak of obscurity? And how is the required innovation supposed to come in if the cloak of obscurity prevents innovators to apply their solutions to G-Cloud? I believe that general government cloud architectures should be publicized so that the expert community can provide suggestions. It is also a good way to achieve some transparency about procurements and push for standards.I would be grateful if G-Cloud initiatives could provide me with information about their IA architectures so I could explain why and how model-driven security policy automation and compliance automation should be integrated.

Cyber security paradigm shift needed: Focus on solving your customers' problems instead of “something else”!

Over the last decade, a lot of money has been spent on cyber security, while cyber security has become less effective in terms of preventing security breaches and the related damage. On the one hand, this is partly because of the increasing sophistication of attackers. But on the other hand, it is partly also because the cyber security industry fails to adequately address the really significant security problems, and instead selling “something else” that is easier to solve but does not solve the problems. While a defense-in-depth strategy is desirable, our industry needs to stop shying away from solving the big problems (incl. general lack of enforcement mechanisms and procedures, preventing insider theft, preventing data leakage, no mechanisms to implement regulatory compliance reliably for applications, no mechanisms to enforce least privilege / need to know policies).

One thing I hear repeatedly is that customers do not ask for solutions to their problems, but instead ask for a more or  less ineffective "quick fix". I do not believe this is really true - customers are often unaware of how to pose the right questions to their vendors, or pose them very indirectly because their understanding of security is shaped by vendor offerings/marketing/misinformation. Discuss top down ("what are you trying to achieve?") instead of  bottom up ("what product feature xy would you like to adopt?"). Here are some concrete questions to ask your customers:

 

1) HOW TO BE PREVENTIVE / PROACTIVE & REACTIVE VS JUST REACTIVE?

- How are enterprise security policies and regulatory compliance in general proactively enforced (=blocking based on whitelists), as opposed to just reactively monitored?

- How are enterprise security policies concretely implemented (enforced & monitored) in the software?

- How do you demonstrate that the implemented technical security actually matches with the intended enterprise security policies?

- How is automation used to achieve all this?

2) HOW TO PREVENT INSIDER BREACHES, LEAST PRIVILEGE?

- How are malicious or negligent insiders (or compromised accounts) prevented from committing massive data breaches?

- How are contextual policies, such as "least privilege" policies enforced, e.g. for HIPAA and PCI?

- How is automation used to achieve all this?

3) HOW TO MAINTAIN SECURITY IN THE FACE OF CHANGE? HOW TO AUTOMATE?

- What happens when the interconnected application landscape changes (e.g. SOA & cloud agility)?

- How is security made part of the software development lifecycle (SDLC) without burdening developers?

- How are the technical policies updated to match with the enterprise security policies and the changed environment in a fast, reliable, and cheap fashion?

- And how is compliance reliably demonstrated after updates?

- How is automation used to achieve all this?

4) CUSTOMER PAIN POINTS:

- Even if customers have not raised those points as described above, they will probably have implicitly asked for solutions to those problems. For example:

- If customers say "the deployment needs to comply with regulation xy", and the regulation states things like "data should only be used for the purpose", then you need to enforce least privilege (example: HIPAA). The same applies if customers ask for solutions to prevent insider breaches.

- If customers ask for preventing breaches, they will need real proactive policy enforcement (=blocking based on whitelists), and not just monitoring.

- If customers say "our IT landscape needs to be agile", or " future-proof", then they will need to have policy automation. Otherwise the manual policy implementation will effectively prevent IT agility (too many manual updates)

Comments on this are greatly appreciated as usual.