News + Resources

“Cloudflare acknowledged that it had failed to rotate these credentials, mistakenly assuming they were unused¹” 

This quote from the February Hackernews report on the recent alleged nation state attack on Cloudflare caught my eye. It would be easy to raise one’s eyebrows and roll one’s eyes at the news that yet again, stolen credentials had unzipped one of the world’s most important internet security companies. But that is not what caught my eye. 

The quote above reflects more than we might think about the humanity of these companies; while it is damaging for Cloudflare that their security was compromised, this admission at least shows that there is still room for improvement: we are not coming up against implacable AI fuelled hacking just yet. 

To assume is to make an ass of you and me 

It is an old saying but it is still largely correct: 

It is human to assume that things will go right. When we don’t know whether something has been done or can be done, we usually assume that it will be okay. Yet even the most cursory look at a service level agreement, or a review of past experience might tell us that an assumption of positive outcome is fundamentally dangerous and flawed. The  development of manned space flight is a case in point: NASA took a safety-first zero assumption to risk, especially after the Apollo 1 Oxygen fire which killed three astronauts. 

The fact that Cloudflare had assumed something had been done and got caught, means that next time no such assumption will be made and as a result they will be more likely to do things right.  An expensive lesson, but an effective one. 

We continually ask our clients to check their assumptions.  Some of these are basic but nonetheless vital: 

Are you sure your suppliers will be able to provide 500 laptops configured to your build standards the moment you are breached? What does it say exactly on your service level agreement with them? 

Another question:

What happens if your major supplier is attacked.  Do they have any obligations to maintain service to you or even to inform you? What is your recourse in your contract for supplier failure? Or do you think it will just be okay? 

One of the reasons why we prefer to make assumptions rather than to obtain ground truth is because we don’t enjoy embarrassing people or having a confrontation.  Those who will know me will recognise that I am not a fan of the brutalist school of management.  But even I recognise that it is worth asking the question to make sure that the assumptions underpinning the plan, are true. 

A valid exercise for any CISO is to review their incident response plan and to underline any phrase that appears to be an assumption.  Where is the SLA that says that supplier X will indeed be ready to provide you with continuity of service in the event of a breach? Where is the contractual commitment that 300 laptops will always be waiting for you on a hot-swap basis just in case? 

It is much more difficult when you are relying on assumptions made based on commitments from people with whom you work. How do you check these commitments without appearing to cast doubt on a person’s reputation and credibility?  You have no SLA to guide you; no contract to shape each other’s behaviour. How do you know that one department will contribute as needed to the common endeavour at a time of maximum stress and career defining post mortems. 

During the Reagan era, the Americans used the Russian phrase “trust, but verify” during the Intermediate Nuclear Forces reduction treaty negotiations. 

Under the nuclear weapons treaties, the two superpowers had to get each other to reduce their weapons holdings to the agreed levels. But relying on trust alone was never going to be enough: each required stringent verification processes to ensure that the other side was not cheating. In the context of cyber security, the conundrum is similar.   The only way to be sure that requisite activities occur is to require people (suppliers or staff) to agree formally to do what is required of them, whether in job descriptions or written instructions, service level agreements or other concrete terms.  Cyber allows no room for assumption: you cannot afford to trust colleagues or suppliers to do things they are not formally required to – in a cyber event, getting something wrong is usually career threatening, and people will not usually volunteer for something risky unless it is their job.  The only way to be sure is to obtain verifiable solid, written, commitments that things will happen in a prescribed manner should they be required. Otherwise who is the ass? 

As always, we are here if you wish to discuss the above or any other cyber related topic.