Monday 5 November 2012
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/
Thursday 22 March 2012
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.
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.
Friday 20 January 2012
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.
"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.
Subscribe to:
Posts (Atom)