Archives For Assume Breach

It is very interesting to understand how attackers work, and sometimes it is also scary to see how unprepared we are. This in an unbalanced war, which we are losing.

Ransomware is on the rise, and it is more and more dangerous. But it is not the only problem. Many of my customers are totally unprepared, yet they say that they have not been compromised in the past, but for a couple of well known incidents. No wonder, considering that their detection controls are in some cases totally ineffective.

Sometimes customers have no clue of where their assets are or how they can be exploited. The most absurd thing to see is that many organizations have VIPs that are not tolerant toward the limitations imposed for Security reasons, and they have the power to require exemption: as a result, sometimes those who have the highest value for an organization are the least protected!

Attackers already know all this and understand your business better than you. They are going to find your weakest spots and to hit them, hard. Many are not able to see that coming and even less to respond properly.

FireEye’s incident response business further reports the mean “dwell time” for breaches in EMEA is 469 days, versus 146 globally.


In other words, in EMEA the time an attacker on average remains undetected in a victim’s system, is more than 3 times higher than the World average!

We have to change this and soon, and it all starts from adopting a more active stance toward Security. It is not a cost: it is a necessity!

David Ferbrache from KPMG describes the situation very well, and SC Magazine has an article about it that can be both alarming and illuminating:


Computing means processing Data. Therefore, it is only natural that Data Protection is one of the most important things when you discuss the Security of an Application, regardless how it is implemented, where it is hosted and how it is maintained.

Protecting Data is like storing it in a safe: you will have to choose the type of protection and you will get a key, that is a token granting access to that Data only to you and to the users who are allowed to access it. This key could be in the form of an Identity, in the form of a cryptographic key or in any other form; this is not really important for the sake of our discussion.

The key is very important, even if not as much as Data. Its importance is not due to anything intrinsic in it: you could safely discard a Key under controlled situations, and none will complain with that. It is important only because it allows access to Data; sometimes, the Key is the only thing that keeps attackers from accessing your Data.

So, you will want to keep your key safe as well. And this is the really hard thing to do: how could you protect it without involving another key, and then another key, and then yet another key? Sometimes you can leverage on services offered by the Operating System, like Microsoft Windows Data Protection API (DPAPI), or store the keys in hardware modules like the Hardware Security Modules (HSM). But really, this is only part of the answer. That is, even if you find a way to protect your keys effectively, you need a way to provide them to any instance of your Application, if it is installed on multiple servers in multiple locations, and to be ready to replace the keys – and discard the old ones – when (not if!) they are suspected to have been compromised or for any other reason.

It is all too common not planning for Key Management tasks like those. In my experience, I have found more than a couple of customers which had not planned for that: typically they placed the keys in code as strings or as resources, without planning for when they need to be changed. The net result is that they are not changed, and sometimes they are the very same in the Development as in the Production environment. The only thing that is worse than that, is not to put in effect ways to understand when you are under attack and therefore you need to change the keys. It goes without saying that those customers were more than happy with the situation, because they had no clue about actually being under attack.

Much better to Assume Breach and act accordingly.