Ulrich Lang's Security Policy Automation & Model-Driven Security Blog

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

2012-01-20T11:28:00.000-08:00

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

2011-12-15T10:25:00.000-08:00

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"

2011-12-09T10:16:00.000-08:00

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

2011-08-01T17:46:00.000-07:00

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:

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.
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”.
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:

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.
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.
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

2011-07-29T10:13:00.000-07:00

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

2011-07-15T12:34:00.000-07:00

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

2011-06-27T20:28:00.000-07:00

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?

2011-05-31T18:52:00.000-07:00

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”!

2011-04-27T14:09:00.000-07:00

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.

Give cloud users more control and close the loop: Standards-based policy in, standards-based audit out.

2011-04-06T16:29:00.000-07:00

It is becoming increasingly clear to me that we need to give end-users more control over what security and auditing the cloud (especially for the higher layers, i.e. PaaS/SaaS) does for them. Cloud providers simply cannot know the end-user organization's business security & compliance policies, and therefore can only provide basic (but important) security and compliance support. This should happen in two main directions of a closed loop:

1) Policy in: we need to have standardized interfaces and policy formats which cloud providers can support, so that end-users can configure authorization, authentication etc. There are some standards out there, e.g. OASIS XACML, but this may be on a too application specific level. My company has advocated the use of models as a generic format to express policy - these can then be implemented automatically by cloud providers using model-driven security. Request more information here.

2) Audit out: We also need standard formats/APIs etc. to let end-user organizations tell the cloud provider what audit information they require, and when. It looks to me that CloudAudit is doing just that.

Would anyone be interested in joining forces to bring a community together to do what CloudAudit does for Policy? Please contact me or post your interest on this discussion.

Feel free to comment on this blog, or join the discussion on the Cloud Security Alliance LinkedIn group.

Implementing security policy automation: Free lunch? Unfortunately not.

2011-04-01T11:43:00.000-07:00

Good security is ultimately about figuring out what should happen, and making sure that anything else does not happen. In security terms, this means figuring out enterprise security and compliance policies first, then figuring out how to implement controls across technology, processes, and people.
Unfortunately this is hard, which is why most security products and methods in the market avoid enforcing your policy altogether. For example, antivirus, anti-malware, etc. are useful "hygiene" tools but do not know enough about your business to even enforce the policies that matter (e.g. PCI, HIPAA, NERC/FERC, Common Criteria...). Other tools (IDSs, compliance monitoring etc.) also do not know the policy that matters and simply monitor something, so some administrator - if they can weed through the overload - may spot that you got hacked, which is better than nothing but does not prevent being hacked. Other tools enforce a policy (e.g. firewalls, identity management), but usually not the policies or the granularity/contextuality that matters to the business. While I am a proponent of "defense in depth", I would sum the current state of most of the security vendor landscape and end-user purchasing behavior as "solving something we can solve", rather than actually solving the real security problems.
However, doing this right by stating what you want and enforcing it is hard: for example, manually producing many complex, context-aware technical policy rules ("whitelisting") for a highly interconnected, large Service Oriented Architecture (SOA) or cloud mash-up is highly error-prone and expensive, and is also totally unmaintainable. There is also little assurance that the configured policy actually capture the intent.
Policy automation tools such as OpenPMF make this easier and more maintainable, especially for agile IT landscapes (incl. SOA/cloud) - it lets security and compliance specialists capture policies at an intuitive level as models (similar to enterprise architecture and business process models), and automatically takes care of generating/enforcing/monitoring the matching technical rules. However, this is no free lunch either - figuring out and capturing the requirements and configuring everything is not easy and takes time. It also will not work elegantly for each and every kind of system. However, when you compare it to the two alternatives (1) solving something but not the problem and (2) incurring a manual administration nightmare, it is a compelling approach.

"Least privilege", "need to know", insider threats & WikiLeaks

2011-03-22T11:33:00.001-07:00

We are happy to see recent increasing understanding in large enterprises and government that policies (security & compliance) need to proactively enforced, and not just monitored. To motivate my point, one of the hype topics at this year's RSA Expo hype was "continuous monitoring", which essentially tells you when you got attacked earlier than normal compliance auditing. This is necessary but not sufficient: Necessary because there is no 100% security protection. Not sufficient because you need to prevent attacks proactively. Such real prevention is difficult to manage because it requires that someone captures the security & compliance requirements in a technical policy "whitelist". However, without a whitelist of allowed actions, "least privilege" and "need to know" cannot be implemented. And it is exactly that least privilege principle that prevents insider attacks and attacks where outsiders hijack insider credentials. It would have potentially prevented the WikiLeaks leak from Navy, because if least privilege had been enforced correctly, access to all the information would have not been granted. Security policy automation and model-driven security help capture requirements and automatic enforcement. Least privilege can for example be elegantly captured by having policies related to the sequence of a workflow of a SOA orchestration: you can only access a particular web service in a particular step of a workflow for which you have been authorized, and only if you have correctly gone through the workflow up to the point where you can access the web service. Again, capturing SOA BPM workflows and security & compliance models is not easy, but easier approaches (e.g. firewalls, malware, code scanning, IDS etc.) are not able to solve the least privilege & need to know problem. Contact us at www.objectsecurity.com if you have any questions/comments

Cloud Security Alliance Presentation on Policy Automation: 8 Feb 2011, noon PST (WebEx & Sunnyvale, CA, USA)

2011-01-21T10:59:00.000-08:00

What: Security Policy Automation for Cloud Applications

When: Tuesday, February 8, 2011 12:00 PM

Details & RSVP to this Silicon Valley CSA Meetup:
http://www.meetup.com/SV-CSA/calendar/16049370/

ABSTRACT:
You have to plan ahead in terms of security when moving parts of your organization’s IT into the Cloud. Compromises and mistakes done early on when things are small and less critical will come back and haunt you later. In this session, you will learn why security automation is important to meet both regulatory compliance requirements and the financial rationale behind Cloud adoption. 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. This session explains how automated tools can be used to translate security policy into technical security implementation for Cloud applications (using an approach known as “model-driven security”), so that security practitioners can better support financial rationale behind Cloud computing, and also influence Cloud providers to provide better security tools. The session will also cover how this approach helps achieve regulatory compliance for cloud.

SPEAKER:
Dr. Ulrich Lang is the co-founder and CEO of ObjectSecurity®, “The Security Policy Automation Company™”. ObjectSecurity’s OpenPMF™ product makes application security manageable through automation. Ulrich is a renowned thought leader, author and speaker on model-driven security, security policy, Cloud/SOA/middleware/application security, and has over 15 years of experience in information security. He received a PhD from the University of Cambridge Computer Laboratory (Security Group) on conceptual aspects of middleware security in 2003, after having completed a Master's Degree in Information Security with distinction from Royal Holloway College (University of London) in 1997.

Making sense of the buzzword soup: "policy-driven", "automation", "proactive", "enforcement" etc.

2010-10-05T11:06:00.000-07:00

Security vendors nowadays are frequently jumping onto new buzzwords on a daily basis to catch buyers' attention. Almost all marketing materials contain a buzzword soup that includes "policy-driven", "automation", "proactive", "enforcement" etc. Unfortunately often the products do not actually reflect the meaning of the term, or the meaning has been twisted to hide the fact that the product does not actually do what the term originally implied. This is very frustrating to both buyers and other vendors because it makes informed comparison very difficult. In this blog post, I explain the main buzzwords related to policy automation and model-driven security, so that you can more easily compare them with alternative approaches.

Automation: As the name implies, automation takes the human out of the loop. Policy automation involves: (a) without human interaction, translating policy requirements into technical implementation, e.g. access control & monitoring, authentication, (b) without human interaction, enforce technical security policies across applications and systems, (c) without human interaction, collect, analyse, and remediate incidents. Anything else is not automation: e.g. collecting incidents and presenting them to a user so that they can manually remediate. The simple test: If it involves the human at runtime to enforce security, then it's not automated.

Proactive: Proactive is related to "preventive", i.e. when the product enforces security based on that policy that states what should be allowed and what should not be allowed, irrespective of any monitored incidents. This means that bad things are prevented before they happen, instead of fixing the damage after it happens. Security enforcement based purely on "reactive" action based on monitored incidents is not proactive. Proactive means that the security product knows what should be allowed and what should not (= policy) before any activity happens across systems and applications; Proactive inherently implies that the product needs to capture the policy, which the next topic "policy-driven" is about. Proactive is inherently a wobbly term, so ask for specifics, esp. whether the product is preventive.

Policy-driven: Policy driven means that the security product knows and captures what should be allowed and what should not (= policy) before any activity happens across systems and applications. This means someone has to type in the policy in some form (in model-driven security, you capture generic requirements models; in e.g. firewalls, you type in many technical rules). This is often called "white-listing", and white-listing policies have been traditionally difficult to manage - it is expensive, error-prone, and time-consuming, esp. in agile IT environments. Model-driven security helps address that policy management challenge (this is explained in the beginnings of this blog). According to that definition, tools are not "policy-driven" when e.g. compliance decision support tools tell you based on collected incidents that you are not meeting your compliance policy. As you can see, this term can be turned into meaning almost anything, so if a vendor says "policy-driven", the best thing to do is to ask for the specifics.

Enforcement: Enforcement means that the product ensures the policy is actually enforced. For example, a firewall that blocks traffic based on the policy proactively "enforces" the policy. Sounds obvious, but many vendors that do not have enforcement capabilities (usually because they cannot capture policy in a suitable way) have twisted this term to mean that the product presents some information (e.g. about incidents) to a human user who can then manually take steps to remediate the problems found. This is not enforcement, this is remediation. Again, the terms are turned into meaning almost anything, so ask for specifics.

Application security: This is a tough one because it is such a broad topic. Be aware that there is much more to application security than what gets visibility these days (static/dynamic code analysis, executable whitelisting etc.). Applications today are definite to an increasing extent by how they interact (e.g. SOA & Cloud mashups), so it is important to enforce security policy based on many application attributes (e.g. application, interactions, application context, execution/use workflow etc.). It is very important that application security is not only about vulnerabilities, but also about application behavior - a perfectly correct application can be used by a user in the wrong context to do something they are not allowed to (esp. by insiders). Make sure you are not talked into "application security is only xyz" by vendors.

Model-driven: For completeness, here is the main uniqueness of model-driven security. It allows security requirements to be captured in generic terms (models), which are semantically so close to human thinking that they cannot be directly enforced by a computer. Model-driven security translates these models into concrete computer-enforceable technical rules by analyzing the applications with all their interactions (at development/deployment time) and context information (mostly at runtime). This step from "human thinking" to "machine enforceable" is what other policy management approaches do not achieve: whatever the format or representation, in those other approaches you still have to input technical security policies. Read up below, or contact us if you would like to know more about this.

Any comments on this would be greatly appreciated.

"Automating configuration and security management is the best way forward" (DEFCON 18)

2010-08-31T10:09:00.000-07:00

An interesting article states that a survey at the DEFCON 18 conference concluded that misconfigured networks main cause of breaches, and that "... automating configuration and security management is the best way forward to solving this problem....". 73% came across a misconfigured network more than three quarters of the time – which, according to 76% of the sample, was the easiest IT resource to exploit. If you add to this the studies indicating that 70%-80% of all attacks are targeted at the application layer, and that application platforms and applications themselves are at least as hard if not harder to configure and manage properly, it becomes clear that "... automating configuration and security management is the best way forward ...." also for application security. This blog has advocated security policy automation and model-driven security for years, and it is great to see this survey underscore the absolute need for it.

New Whitepaper "Security Policy Automation: Improve Cloud Application Security ROI"

2010-08-20T11:07:00.000-07:00

New Whitepaper: "Security Policy Automation: Improve Cloud Application Security ROI"
You have to plan ahead in terms of security when moving parts of your organization’s IT into the Cloud. Compromises and mistakes done early on when things are small and less critical will come back and haunt you later. In this article, you will learn why security automation is important to meet both regulatory compliance requirements and the financial rationale behind Cloud adoption. 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. In order to reduce security related manual maintenance cost at the end-user organization, security tools need to become more automated. Unfortunately in many cases automation is easier said than done, and many security tools today offer automation at the price of trading off relevance, correctness and automation. This article discusses security policy automation challenges and solutions for Cloud applications (using an approach known as “model-driven security”), so that security practitioners can better support financial rationale behind Cloud computing, and also influence Cloud providers to provide better security tools.
Contact me if you would like a free copy.

Policy Automation is Critical Because Security is About Cost-Benefit

2010-07-21T12:27:00.001-07:00

Security automation (together with configuration management automation and audit/compliance automation) should be a top priority for enterprise/government. Here is why:
We need more automation to make security cheaper and reduce the hidden costs ("externalities") related to security, such as user/administrator time wasted. A lot of security advice and technologies cost more than they save, i.e. taking the unlikely hit is cheaper than adopting them [1].
To achieve better security cost-benefit, my interest has been "security policy automation" for a long time, i.e. to automate a lot of the tasks ("externalities") that administrators face when managing security policies for applications (esp. authorization) [2].

[1] A Microsoft Research paper outlines why cost-benefit optimization is needed for security: " So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users". In fact my PhD supervisor from back in the days (Prof Ross Anderson in Cambridge) has talked about this for over 10 years, and so did Schneier and others.
[2] OpenPMF Security Policy Automation

Linkedin discussion "Security Policy Automation"

2010-07-16T11:28:00.000-07:00

FYI - I have just set up a discussion group on Linkedin where you can discuss this topic more interactively.

"Authorization as a Service"

2010-07-06T12:39:00.000-07:00

"Identity as a Service" is now a buzzword pushed by big vendors sell their identity management suites. Unfortunately, identity as a service does not solve the basic challenges that managing access control is the harder - and often ignored - problem. It is somewhat disappointing to me that the Cloud Security Alliance published a very narrowly scoped docucment "Domain 12 Guidance for Identity & Access Management" back in April 2010 that covers Identity-as-a-Service, but leaves out Authorization-as-a-Service (the document is sponsored by a big identity vendor, which explains a lot...).
This blog has advocated the use of model driven security to implement "Authorization as a service", or more precisely "Security & Compliance Automation as a Service" (SCaaS), for some time. Scientific papers are being presented at various conferences over the coming months, contact us if you would like to know more.
*UPDATE*: a discussion on the Cloud Security Allicance Trusted Cloud Initiative Linkedin forum discusses the issue.

Cloud application security discussion at Cloud Security Alliance (CSA)

2010-06-22T14:46:00.000-07:00

Cloud Security Alliance (CSA) LinkedIn Group discussion about Cloud application security
There is a pretty lively discussion going on about Cloud application security at the Cloud Security Alliance (CSA) LinkedIn Group. As expected, the discussion seems to home in on the need to configure and enforce fine-grained technical authorization and monitoring policies - the driver behind model-driven security policy automation.

Follow the discussion here:
http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1864210&discussionID=20649547

P.S. If you would like more information about Cloud application security, please have a look at our eBooks or contact us.

Cloud Security: Controlling PaaS Information Flows

2010-01-26T03:35:00.000-08:00

There is a lot of confusion today about what Cloud security means, and how security is related and different from other technologies. While a lot of infrastructure security is already required to make Cloud computing secure and compliant with regulations, a particular challenge is how to also make the applications running in the Cloud (i.e. on Platform-as-a-Service, PaaS) compliant. For example, if your organization deals with customer information, PaaS applications - just like traditional applications - need to include policy management and enforcement to ensure information usage is in line with regulations and policies.
PaaS applications are best integrated using a model-driven approach (e.g. using business process modeling, BPM). For example, Intalio|Cloud offers such a BPM PaaS enabled Cloud platform.
ObjectSecurity has integrated their OpenPMF model-driven authorization management product with the model-driven BPM integration tools that come with Intalio|Cloud. The integration allows PaaS developers to reliably manage and enforce consistent, human-understandable security policies for their agile applications (in just the same automated way OpenPMF does this for Service Oriented Architecture and virtualization platforms).
Please contact ObjectSecurity if you would like to discuss this, and know more about Cloud security and PaaS security policy automation. ObjectSecurity offers free trials, free webinars, consulting, and eBooks to help you. Future-proof your Cloud roadmap - you can only take the right roadmap decisions if you have all the information you need!

Business Process Sequence Policies

2009-11-30T20:18:00.000-08:00

Today I would like to share the idea of stateful sequence policies for business process (BPM) orchestrated applications. This has been published back in 2007, and has also been implemented in OpenPMF's model-driven security feature a while back.

For example, the generic process sequence policy "only allow each step in the workflow if the previous interaction also happened" means that interactions are only allowed to be executed in the order of the workflow. Simple, generic, intuitive and useful.

But how do you translate this into technical access control rules for your specific interconnected application without having to rewrite the policy each time you change the application? Model-driven security (as implemented in OpenPMF) can apply such generic security policies to specific technical application security policies by analyzing the application (in this case the BPM model). To make this work, we had to slightly extend our rule language and add a few things to the runtime infrastructure. If you want to see how this works in the real world (within a BPM software development tool), go to , www.objectsecurity.com and get your free trial.

Update: Model Driven Security Accreditation (MDSA) publications

2009-11-26T12:26:00.001-08:00

ObjectSecurity published a scientific ACM publication "Model Driven Security Accreditation (MDSA) For Agile, Interconnected IT Landscapes" at The 1st ACM Workshop on Information Security Governance, November 13, 2009, Hyatt Regency Chicago, Chicago, USA

You can learn more about MDSA, MDS, and SOA Security here:

E-Book 3 - Model-Driven Security Accreditation for Agile IT Landscapes
E-Book 2 - Security Policy Management with Model Driven Security
E-Book 1 - SOA Security Concerns & Recommendations

Upcoming Webinar with Intalio: Securing Agile Process-Led Applications with OpenPMF for Intalio BPMS

2009-07-07T23:45:00.000-07:00

Organizations today need to meet increasingly demanding security and compliance requirements, while software applications and business processes get evermore complex and agile (e.g. Service Oriented Architecture, Business Process Modeling). According to industry analysts, most security products in use today focus on the network layer, while the majority of cyber attacks today exploit vulnerabilities on the application layer. Application security and a secure development process are therefore a critical element of any security strategy. However, application security is often not dealt with effectively due to time and cost pressures, especially in the current economic climate.

In this webinar, you will learn:
1) application security challenges and solutions
2) agile SOA security challenges and solutions
3) aspects and stages of the secure development lifecycle (including policy abstraction, externalization, authoring, automation, enforcement, monitoring, and verification)
4) how OpenPMF can be used to protect and monitor agile applications with minimal effort by automatically generating technical security policies for your applications and processes from intuitively captured security & compliance requirements.
5) how the newly packaged, award-winning OpenPMF 2.0 application security automation product (www.openpmf.com) version can be used in action for Intalio BPMS (www.intalio.com), the leading open-source-based Business Process Modeling (BPM) application automation vendor.

Date: Monday July 20, 2009
Time: 9:00 AM PST (12:00 PM EST, 5:00 PM GMT, 6:00 PM CET)
To Register: www.objectsecurity.com/en-contact-webinar.html

Model Driven Security Accreditation (MDSA)

2009-06-24T00:27:00.000-07:00

Exciting news! Model Driven Security is now applied to assurance accreditation for agile IT landscapes.

Challenge

Assurance accreditation of agile, interconnected IT landscapes is a great challenge, and is currently often cited as one of the show-stoppers for the adoption of modern IT architectures (e.g. SOA) in mission critical domains.

Solution

ObjectSecurity’s patent-pending Model Driven Security Accreditation (MDSA) approach automates large parts of the compliance and assurance accreditation management processes (e.g. Common Criteria). The benefits of MDSA are most significant for agile, interconnected IT “systems of systems” that are model-driven (potentially also business process-driven). MDSA automatically analyses and documents two main aspects:

Does the actual security match with the stated requirements?
Do any changes impact the current accreditation?

Definition

Model Driven Security Accreditation (MDSA) enables “agile accreditation” in a way that is cost-effective, low-effort (i.e. partly automated), and reliable / traceable. MDSA especially enables agile accreditation for agile, interconnected IT landscapes based on model-driven, process-led application development and deployment approaches, and on standard middleware and runtime platforms (e.g. SOA). MDSA allows the automated, formalised assignment of “undistorted” Common Criteria assurance requirements to IT landscape specific technical assurance control objectives in functional system specifications. Both are expressed as formalised models and are automatically and traceably matched.Using model-driven security (MDS), the technical assurance control requirements are then automatically transformed into concrete technical IT enforcement & monitoring at runtime. In addition, the traceable correspondence between technical security implementation and the information assurance requirements is analysed and checked. MDSA also documents Common Criteria “supporting evidence” based on all available design-time system / security models, system / security artefacts, system / security model transformations, and runtime system / security incident logs.Furthermore, MDSA enables the automated analysis whether changes to or newly discovered knowledge about an agile IT landscape impact its security properties, and whether the accreditation is still valid. The goal of MDSA is to automatically check whether IT systems security meets its assurance accreditation requirements, and to check the impact of changes (incl. system, security, requirements, newly discovered vulnerabilities) on the accreditation. Based on so-called “change policies”, MDSA decides whether particular system re-configurations are within scope of the current accreditation (thus enabling a level of IT agility) or whether manual corrections and re-accreditation are required. MDSA also allows to assess the impact of newly discovered security vulnerabilities, e.g. weaknesses in crypto algorithms or buffer overflows in libraries, on one system or multiple systems as part of an Accreditation Management System (AMS), a central database of fine grained accreditation information. If manual re-accreditation is required, MDSA also acts as a decision support tool.

Current State

A ~80 page concept exploration study has been produced for UK Ministry of Defence, and a scientific paper is being submitted for publication. MDSA is currently at the prototype stage. Please contact ObjectSecurity if you are interested in further information about the OpenPMF MDSA prototype or the study.

New Analyst Coverage for Model-Driven Security

2009-03-11T05:11:00.000-07:00

IT analyst firm Gartner, today has again raised awareness for model-driven security in Tom Scholtz's report "No More Dr. No: Developing a Strategy for Business-Aligned Information Security" (10 March 2009, ID:G00166010), which advocates that rather than simply saying no to new technology, effectively aligning information security practices with business strategy results in optimized security efforts and investments. Such business alignment requires a multifaceted strategy." The report recommends businesses to "... investigate the potential benefits of modeling-based policy automation. Such technology solutions support the development, implementation and management of security policies that are inherently integrated into the business requirements modeled during IT service solution design.". You can find further information about model-driven security (+ model-driven compliance, model-driven security accreditation,) and about ObjectSecurity's OpenPMF product at www.objectsecurity.com.

Ecosystem for model-driven security is getting ready

2008-12-05T17:47:00.001-08:00

Many vendors provide model-driven tools today, incl. business process management (BPM), model-driven engineering/development (MDE/MDD), model-driven integration (MDI), enterprise architecture (EA) etc.
Process-let SOA orchestration and model-driven code generation or service integration is also a reality today, and big vendors such as Microsoft have announced that they will release these features in their mass-market software development tools.
This is great news for model-driven security, which ties into model-driven tools in order to automatically and traceably produce fine-grained, contextual security policies.
The fact that mainstream tools are available and in use today enables shrink-wrapped, push-of-a-button model-driven security to be added to such model-driven tools - ObjectSecurity has just produced such a shrink-wrapped security policy generator for IntalioBPMS and their OpenPMF model-driven security technology.
SOA security, and specifically security policy management for SOA are also being closely examined, and model-driven security has been identified as a great solution.
So everything is finally coming together in the mass market - watch this space!

Revisited: Aligning business and IT security

2008-10-30T16:55:00.000-07:00

Well, ok, there are a number of useful best practice guidelines for information security management, e.g. ISO 27000 family, COBIT, ISMS, ITIL, which help communicate the processes and requirements to management, select controls, and measure success. So far, so good. However, these documents are so business-centric that IT security enforcement does not simply "fall out at the bottom".
But beware: What ultimately matters is not the documentation produced, but the actual enforcement across your information systems. Real-world attacks are obviously not thwarted with documents!
Today, mapping the requirements from the produced documents down to concrete IT enforcement (and bringing measurements back up) is typically done in a pretty ad-hoc way. The focus is primarily on what the management wants to (not) see, rather than in what matters.
Model-driven security (e.g. OpenPMF), tied into an overall security management methodology, can help close (parts of) this gap in a traceable, runtime, automatic way - therefore model-driven security should be a critical element of effective "business-driven compliance management".

Why "business process-led" model-driven security is useful

2008-10-30T15:31:00.000-07:00

You may have seen that ObjectSecurity released a beta for OpenPMF with Intalio BPMS that supports "business process-led" model-driven security (for BPMN). This feature will form part of the new OpenPMF 3.0 release planned for Q1/2009. Why are business processes so relevant for security policies? Simply because the workflow context is a powerful contextual element of a fine-grained security policy. For example, an e-shop can block access to their bank's credit card charging facility for any access except at the specific step in the business process workflow when the access should be granted. Control is therefore much more fine-grained and contextual than for example role-based or label-based access control. Research (e.g. here) has focussed around the addition of security to business processes for a while, and this feature is now implemented (in beta) in OpenPMF for Intalio's open source BPMS.

Model-driven security needs to be cross-platform

2008-10-18T10:47:00.000-07:00

Another observation we made over the last couple of years is that there will most likely be no "one size fits all" technology platform (e.g. middleware) in today's large, complex IT environments. A plethora of platforms (e.g. web services, JMS, CORBA, CCM, DDS) will probably be used, potentially orchestrated using some BPM technology (e.g. BPMN/BPEL) or model-driven integration (MDI) technology.
As a result, model-driven security needs to be able to ensure correct policy generation and enforcement for all these platforms.
OpenPMF supports policy enforcement for a large number of enforcement points, including web services, JMS, CORBA, CCM, DDS. XACML is also supported to ensure the emerging SOA enforcement landscape can be supported.
Push-button policy generation using model-driven security from a single place only if enforcement is supported cross-platform.

New publications about model driven security

2008-10-18T10:28:00.000-07:00

ObjectSecurity published a paper at ISSE 2008 with a concrete model-driven security healthcare example where a HIPAA healthcare compliance requirement is mapped to cross-platform IT infrastructures including BPM, web services, and CCM. The presentation is here, and the detailed paper is published at:

Lang U., Schreiner R., "Managing business compliance using model-driven security management", in Pohlmann N., Reimer H., Scheiner W. (editors), Proceeedings ISSE 2008 Securing Electronic Business Processes - Highlights of the Information Security Solutions Europe 2008 Conference, Vieweg + Teubner, ISBN 978-3-83480660-4, Edition 2009

Abstract: Compliance with regulatory and governance standards is rapidly becoming one of the hot topics of information security today. This is because, especially with regulatory compliance, both business and government have to expect large financial and reputational losses if compliance cannot be ensured and demonstrated. One major difficulty of implementing such regulations is caused the fact that they are captured at a high level of abstraction that is business-centric and not IT centric. This means that the abstract intent needs to be translated in a trustworthy, traceable way into compliance and security policies that the IT security infrastructure can enforce. Carrying out this mapping process manually is time consuming, maintenance-intensive, costly, and error-prone. Compliance monitoring is also critical in order to be able to demonstrate compliance at any given point in time. The problem is further complicated because of the need for business-driven IT agility, where IT policies and enforcement can change frequently, e.g. Business Process Modelling (BPM) driven Service Oriented Architecture (SOA). Model Driven Security (MDS) is an innovative technology approach that can solve these problems as an extension of identity and access management (IAM) and authorization management (also called entitlement management). In this paper we will illustrate the theory behind Model Driven Security for compliance, provide an improved and extended architecture, as well as a case study in the healthcare industry using our OpenPMF 2.0 technology.

We are pleased that the papers from the MODSEC 2008 (Modeling Security Workshop) are now also available online here (CEUR Workshop Proceedings),

Please contact us if you have any products or publications you would like to see covered in this blog.

Model Driven Security & SOA - take the survey & get involved

2008-09-20T10:43:00.001-07:00

The UK Cyber Security KTN currently runs a SOA security analysis project (see www.secure-soa.info) and there is a study about the main concerns of SOA security by end-users.
Please click here www.secure-soa.info to take the 5 minute survey, and get involved in the email group, wiki, and report!

Business-driven security: Aligning business and IT security

2008-09-02T13:56:00.000-07:00

Organizations today advocate the architectural vision of "aligned business and IT" - this means that the organization's IT landscape is aligned with achieving business goals, and that it can be adapted quickly to help the business respond to changes (e.g. in the market). Enterprise Architecture (EA), Business Process Management (BPM), BPM-driven Service Oriented Architecture (SOA), Model Driven Integration (MDI), and Model Driven Engineering (MDE/MDA) are examples that tie into such a vision.

Model-driven security is a critical aspect ofthis vision because - in line with the overall vision - it allows 1) business security requirements to be defined, 2) these requirements automatically transformed into IT-centric security rules, 3) automatically enforce the rules across the IT landscape, and 4) demonstrate compliance to the business.

The result is a closed loop from the business to IT and back to the business. The benefits include: enable IT/business agility, save cost, improve security, and of course align business and IT security.

Analyst firms forecast the mainstream for model-driven, process-led approaches within 5 years, and model-driven security is set to piggyback onto that adoption. So it is time to look into it now. Feel free to read our white paper at http://www.openpmf.com/.

"Security stove-piping" & agility (e.g. SOA)

2008-05-07T10:32:00.000-07:00

It is clear that end-users are trying to get away from stove-piped, hard-coded IT environments. Instead, they want agile, reconfigurable, modular IT environments, as e.g. advocated by Service Oriented Architecture (SOA). A lot of effort has been put into architecting modular, model-driven approaches to achieve system agility.

Unfortunately security typically gets overlooked, and traditional security tools are deployed and configured (e.g. manually configured policies set in app servers, IAM systems etc.). The result is a system that is almost as stove-piped as before. ObjectSecurity calls this problem "security stove-piping".

Model driven security as a security management approach enables agility and security, and is therefore a critical ingredient in the SOA security mix. Contact ObjectSecurity if you would like to discuss this further.

Management vs. interoperability: Model driven security vs. today's authorization management

2008-05-07T03:49:00.000-07:00

It is clear that the number of fine-grained IT authorization policies that are spread across a medium-size or large-size IT environment can easily go into the 10,000's and 100,000's. Just take the rules from firewalls, databases, and single sign-on systems, and you see that the complexity has grown out of hand: Security is simply unmanageable.

Today's authorization management solutions (sometimes called "entitlement management") tackle the problem by simply putting all the complexity into a single place (the Policy Access Point, PAP). By and large the rules in the central manager are still at the same semantic level and complexity as the rules that are spread across the IT environment if no authorization management is used. This is clearly not a significant reduction of complexity.
(By the way, identity management does not actually cover this problem very well, as it is pretty much concerned with managing identities and less with the management of fine-grained, expressive, maybe context-sensitive authorization policies).
In summary, today's authorization management makes the problem evident, rather than solving it.

What today's vendors are good at is solving the policy interoperability challenge: XACML is a webservice standard for exchanging authorization policy information, and vendors include ObjectSecurity, Cisco, CA, etc.

Model driven security is concerned with solving the complexity challenge: It lets you manage simple, business-driven security policies, and generates the 100,000's of rules for the particular deployment automatically. Sounds like magic, but it is not. Contact ObjectSecurity, the leading model driven security vendor if you would like to learn more.

So in summary: authorization management is necessary but not sufficient.

Model driven security recognized as impactful, innovative, intriguing by leading analyst firm

2008-04-20T05:19:00.000-07:00

Model driven security has recently received internationational recognition indicating the continued emergence of the approach: ObjectSecurity has been named “Cool Vendor” by Gartner, Inc, the leading IT analyst firm, for our innovative OpenPMF 2.0 technology. OpenPMF 2.0 is the first full “Model Driven Security Management” product in the market. Model driven security is predicted to be a high-impact technology area that helps deal with the complexity of today’s authorization management technologies. Read the press release and some information about OpenPMF 2.0 here:

Press Release ObjectSecurity Named "Cool Vendor" by Leading Analyst Firm
(Cambridge/UK – 04 April 2008) – ObjectSecurity, the leading solutions provider for Model Driven Security Management and secure information sharing in mission-critical industries such as air traffic control, today announced that Gartner, Inc., the world's leading information technology research and advisory company, has named ObjectSecurity in its "Cool Vendors in Application Security and Authentication, 2008”. The April 04, 2008 report was written by Ray Wagner, Joseph Feiman, Neil MacDonald, Arabella Hallawell, Ant Allan, and Gregg Kreizman. According to the report, vendors selected for the "Cool Vendor Report" are innovative, impactful and intriguing.
"We are honored to be included, which we believe is recognition by the world's leading information technology research and advisory company, Gartner," said Dr. Ulrich Lang, CEO and co-founder of ObjectSecurity.
About OpenPMF 2.0 - OpenPMF 2.0's powerful, yet easy-to-use technology is the only 'model driven security management' solution in the market today. It is the most flexible, extensible, standards based, and easy-to-use enterprise security management framework on the market. The patent-pending technology is based on 9 years of solid research and development by leading experts who are currently driving international standardization of model driven security. OpenPMF 2.0 is the most thought-through solution on the market and listed as a promising high-impact technology on Gartner’s “Hype Cycle for Information Security 2007”. OpenPMF 2.0 benefits include reduced cost, improved enterprise-wide security compliance, and low-maintenance security management for agile Service Oriented Architecture (SOA). OpenPMF 2.0 lets you manage security at a business-driven, intuitive high level of abstraction close to human thinking. OpenPMF 2.0 is fully customizable so that you can define customized policies in the way you think about security in the context of your organization.
About Gartner's Cool Vendors Selection Process - Gartner's listing does not constitute an exhaustive list of vendors in any given technology area, but rather is designed to highlight interesting, new and innovative vendors, products and services. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness of a particular purpose. Gartner defines a cool vendor as a company that offers technologies or solutions that are: Innovative, enable users to do things they couldn't do before; Impactful, have, or will have, business impact (not just technology for the sake of technology); Intriguing, have caught Gartner's interest or curiosity in approximately the past six months.
ABOUT OBJECTSECURITY - ObjectSecurity Ltd. is a Cambridge (United Kingdom) and San Jose (CA, USA) based world-leader in model driven security and authorization management. The company offers the ground-breaking model-driven OpenPMF enterprise security management ecosystem and various secure middleware platforms. ObjectSecurity provides services for model driven security, middleware security, SOA security, secure information sharing (e.g. CDM). Their customer base includes Agilent Technologies, BAA Heathrow Airport, Deutsche Telekom, ESG, European General Electric, Intel, QinetiQ, Royal Bank of Scotland, Real-Time Innovations, Twinsoft/Hewlett-Packard, US Naval Research Lab and others. ObjectSecurity specializes on information security for complex IT environments in mission-critical markets.
PR CONTACT Dr. Ulrich Lang, ObjectSecurity Ltd., info@objectsecurity.com, www.objectsecurity.com, +44 1223 420252/+1-800-898-9148
>>> PDF version: http://www.objectsecurity.com/doc/20080407_gartnercoolvendor.pdf
>>> Purchase the report: http://www.gartner.com/7_search/Search2Frame.jsp?keywords=objectsecurity

The need for standards NOW

2008-03-28T05:03:00.000-07:00

We need standards for Model Driven Security. There are primarily two reasons for this:

we need to avoid vendor lock-ins, because they will hurt end-users and vendors alike.
we need to avoid market fragmentation into dozens of products that have their own way of expressing security models

If industry is not commited to preventing vendor lock-ins and market fragmentation, then Model Driven Security would take much longer to become mainstream. Also, the shakeout in the market would be bloodshed, where innovation typically goes out of the window.

As a consequence, ObjectSecurity and several OMG members have come together at the Object Management Group (OMG) consortium to work towards a Model Driven Security Policy standard. This standard should specify a common vocabulary which allows policies to be transferable between different vendors' tools. An RFI has just been issued by the OMG.

Please contact us if you would like to know more about this.

Model Driven Security, accreditation, and agile SOA

2008-02-04T09:00:00.000-08:00

Defence companies and DoD/MOD are increasingly aware that they are "hitting the wall running" with SOA and certification/accreditation (e.g. Common Criteria).

The main problem is simple: SOA is about agility, and dynamically responding to change by allowing fast reconfiguration of the infrastructure "Lego blocks". Accreditation is about accrediting the assurance of a static system using some elaborative analysis process.

Unless the two are brought together, there will simply be no useful SOA in defence. Model Driven Security (MDS) can help achieve this.

IBM has recently (6/2007) published a Working Paper on the subject. It is not very dense, essentially they are saying that the challenges are due to complexity. The relevant information includes:
1) they then say "the new direction parallels the way Model Driven Architecture (MDA) and Model driven Development (MDD) have restructured the ... challenges and have provided architects ... better leverage over SOA complexity".
2) cultural and the accreditation community needs to be trained
3) support incremental change in accreditation practices
4) SOA should be deployed without agility (why would you buy SOA then at all?)
5) traditional accreditation approaches need to be adapted to match SOA better
6) security mechanisms are there and aren't really the problem

The first point echoes what ObjectSecurity has said since 2005: Model Driven Security is a highly useful concept to provide accreditable, agile SOAs with low-maintenance security policy management.

Please contact us if you would like to know more about agile SOA security and accreditation.

"Security Stove-Piping" and Model Driven Security

2008-01-31T17:18:00.000-08:00

It turns out that one of the main security issues related to SOA is that security is typically implemented in such a way that it cannot preserve the agility SOA (without security) promises. The reason behind this is simple: If I have a large SOA with many interactions, and I reconfigure (e.g. orchestrate) the SOA, I will need to check all the security policies and figure out whether anything changed. It is likely that a significant SOA reconfiguration changes security policies for many nodes.
Now imagine having to do such a manual process everytime you reconfigure the SOA - clearly not cost-effective and highly error-prone.
We at ObjectSecurity call this "security stove-piping".
Model driven security (as implemented in the patent-pending ObjectSecurity's OpenPMF 2.0) allows you to state your security intent in an intuitive, general, and undistorted way that remains relatively constant over time.
The semantic gap between this high-level intent and what needs to be enforced on the SOA infrastructure layer is then bridged using model driven security. The concept is related to Model Driven Architecture (MDA), and applied to security e.g. in our OpenPMF 2.0 SecureMDA sub-module.
The benefits are intuitive: As long as my high-level intent remains the same, I can reconfigure the SOA without any changes to the abstract security policy models. Contact us if you would like to know more about how this works in OpenPMF 2.0's TrustedSOA submodule.

By the way, if you happen to be in the area, then please feel free to sign up to our Peer2Peer session at the RSA Conference 2008, San Francisco, April 2008:

ObjectSecurity will present a peer-to-peer session "How can we secure SOA without losing agility?" at the RSA Conference 2008, San Francisco, CA, USA, 7-11 April 2008. Contact us to arrange a meeting.Abstract: In this Ask the Moderator session, ObjectSecurity discusses how SOA security must go beyond web services security. The core issue is how to specify and maintain consistent/effective security policies for *agile* SOA. This cannot be done manually (too complex/labor-intensive). New approaches such as Model Driven Security are needed. Session topics incl. security stove-piping, how to reduce cost/effort, architecture approaches, experiences, secure BPM SOA." (P2P-205A, 9 Apr 2008, 1:40 PM - 2:30 PM).

See you there!

Publications & Resources about Model-Driven Security

2007-09-25T13:08:00.000-07:00

This blog also tries to provide a forum for publications about model driven security. Please put any abstracts into the comments of this message and we will merge them into the main message.

ObjectSecurity released a publication Model driven security for agile SOA-style environments, by Dr. Ulrich Lang & Rudolf Schreiner at ISSE 2007:

There is evidence that many IT security vulnerabilities are caused by incorrect security policies and configurations (i.e. human errors) rather than by inherent weaknesses in the attacked IT systems. Security administrators need to have an in-depth understanding of the security features and vulnerabilities of a multitude of ever-changing and different IT "silos". Moreover, in complex, large, networked IT environments such policies quickly become confusing and error-prone because administrators cannot specify and maintain the correct policy anymore. Agile service oriented architecture (SOA) style environments further complicate this scenario for a number of reasons, including: security policies may need to be reconfigured whenever the IT infrastructure gets re-orchestrated; security at the business process management layer is at a different semantic level than in the infrastructure; semantic mappings between the layers and well-adopted standardised notations are not available. This paper explores how the concepts of security policy management at a high, more intuitive (graphical) level of abstraction and model-driven security (tied in with model driven software engineering) can be used for more effective and simplified security management/enforcement for the agile IT environments that organisations are faced with today. In this paper, we illustrate in SecureMDA™ how model driven security can be applied to automatically generate security policies from abstract models. Using this approach, human errors are minimised and policy updates can be automatically generated whenever the underlying infrastructure gets re-orchestrated, updated etc. The generated security policies are consistent across the entire distributed environment using the OpenPMF policy management framework. This approach is better than having administrators go from IT system to IT system and change policies for many reasons (including security, cost, effort, error-proneness, and consistency). The paper also outlines why meta-modelling and a flexible enforcement plug-in model are useful concepts for security model flexibility.

---

Gartner released a study Model-Driven Security: Enabling a Real-Time, Adaptive Security Infrastructure that defines:

"Model-driven security is the use of visual models or domain specific modelling languages during application design, development and composition to represent and assign security primitives — such as confidentiality, integrity, authentication, authorisation and auditing — to application, process and information flows independent of the specific security enforcement mechanisms used at runtime."

---

ObjectSecurity released a study Model Driven Security - A new security management approach applied to SOA - please contact to puchase.

---

DEFINITION: MODEL DRIVEN SECURITY

2007-09-25T11:26:00.000-07:00

ObjectSecurity is just finishing a larger study about model-driven security (MDS), as part of which they did an exhaustive search of different approaches, architectures, and definitions. In the end they settled for the following definition:

Model driven security (MDS) is the tool supported process of modelling security requirements at a high level of abstraction, and using other information sources available about the system (produced by other stakeholders). These inputs, which are expressed in Domain Specific Languages (DSL), are then transformed into enforceable security rules with as little human intervention as possible. MDS explicitly also includes the run-time security management (e.g. entitlements/authorisations), i.e. run-time enforcement of the policy on the protected IT systems, dynamic policy updates and the monitoring of policy violations.

Please put any suggestions into the comments field and we will modify this definition as needed.

As part of their study, they also analysed the product/vendor landscape in technical depth, and identified industry trends - this information can be made available upon request. Contact us here if you are interested in details or would like to purchase a report.

Gartner Hype Cycle for Information Security 2007

2007-09-06T07:41:00.000-07:00

Gartner has just released their new Hype Cycle for Information Security 2007, and model driven security is on it. ObjectSecurity's OpenPMF 2.0 (www.openpmf.com) has been identified as aleading product in this emerging area.

This shows that Gartner believes that model driven security is a critical technology approach to simplify enterprise security.

This blog is a public forum and we are welcoming any views on this.

Related blogs

2007-07-27T03:54:00.000-07:00

There is a related blog at www.trustedsoa.org and one with more of a middleware security focus at www.securemiddleware.org.

Looking for OpenPMF, SecureMDA, TrustedSOA?

2007-06-21T03:02:00.001-07:00

Did you get to this page because you are looking for ObjectSecurity's model driven security tools to automatically generate security policies from models? If so, please go to:

http://www.openpmf.com
http://www.trustedsoa.com
http://www.securemda.com/

Model driven architecture and SOA assurance

2007-03-17T06:45:00.000-07:00

Model driven engineering and SOA seem to complement each other very well. SOA enables horizontal decoupling of services (the issues of that are discussed on our other blog www.trustedsoa.org), and MDA enables horizontal decoupling (of models from implementations). Now this is obviously an oversimplification, but a nice upcoming architectural idea.
Security plays an important role here, and it is currently still a bit unclear to many how security can be defined and enforced in a manageable way. Of course there are webservices security specifications, but those (at least the ones that work in real-world products today) only deal with the protocol layer, which is the easy bit.
The harder bit is how to define and enforce policies for agile SOA-style enviroments. We at ObjectSecurity believe that model driven security (MDS) can help here because it allows to generate security policies for agile systems from a stable model.
But securing SOA is only one application of this useful concept...

Welcome & Introduction

2007-02-15T18:16:00.001-08:00

On this blog we will discuss model driven security. Please feel free to comment.

Defining security policies for complex, large IT environments is a difficult, cumbersome, and error-prone task. This is in particular the case for agile IT environments such as highly distributed component based systems and Service Oriented Architecture (SOA). We have shown that model-driven security, which allows the generation of security policies from the application models, helps build and maintain secure, agile IT environments.

Today software modelling is the accepted best-practice approach for developing flexible and reusable software applications where abstract application models are turned into software using a modelling toolchain. The OMG Model Driven Architecture (MDA) is the leading standard framework for software modelling. The ObjectSecurity/Fraunhofer FOKUS SecureMiddleware includes a full MDA development toolchain.
Why not apply the same logic to security and automatically generate security policies and high assurance from the application models? This way, you can be confident that the deployed system matches the models, and that you have not forgotten any security policy aspects.
And most importantly, you can reconfigure and redeploy your (possibly distributed) applications by simple changes in the model - the underlying software and security policies will be automatically matched to your models through the automatic MDA and SecureMDA tool chains.

This approachhas been showcased by ObjectSecurity (with their SecureMiddleware partner Fraunhofer FOKUS) in their SecureMDA technology.

Any comments on model driven security are greatly appreciated.

Ulrich Lang's Security Policy Automation & Model-Driven Security Blog

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

Model-driven security is now on Wikipedia

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

Analysis Series: NISTIR 7628 Smart Grid Security Recommendations

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

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

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

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

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

Give cloud users more control and close the loop: Standards-based policy in, standards-based audit out.

Implementing security policy automation: Free lunch? Unfortunately not.

"Least privilege", "need to know", insider threats & WikiLeaks

Cloud Security Alliance Presentation on Policy Automation: 8 Feb 2011, noon PST (WebEx & Sunnyvale, CA, USA)

Making sense of the buzzword soup: "policy-driven", "automation", "proactive", "enforcement" etc.

"Automating configuration and security management is the best way forward" (DEFCON 18)

New Whitepaper "Security Policy Automation: Improve Cloud Application Security ROI"

Policy Automation is Critical Because Security is About Cost-Benefit

Linkedin discussion "Security Policy Automation"

"Authorization as a Service"

Cloud application security discussion at Cloud Security Alliance (CSA)

Cloud Security: Controlling PaaS Information Flows

Business Process Sequence Policies

Update: Model Driven Security Accreditation (MDSA) publications

Upcoming Webinar with Intalio: Securing Agile Process-Led Applications with OpenPMF for Intalio BPMS

Model Driven Security Accreditation (MDSA)

New Analyst Coverage for Model-Driven Security

Ecosystem for model-driven security is getting ready

Revisited: Aligning business and IT security

Why "business process-led" model-driven security is useful

Model-driven security needs to be cross-platform

*New publications* about model driven security

Model Driven Security & SOA - take the survey & get involved

Business-driven security: Aligning business and IT security

"Security stove-piping" & agility (e.g. SOA)

Management vs. interoperability: Model driven security vs. today's authorization management

Model driven security recognized as impactful, innovative, intriguing by leading analyst firm

The need for standards *NOW*

Model Driven Security, accreditation, and agile SOA

"Security Stove-Piping" and Model Driven Security

Publications & Resources about Model-Driven Security

DEFINITION: MODEL DRIVEN SECURITY

Gartner Hype Cycle for Information Security 2007

Related blogs

Looking for OpenPMF, SecureMDA, TrustedSOA?

Model driven architecture and SOA assurance

Welcome & Introduction

New publications about model driven security

The need for standards NOW