Model Driven Security Policy Automation

On this blog, ObjectSecurity co-founder and CEO Ulrich Lang discusses security policy automation and model-driven security. The aim of this blog is to advocate advance the state of the art in this area through exchange of ideas. - -

Wednesday 27 April 2011

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:
- 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?

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

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

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


Anonymous said...

Interesting. After spending a significant time learning principles from the Information Assurance Technical Framework (IATF) [i.e. keeping the problem space separate from the solution space], this article suggests nearly the opposite approach. More specifically, nearly all the questions say "How do you propose we..." -- areas that the ISS engineer is responsible for. In defense of this writing, I think these example questions are to whet the readers appetite. Otherwise, I agree 100% other wise with the article and appreciate the idea to "Discuss top down ('what are you trying to achieve?') instead of€ bottom up ('what product feature xy would you like to adopt?')." Spot On! - Thank you. KD, CISSP-ISSEP

Dr. Ulrich Lang, CEO, ObjectSecurity said...

KD, thanks for your comment. Not sure I fully understand your perspective as to how this relates to "keeping the problem space separate from the solution space". Could you please explain more? Which particular problem space and solution space are you referring to?
And yes, the ISS engineer is responsible for doing this, as long as the business actually asks for it...