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.
No comments:
Post a Comment