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!