Manage on Sikkerhet.bouvet.no - For Security Champions in Bouvet

Verify the Design

Mon, 01 Jan 0001 00:00:00 +0000

When we create a design for a new solution, there may be details we do not know, or unexpected complications may arise during implementation. This can result in the original design deviating from the final solution.

Documentation is crucial for understanding how a solution is set up and how it works, especially if an incident occurs that requires redeployment or disaster recovery. To ensure that the gap between documentation and the final product is not too large, we should always validate the design afterward.

Logging and Monitoring

Mon, 01 Jan 0001 00:00:00 +0000

Regardless of where a solution is deployed, we should ensure that it is monitored. Even if it is only available on the intranet with only internal users working from approved devices over VPN, logging information is important if one of these is compromised. A typical DevOps team will collect some information to help debug the application’s functionality, but we also need other information to assess the security context around it.

Dependency Management

Mon, 01 Jan 0001 00:00:00 +0000

When the team is in maintenance mode, most of the issues mentioned in the article on Software Supply Chain still apply. You will encounter situations where:

A critical vulnerability is discovered in a package you use
Packages are deprecated and replaced with something new that is not directly compatible with the old
Developers behind packages stop maintaining them
Malicious actors take over a package and use it to spread malware

….and certainly other scenarios that result in you needing to do something. To ensure that packages hitting one or more of the points above are addressed, tools like Sonatype and others offer the ability to monitor various stages of the lifecycle, with the option to alert you when vulnerabilities or other events affecting quality occur.

Preparedness

Mon, 01 Jan 0001 00:00:00 +0000

An untested backup is worthless. The same applies to a disaster recovery plan that has never been tested.

If the team has done the groundwork well, you have a plan for disaster recovery that describes how infrastructure, applications, and data are restored to normal operations.

The reasons for restoration vary: human error, delivery errors, vendor failure, unavailable infrastructure, or malicious events. The goal is always the same: to reduce downtime and data loss with predictable processes.

Contingency Plans and Incident Response

Mon, 01 Jan 0001 00:00:00 +0000

Many people think of security incidents as targeted attacks where someone attacks a solution by hacking it. In some cases, this may be correct, but an incident can be much more.

NSM defines a security incident as “A deviation situation where there is a potential for loss of confidentiality, integrity, and/or availability of information or ICT services. A security incident can occur as a result of a data attack, technical failure, or unintentional errors.” In other words, an incident can be almost anything that affects confidentiality, integrity, and availability. Different customers have different requirements for when to notify, escalate, and report, and to whom.