This is the multi-page printable view of this section. Click here to print.
When the solution is designed, developed, and deployed, another job begins that may be a bit unfamiliar to many: Management. Regardless of how much development is happening, we still have a responsibility to manage what we roll out into production (or to other environments).
These need to be monitored, we must ensure we have regular backups that also need to be tested, that we have up-to-date disaster recovery plans, follow up on vulnerable dependencies, and much more.
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.
One of the most important aspects is everything around the code that may not necessarily be in code form. This includes the resources we use, network setup, and firewall openings. We should also review IAM and the permissions granted to resources and applications.
When design is verified during the operations phase, the team should at minimum check:
If there are elements in the design that are not implemented, these should be removed from the documentation. If we have implemented elements not in the design, the design should be updated, or the elements should be removed from the solution.
If the customer has opted out of a recommended measure or an additional service, that is not a deviation to be hidden. Document the decision and the residual risk it leaves. This matters both for managing expectations and so that someone can later explain why the solution looks the way it does.
To make verification traceable, the team should use a simple traceability matrix:
This makes it easier to document that requirements are actually realized and provides a clear basis for audit, handover, and incident response.
Examples of how this can be demonstrated:
For solutions with AI components, verification must extend beyond classic infrastructure and application design.
The team should verify:
This supports control areas such as “AI system verification and validation” and “Documentation of AI system design and development”.
For AI solutions, it is not enough to verify that the service responds. The team must also verify that the model’s results continue to fall within accepted parameters.
At minimum:
If deviations occur, the team must document actions and any risk assessment before further production use.
In practice, the documentation should make it possible to answer:
Traceable documentation reduces troubleshooting time during incidents and makes re-verification easier with major changes.
See also:
This depends greatly on the form and nature of the project, but in many cases, the IT organization at the customer (for projects hosted at the customer) can help. If the solution runs at Bouvet, Internal IT & Security can certainly assist with checking things like network configurations or point you in the right direction. There is also much you can do yourself, but check with Internal IT & Security before installing tools and running scans or similar.
A practical minimum is to conduct verification:
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.
Regardless of the need, remember that privacy applies to logs as well! Do not collect more information than you need, and logs must be deletable after a given period.
The goal of logging has three primary purposes:
What we log will vary greatly depending on who the customer is, the risk and threat landscape they operate in, and their needs for log information. In some cases, the customer will have its own security organization, typically a Security Operations Center (SOC), responsible for monitoring networks and applications. They will then have requirements for what and how to log, but if this does not exist, we must define our own requirements to have a starting point.
Below are some points that should be an absolute minimum, but the team must understand what is logged, why it is logged, and how this information relates to other requirements such as privacy.
If someone logs into the solution, this should be logged. This is especially important if it occurs from a place a user does not normally log in from, or if it happens with a different browser or client than usually seen. Failed logins should also be logged so that it is possible to act on them.
Errors during JWT validation or other session-related errors should also be logged so that they can be reviewed afterward.
Events where users try to access functionality they are not normally authorized for are important signals that must be captured. This could be as simple as a user getting or testing a URL from a colleague, but it could also be an attacker trying to map or test an application. Regardless of the cause, it is important information that must be preserved - if an incident occurs later, it is important to be able to say something about movement patterns and the like leading up to it.
If the application supports elevating or changing permissions, these are also typical events that need to be logged. Elevation is a mechanism where a user is given additional permissions, but these must be “turned on” before they are available - often with an extra level of authentication such as MFA or similar. Examples of such mechanisms are sudo in Linux or Privileged Identity Management (PIM) in Azure. When these are activated, it is important that the logs reflect this since errors or weaknesses in these solutions would be critical for the application’s security.
If errors occur in the application, these should also be logged. We should never give the user more information than absolutely necessary, but the details should be included in the logs so that they can be monitored or reviewed later.
If the application relates to the network, for example, by monitoring network connections, connections to other resources, or similar, disruptions or outages here should also be logged as they may be important indicators.
All applications have inputs that can be described, even free text inputs where the user can enter anything. Inputs that violate validation rules or instances where a user attempts to change information that should not normally be changeable are typical cases that need to be logged.
If the application supports file uploads or similar, deviations from expected files, such as discrepancies between file type and file signature or unusually large or small files, should be logged.
Logging and monitoring for AI solutions should be designed as an ongoing operational and governance mechanism that makes it possible to detect failures, anomalies, and security incidents, as well as document that the solution continues to operate as expected in production.
System and performance logs (e.g., error rates, response time/latency, availability, and service quality) should be collected in one place so that alarms or other notifications can be configured for unexpected events. Model/function performance should also be monitored with clear metrics (e.g., task success rate, quality/confidence scores where relevant), including alerts when unexpected behavior changes or degradation occurs over time.
The logs should support the principles outlined at the top of this article and should be included in the process for managing updates and changes to the application. Monitoring should also cover compliance and customer/other requirements, and should have an established support channel so that users can report failures, unexpected results, or misuse, allowing the organization to assess whether the system is being used outside its intended purpose.
How we log will also vary from project to project, the platform we run on, and the resources we are allowed to use. An important point to keep in mind when designing the logging solution is that logs are a target for attacks! An attacker who can exploit vulnerabilities and then manipulate the logs can both hide activity and plant false evidence.
All logs we have should be stored in a place where data can be added but not changed afterward. The advantage of using such solutions is that you can collect logs from many different sources, such as cloud resources, network components, and applications, in one place. This can give you insights from multiple dimensions when reviewing an incident, which can be useful in understanding the overall situation.
Being able to determine the sequence of events is incredibly important. We must therefore understand what the different log sources use as the basis for synchronizing clocks internally to be sure that an event on node A is related to another event two seconds later on node B.
It is also important to standardize log formats where possible. Much logging centers around the log message itself, which is typically text-based, but all metadata should be standardized where possible. Define what you need to see and ensure this is available from the various sources.
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:
….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.
Content-delivery-networks to distribute Javascript libraries have been used by many as an easy way to include these in the code without having to include them in the build or deploy process. The idea is good, but you then have a direct dependency on a source you have no control over, which can be abused to spread malware.
For especially critical dependencies, it may be appropriate to host artifacts in internal registries or maintain forks of packages, actions, and other build components. This reduces exposure to incidents at third parties, but also increases internal maintenance responsibilities.
This should be used selectively, typically when the dependency is business-critical, has high impact if compromised, and the team actually has the capacity to maintain it over time.
If you choose this approach, you should at minimum have:
Dependency management is not only about packages from external ecosystems. Many teams also operate internal components such as application servers, integration services, containers, or virtual machines. These should be included in the same maintenance routines as the rest of the solution.
Internal components should be kept up to date through a planned patch routine. Follow vendor release notes and assess what must be upgraded now versus what can be scheduled later. Components that are no longer supported should be phased out.
Components must be part of the overall security design. The team should maintain an overview of network exposure, identities/roles, and internal and external access paths. Apply a “deny by default” approach and only allow what is explicitly needed.
Internal components must be monitored in the same way as other services. Logs should be trustworthy, protected against tampering, and included in incident handling routines. See also Logging and Monitoring.
Software Bill Of Materials (SBOM) is an approach where we generate an overview of all dependencies with versions from our solutions. This overview should be tied to each release so it is clear which dependencies were actually in use at a given point in time.
For AI solutions, the overview should also include relevant AI artifacts such as models, model digests, tokenizers, and key dataset references where relevant. There are several more or less standardized file formats for SBOM, and they can be archived or included in other solutions to simplify central monitoring.
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.
The team should at minimum have control over:
Recovery must be tested regularly. The team should plan exercises that cover both simple errors and more complex scenarios.
Examples of exercises:
After each exercise, you should document what worked, what failed, and what measures need to go on the backlog.
An example recipe for the solution outlined in the article on system diagrams could be as follows. The premise of the plan below is that we have source code and pipelines available in, for example, Azure DevOps, and the application and resources have mysteriously disappeared from Azure:
It is worth mentioning that each of the points may need additional information, with references to access packages or group memberships for the person restoring to gain the necessary access.
If the solution has AI components, the recovery plan must also cover:
This supports control areas such as “AI system operation and monitoring” and “AI system recording of event logs” in an operational recovery context.
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.
This article addresses overall incident response and preparedness:
Operational recovery after destructive incidents is covered in the article about preparedness.
Before an incident occurs, the following must be clarified and documented:
All customers in Bouvet should have a defined contact point for incidents in Kunder (CRM). If the team has other contact points towards the customer, such as a security operations center (SOC), these should be documented as well so that an incident can be resolved as quickly as possible. In the other direction, the delivery manager is normally the formal contact point in the Bouvet team when the customer needs to reach you.
This must be known throughout the team, not just by individual persons.
Incident response requires that you actually see what is happening in the solution. The team must ensure that necessary logs are collected, protected, and made available for analysis.
For AI-component solutions, this additionally means:
This supports control areas such as “AI system operation and monitoring” and “AI system recording of event logs” in ISO 42001.
See also Logging and Monitoring for more detailed information on this topic.
Incidents can take many forms: vulnerabilities in applications or dependencies, operational anomalies, or active attacks.
If you discover or have reason to believe that a solution is under attack, this must be reported to the customer immediately. It is not always the case that the attacked solution is the target; in many cases, a solution is just a stepping stone to another. Therefore, it is also important to know what accesses and network openings it has to other solutions, so the customer’s IT organization can check these for signs of attacks.
If you come across signs that a solution has been attacked or used for an attack, it is also important to notify the customer so they can secure information and evidence for further investigation.
Incident handling and investigation is a specialized field. If you come across signs that something may have happened, notify your contact point and wait for instructions from them before taking any action.