Cyber incident response: crisis communication

The worst time to write a security incident response plan is during an incident itself. Anticipating adverse events and preparing playbooks for likely scenarios and testing them in advance are important facets of a wider cyber resilience strategy.

Incident response, however, is not only about technology, logs and forensic investigation – managing communication is equally important. It is often a compliance requirement to notify the relevant regulator and customers about a data breach or a cyber incident, so having a plan, as well as an internal and external communication strategy, is key.

Security incidents can quickly escalate into a crisis depending on their scale and impact. There are lessons we can learn from other disciplines when it comes to crisis communication.

One of the best example is offered by the Centers for Disease Control and Prevention (CDC). The resources, tools and training materials they have created and made available online for free have been tested in emergency situations around the world, including the latest Covid-19 pandemic.

CDC’s Crisis and Emergency Risk Communication (CERC) manuals and templates emphasise the six core principles of crisis communication:

1. Be first. Quickly sharing information about an incident can help stop the spread, and prevent or reduce impact. Even if the cause is unknown, share facts that are available.

2. Be right. Accuracy establishes credibility. Information should include what is known, what is not known, and what is being done to fill in the information gaps.

3. Be credible. Honesty, timeliness, and scientific evidence encourage the public to trust your information and guidance. Acknowledge when you do not have enough information to answer a question and then work with the appropriate experts to get an answer.

4. Express empathy. Acknowledging what people are feeling and their challenges shows that you are considering their perspectives when you give recommendations.

5. Promote action. Keep action messages simple, short, and easy to remember.

6. Show respect. Respectful communication is particularly important when people feel vulnerable. Respectful communication promotes cooperation and rapport.

Cyber security professionals can adopt the above principles in crisis situations during a cyber incident, demonstrating commitment and competence and communicating with transparency and empathy both inside and outside of the organisation.

Secure software development lifecycle and DevSecOps

In the DevSecOps paradigm, the need for manual testing and review is minimised in favour of speed and agility. Security input should be provided as early as possible, and at every stage of the process. Automation, therefore, becomes key. Responsibility for quality and security as well as decision-making power should also shift to the local teams delivering working software. Appropriate security training must be provided to these teams to reduce the reliance on dedicated security resources.

I created a diagram illustrating a simplified software development lifecycle to show where security-enhancing practices, input and tests are useful. The process should be understood as a continuous cycle but is represented in a straight line for the ease of reading.

There will, of course, be variations in this process – the one used in your organisation might be different. The principles presented here, however, can be applied to any development lifecycle, your specific pipeline and tooling.

I deliberately kept this representation tool and vendor agnostic. For some example tools and techniques at every stage, feel free to check out the DevSecOps tag on this site.

Static code analysis for security

There is a strong correlation between code quality and security: more bugs lead to more security vulnerabilities. Simple coding mistakes can cause serious security problems, like in the case of Apple’s ‘goto fail’ and OpenSSL’s ‘Heartbleed‘, highlighting the need for disciplined engineering and testing culture.

I touched upon embedding security in modern software development practices in my previous blogs on agile security and DevSecOps culture and recommended some tools to help automate managing vulnerabilities in open source libraries, help preventing committing secrets in code and integrating application security testing in the CI/CD pipeline. In this blog I would like to touch upon the connection between code quality and security and explore static code analysis.

An open source tool that is gaining a lot of momentum in this space is Semgrep. It supports multiple languages and integrates well in the CI/CD pipeline. You can run Semgrep out of a Docker container and the test results are conveniently displayed in the command line interface.

The rule set is still relatively limited compared to other established players and it might find fewer issues. You can write your own rules, however, and things are bound to improve as the tool continues to develop with contributions from the community.

A more well-known tool in this space is SonarQube. You can still use a free Community Edition for basic testing but advanced enterprise-level features would require a paid subscription. CI/CD integration is possible, inter plugins (like the one for ESLint) are also available.

SonarQube has a dashboard view which scores your code across reliability, security, maintainability and other metrics.

As with any tool of this type, to get the best use out of it, some initial configuration is required to reduce the number of false positives, so don’t be discouraged by the high number of bugs or “code smells” being discovered initially.

Keeping in mind the fact that no amount of automation can guarantee finding all the vulnerabilities, I found SonarQube’s analysis around Security Hotspots particularly interesting. It also estimates a time required to pay down the tech debt which can serve as a good indicator of maintainability of your codebase.

It is important to remember that static code analysis tools are not a substitute for the testing culture, code reviews, threat modelling and secure software engineering. They can, however, be a useful set of guardrails for engineers and act as an additional layer in your defence in depth strategy. Although these tools are unlikely to catch all the issues, they can certainly help raise awareness among software developers about quality and security improvements, alert about potential vulnerabilities before they become a problem and prevent the accumulation of tech and security debt in your company.

Security dashboard

Building on my previous blogs on CISO responsibilities, initial priorities and developing information security strategy, I wanted to share an example of what a security dashboard might look like. It is important to communicate regularly with your stakeholders and sharing a status update like this might be one way of doing it. The dashboard incorporates a high-level view of a threat landscape, top risks and security capabilities to address these risks (with maturity and projected progression for each). Feel free to use this as a starting point and adjust to your needs.

The dashboard above aligns to the NIST Cybersecurity Framework functions as structuring your security programme activities in this way, in my experience, allows for better communication with business stakeholders. However, capabilities can be adjusted to align with any other framework or your control set of choice. Some of the elements can be deliberately simplified further depending on your target audience.

Feel free to refer to my previous blogs on developing security metrics and KPIs and maturity assessment for more information.

Cyber security metrics and KPIs

Security professionals have access to the amounts of data never seen before. Antivirus software, firewalls, data loss prevention solutions – they all generate a staggering amount of alerts.

Security operation centres and the underlying SIEM technology allow us to aggregate, correlate and make sense of these vast troves of data. We can create dashboards and metrics that might look slick and even be useful to security teams but do such data add value to business stakeholders? Do they tell a story to the Board?

More

Book signing

I’ve been asked to sign a large order of my book The Psychology of Information Security and hope that people who receive a copy will appreciate the personal touch!

I wrote this book to help security professionals and people who are interested in a career in cyber security to do their job better. Not only do we need to help manage cyber security risks, but also communicate effectively in order to be successful. To achieve this, I suggest starting by understanding the wider organisational context of what we are protecting and why.

Communicating often and across functions is essential when developing and implementing a security programme to mitigate identified risks. In the book, I discuss how to engage with colleagues to factor in their experiences and insights to shape security mechanisms around their daily roles and responsibilities. I also recommend orienting security education activities towards the goals and values of individual team members, as well as the values of the organisation.

I also warn against imposing too much security on the business. At the end of the day, the company needs to achieve its business objectives and innovate, albeit securely. The aim should be to educate people about security risks and help colleagues make the right decisions, showing that security is not only important to keep the company afloat or meet a compliance requirement but that it can also be a business enabler. This helps demonstrate to the Board that security contributes to the overall success of the organisation by elevating trust and amplifying the brand message, which in turn leads to happier customers.

Cyber security: a global perspective

While in the lockdown in the UK, I was reflecting on the many countries I had a chance to work and travel to in my career so far.

Following-up from my previous blog on lessons I learned from working in cyber security across multiple sectors, geography is another lens I can apply when thinking about the diversity of cyber security projects I had a chance to contribute to and people to work with.

It was a pleasure to serve clients and collaborate with colleagues from all over the world and this really gave me a global perspective on cyber security challenges across continents.

I was fortunate to visit more places than mentioned on this map, however, the ones I selected here were the most memorable and challenging from a project perspective. 

There are still plenty of countries I have yet to explore, so I’m eagerly awaiting the time when it’s safe to travel again.