This is the multi-page printable view of this section. Click here to print.
A secure solution begins with a good design! Much of the foundation for assessing whether a solution is secure comes from the design phase, where important trade-offs between cost, benefit, and risk must be made.
The articles you find under the topic design on this page will focus on the design process. Although this process may include much more than we have listed, we cover the essentials such as thorough documentation of what is to be built, critical clarifications, and the need for context.
Some requirements are implicit, such as the use of HTTPS/TLS, while others will be explicit and defined by customers or third parties. Even if the customer has no specific requirements, it is still important for the delivery team to create a list of requirements to ensure that the project’s framework is documented.
Most projects must adhere to various requirements from Bouvet, the customer, and external parties. All development teams must have control over the requirements that apply to the delivery:
Legal requirements can include general requirements related to privacy, but many industries operate with more specific regulations that impose additional requirements.
In many cases, it is clear to both Bouvet and the customer what applies, but it is important that the team verifies this before starting to develop the solution to avoid costly and time-consuming surprises. Regardless of what is defined and where, the team should document the requirements they adhere to so that this information is preserved for the future.
If no other security requirements have been defined, the security checklist can be a good starting point. It covers the major elements and can be completed by most teams without outside assistance. By using this checklist, the team gets an overview of the delivery status, including potential weaknesses and threats.
If the delivery requires a more thorough checklist, OWASPs Application Verification Standard (ASVS) might be a good alternative. This is a more comprehensive checklist that offers three levels of testing:
If the solution includes, or depends on, artificial intelligence (AI), additional requirements are needed beyond standard security requirements. AI systems introduce their own risk dimensions and these should be handled explicitly at the requirements level.
Security requirements for AI systems should cover:
For detailed implementation guidance, see Using Artificial Intelligence.
Correct network configuration matters in cloud, hybrid and on-prem alike. This page is meant as a short reference for secure network practice in project work.
Zero trust means not blindly trusting internal or external traffic. Use the principle as your default: verify explicitly, grant as little access as possible, and assume compromise.
Keep track of which IP addresses and ports you expose, and which services are listening on those ports. Check firewall rules, look in the logs and scan your own systems with nmap.
Maintain an up-to-date overview of:
Scan regularly to confirm actual exposure. nmap is an established FOSS tool for discovering open ports and services.
The use of scanner tools such as nmap must always be cleared with the owners of the infrastructure and network. If you sit in a Bouvet office and scan a customer’s Azure environment, you can easily trigger alarms at both Bouvet and the customer, as well as at the ISP.
Use a firewall to limit traffic within systems and between systems and the Internet. Use an allowlist where possible. Filter traffic at the application layer if necessary.
Practical ground rules:
For AI solutions, your operating model should be evaluated against requirements for ingress and egress control.
Minimum checks for both models:
Network configuration should be automated as far as possible, preferably through CI/CD and infrastructure as code.
When we build solutions, we often set up multiple environments, typically for dev, test, and prod, so that we can develop while the product owner tests new functionality and end users use the system in prod. It is important to distinguish between these environments to avoid situations where changes in one environment affect the use of another.
When designing a new solution, we must consider how to separate the environments. For cloud services, a common approach is to use different subscriptions per environment where possible. One subscription cannot affect another unless explicitly configured, but there are other possibilities as well.
There are other approaches to this as well, but regardless of the solution the team chooses, it is important to consider the overall cost/benefit against the requirements to be met.
For solutions that include artificial intelligence or machine learning, infrastructure segregation alone is not always enough. Teams should also consciously separate data, models, and rollout practices across environments.
Data used for training, evaluation, and production should be clearly separated. This reduces the risk of validating models on the wrong basis or allowing test and development activity to affect production-adjacent data.
Models, weights, and related configuration should be versioned and clearly tied to the right environment. The production model should not be overwritten by experimentation in dev or test.
When introducing new models or major changes, teams should consider mechanisms such as feature flags, controlled rollout, or other techniques that allow limited validation before full production rollout.
Authentication and authorization are crucial in all development projects. In short, authentication is about validating that a user represents the identity they claim to represent, typically by checking a username and corresponding password. Authorization is about checking that the user is allowed to do what they are trying to do. These are often abbreviated to authn for authentication and authz for authorization.
When validating a user, the most important thing is to not create your own authentication solution! Ensuring that such solutions are actually secure is a huge task, and one should instead use established solutions for this!
Single sign-on is a common solution used to avoid having individual applications handling usernames and passwords in corporate environments. The user authenticates via a central platform or the operating system; every application the user opens will then run in the context of that session so that the users avoid manual logins. The user experience is streamlined as a result, and the users are ’trained’ to not having to log on. Any attempts to phish credentials will then appear as out of the ordinary and suspicious.
Common approaches for handling authentication can be the use of third-party services or protocols that handle authentication against the customer’s AD/Entra. In many cases, we want to use Single Sign-On (SSO) to avoid the user having to enter username and password, especially for internal business applications.
Common solutions for handling login are to use libraries that take care of the entire flow, such as Microsoft.Identity.Web. Other alternatives can be the use of:
It is important to understand the needs of the solution and which authentication methods are available and possibly desirable.
The distinction between authentication and authorization is that authentication confirms who you are, while authorization checks that you are allowed to perform an action.
Similar to authentication, there are several approaches to how authorization is handled, and one needs to understand the best practices for the language and framework used.
There are still some main principles that should always be brought into the development process:
This is also known as default deny or principle of least privilege, and is used to ensure that, for example, an unauthorized user does not have access to anything beyond what is explicitly allowed.
If a user attempts to perform an action, it should always be checked whether the user actually has access to this. Remember that this check must be made against the authoritative source for access rights, and never against data that the user can manipulate!
Also known as the principle of least privilege. A user should never be given more access than is needed to perform a specific task. This is done to reduce the attack surface if a user is compromised, so that the scope of damage can be limited.
Using roles, role based access control (RBAC), is a common approach to granting user access. The goal is to define standard roles for an application so that access can be based on these. A common way to handle this, for example, with Entra or AD is to have:
This provides a better overview of who has access to what compared to users with individual access.
For solutions with AI agents, it is not enough to control end-user access alone. The agent itself often acts as a separate identity with access to models, data, APIs, and tools. These access rights should be treated as high-risk when they are too broad.
Practical principles:
When an agent gets access to external tools or APIs, you should also control which commands, endpoints, and data operations are allowed. This reduces the risk that mistakes, misuse, or compromise have a large operational impact.
For MCP-based integrations (Model Context Protocol), the same principles apply, with extra requirements for clear boundaries:
Access management also affects operational risk: broad agent permissions make incidents harder to detect and increase impact. Changes to agent access should therefore be logged and followed up together with normal operational monitoring, see Logging and monitoring.
This is a brief introduction to threat modeling. Methods and tools are mentioned briefly, with links for further reading.
You may have already done simple threat modeling without realizing it. For example, have you ever thought about why the users of the system you’re creating need to log in with a username and password?
When these choices were made, you automatically performed simple threat modeling. You certainly don’t want unauthorized individuals to access data in your system, and you don’t want anyone to see the data transferred between your users and your website.
The whole point of threat modeling is to think like an attacker.
There are several ways to identify threats to a system. In practice, the most important thing is to involve the right roles, define what needs protection, and systematically review how the solution could be attacked or misused. Some threats may already be handled, while others require new measures. The process should be repeated when the solution, data flows, or usage patterns change.
A simple workflow is:
Threat modeling is more important than which method you choose. Pick an approach your team can use consistently.
For solutions with AI, looking at application code alone is often not enough. The threat model should also cover the model itself, prompt flow, data sources, evaluation basis, and how the system is used in operations.
Typical questions include:
Some AI-specific threats that should be assessed explicitly:
For AI solutions, it is also important to describe misuse scenarios, not only direct attacks. A model can be technically available and functioning, but still represent high risk if it is used for decision support without sufficient human control points.
A threat model has limited value if it is created once and then put away. Findings should be used to define concrete security requirements, testing needs, and operational controls.
For example, an identified threat can lead to a need for:
For AI systems, the threat model should also be used when assessing changes to models, data sources, prompt templates, evaluation sets, and monitoring. Changes here can introduce new threats even if application code is unchanged.
The threat model must be versioned and kept up to date. Once threats have been identified, countermeasures must be described, and their effectiveness assessed. A common approach is to give the threat a value indicating severity, for example, 1-10 where 10 is the worst. Countermeasures are assessed similarly but with the opposite scale where 1 has little effect and 10 (or up to criticality) has the highest effect. The sum of these gives a residual risk that indicates the remaining risk:
Identified Threats Criticality Countermeasures Residual Risk
Threat 1 8 8 0
Threat 2 2 0 2
Threat 3 4 3 1
Total 14 11 3
When a risk is identified, it is important that the risk owner is involved, as they are responsible for ensuring that the project delivers quality in line with expectations and requirements.
It is important that countermeasures are validated for them to be effective. The threat model should be reviewed regularly to see how the situation has changed, and if the total criticality or residual risk exceeds a threshold, consider measures to reduce them.
For systems in active operation, the threat model should also be used when deciding which events to log, what to monitor, and which deviations should trigger alerts. This is especially important for AI systems, where misuse, degradation, or unexpected model behavior can develop gradually over time.
When designing a solution, it’s essential to have clear and comprehensive drawings and diagrams that show the planned design. This is already done by many development teams without necessarily being a formal requirement, but it’s still worth mentioning here.
System diagrams should provide enough information to:
Although there is a lot that can be documented here, we focus on the most important aspects:
If the solution includes artificial intelligence or machine learning models, these should be explicitly documented in the system documentation:
Without this information, it is difficult to maintain a clear overview of risk, data flow, and compliance around AI components.
Below are examples of the points listed above. The diagrams you produce do not need to be identical; the most important thing is that they contain enough information to be used for their intended purpose and are understandable to the team.
To easily get started with designing diagrams and sketches, tools like Miro or Draw.io can be used. The latter is free and offers storage of drawings in the browser, locally on the machine as XML, and much more.
The diagrams do not need to be perfect or contain every conceivable detail. Assess the need and work on gradual improvements over time.
This diagram should be a high-level introduction to the solution, showing all the major components and interactions between them.
The goal of the network diagram is to show the network topology, with all the various virtual networks, subnets and resources or servers and firewall openings between them. A good network diagram visualizes the data flow between points for everyone to see, not just developers.
Network diagrams should be created for all environments, providing necessary information on all resources in all environments, as well as connections between them.
The data flow diagram shows the data flow of the solution. This should include all direct dependencies not part of the project, so that it is possible to understand where data originates and all the nodes it interacts with.
An IAM-diagram describes where users originate, and the roles and permissions assigned to users, services and devices on the various resources.
This can also be drawn, but often a simple list is enough. This should contain all direct dependencies of the solution being developed, with a brief summary containing descriptions of what the team depend on.