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.