May 2021 – Cyber Security Leadership

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.