scary hacker

You are a member of C-suite and your nascent company is gaining traction. Many investors and clients ask you about your cybersecurity. It is not something you have done in the past, so where do you start? Hiring a CISO will help, but it can be a long process. What can you do now to make your company secure?

You could pick a framework such as the NIST Cybersecurity v2, or CIS, or Cyber Essentials. Those are good, and you probably should do that eventually. However, they can be daunting. If you are aiming for SOC-2 or ISO 27001 then the road ahead is even more arduous and expensive.

There are three things you can do right now to help immediately.

First, create a risk register.

A risk register is a management tool to track identified risks, their mitigations, and to fulfil regulatory compliance.

You can find many paid and free solutions to do that, but really all you need is a few pieces of paper, a pencil, and a rubber — if you make mistakes. At the top of the page, write what the event is. Something like “All endpoints are not protected”. Then, write a small description of the event: what can happen to cause trouble and how much trouble. In our case, a user could install some malware on their endpoint, leading to a total exfiltration of all company documents.

Next, you have two fields you need to assign: a likelihood and the impact. The former is how likely that event is to happen. The second is if that event happens, how damaging is it? Generally, both are ranked from 1 (low) to 5 (critical). Multiplying those two numbers gives you the severity of the event. Any risk scoring over 15 should be looked at as a matter of urgency.

The next step is to think of mitigations: what can you do to reduce the likelihood or the impact (or better both) of the event occurring? In our example, it would be MDM and EDR/XDR software. Once those mitigation steps are taken, re-score the likelihood and impact, leading to a new security score.

You do not have to create all these events yourself. You can and should ask everyone at your company to think of them. A lot will be the same, some will be surprising. Then, you can score things and decide which mitigations you can apply soon and which are best left for later. This way, you tailor your cybersecurity response to your business needs, which are unique to your business.

Second, do some threat modelling.

As the threat manifesto states, the best time to start threat modelling is right now. Again, there are a myriad of tools available to help you with this. Once again, a few pieces of paper are all you require for now. Pick any IT system or software architecture diagram and think: where can I attack it? Now, think how you can protect the CIA (Confidentiality, Integrity, Access) of your data?

You could use the same likelihood and impact as defined above, with the same mitigation and re-scoring steps. Nothing wrong with that. The mitigations could already be in place (great!), but if they are not, they can be easily added to your backlog as security issues/features.

For example, you could have a sign-in using only a username and passwords. A threat would be a weak user password leading to unauthorised access. A simple mitigation would be to implement MFA and have a password policy. How rapidly you need this feature is something for you to decide: do you accept the risk or not? But at least, you know there is a threat.

Third, create and train incident management

Two and half thousand years ago, Archilochus said, “we don’t rise to the level of our expectations, we fall to the level of our training.” This is still true today. You can create an incident management system trivially, just pick one of many templates available, for example the ITIL Incident Management one. It might look daunting at first, but it is actually simple.

As soon as an incident is raised, there is one, and only one, person responsible and accountable for it. First, that person triages the alert and determines its urgency. The second step is to resolve the problem, inform the relevant people, and document what is going on. Finally, a lesson learned session should happen at some time in the future to see what could have been done better. The incident commander can (and should) delegate roles to other people in the team better suited to the task at hand. The rest is details, and the devil does lurk there, but this is beyond here.

However, even if you have the best incident management system™, it will be utterly useless if no one is trained to use it. A prime example of this is the 1967 USS Forrestal fire. A catastrophic failure led to a fire on the deck of the aircraft carrier. This fire caused ordinance attached to fighter jets to explode. This killed nearly all the trained firefighters on the ship, the remaining crew, who had no formal firefighting training, were forced to improvise. The final toll left 134 men dead, 161 more injured, and millions of dollars in damage.

Running training exercises, first as table-top role playing then on real incidents created in testing and staging environments (not production) is essential. As for the lesson learned, it is worth remembering why complex systems fail…

Final thoughts

Those three steps are not sufficient, but they are necessary foundations to a good cybersecurity hygiene.

If you would like to know more, please book a call with us. We know what works, what does not, and how to get you to get those compliance accreditations with minimal hassle.