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

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

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

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

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

 

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

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

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

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

- How is automation used to achieve all this?

2) HOW TO PREVENT INSIDER BREACHES, LEAST PRIVILEGE?

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

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

- How is automation used to achieve all this?

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

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

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

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

- And how is compliance reliably demonstrated after updates?

- How is automation used to achieve all this?

4) CUSTOMER PAIN POINTS:

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

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

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

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

Comments on this are greatly appreciated as usual.

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

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.

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

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)

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.

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)

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"

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

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"

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

"Authorization as a Service"

"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)

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

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

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

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

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)

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:

1. Does the actual security match with the stated requirements?
   
2. 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

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

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

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

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

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

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

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

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)

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

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

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*

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

1. we need to avoid vendor lock-ins, because they will hurt end-users and vendors alike.
2. 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

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

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!