CS4NSP Episode 5: Any safe can be cracked; lets look at the security of your asset’s environment

Brief at the Start

Go straight to the full length version

The environment hosting the asset needs appropriate security controls to protect itself from direct attack, and to control the users access to the asset; responsibility for these controls varies between different types of cloud services and on-premise solutions. 

Cyber security strategy must be rooted in the specific context of the asset being protected—whether that’s sensitive data, systems, or services. Effective security is achieved by ensuring the surrounding environment (networks, infrastructure, applications) is both Secure by Design and Secure in Operations. This means hardening systems, removing unnecessary features, patching vulnerabilities promptly, and continuously monitoring for suspicious activity. Alongside this, enforcing trust in users and devices through Trust Personas and Device Profiles ensures that only appropriately verified individuals and secure devices can access or interact with critical assets, particularly for actions like updating websites or managing sensitive data.

A practical example of these principles is an email server, which is often a high-value target. To protect it, access must be tightly controlled, services minimised, and administrative routes locked down. However, most organisations now use cloud-based services like Microsoft 365 or Google Workspace, introducing the Shared Responsibility Model. While cloud providers secure the infrastructure, the customer remains responsible for user identity, access controls, and the security of the laptops and mobile phones they use. Ultimately, all risk ownership remains with the customer, so due diligence over the cloud service provider and configuration oversight are essential—because once damage is done, even contractual recourse can’t undo reputational or operational harm.

Get the Full Version

Where the Rubber Really Hits the Road

So far, we have been discussing some concepts that don’t themselves deliver any outcomes. We can talk esoterically about the different levels of trust we might have in a user or a device. However, we can only move from the conceptual to the real once we bring context to the discussion. The ASSET we are protecting defines the context¹. As discussed in Episode 2, we need to assess how the asset might be at risk and how it would impact the organisation if risk occurred.

The Asset is most likely to be a particular set of information, a piece of business-critical equipment or an essential service. This asset will exist within an environment that will enable it to be accessed, controlled or leveraged by the users. This environment will usually combine applications, networks, and computing infrastructure.

For example, let’s consider your organisation’s financial management information. You wouldn’t want this to fall into the wrong hands, and certainly wouldn’t want someone to maliciously delete or modify it. You might hold this information within an accountancy application or ERP software. The application will run on a server somewhere connected to a network, which forms the environment and must be defended to protect the asset. It has two primary security objectives it needs to achieve.

Objective 1 : Protecting Itself

The environment needs to be designed, built and managed to protect itself. It needs to prevent unauthorised individuals from gaining direct access to it and the assets it is holding. This is what we mean by security architecture, and the discipline required is that the solution is Secure by Design².

The network will need security devices such as firewalls to limit what is exposed and can be attacked. There will likely be other network controls, such as proxies, to add separation layers between users and the application. Intrusion detection or protection systems will identify suspicious access and, if necessary, block it. Management access shouldn’t be exposed to the public internet and should be placed behind additional controls to prevent them becoming a back door for attackers to attempt to access.

It is not just about securing the network infrastructure. The operating systems, software and applications also need to be secure by design. Any unnecessary features and services should be turned off or removed. Any libraries and third-party applications should be reviewed to identify how they might introduce weaknesses that an attacker could exploit. The overall solution architecture will need to consider all of the risks that have been identified and introduce controls to reduce the likelihood that the risks will occur and their impact if they do. Reviews should be conducted on any software being developed to ensure it doesn’t contain the most common design vulnerabilities, such as the infamous SQL Injection and cross-site scripting attacks. Other security reviews, such as Penetration Tests³, may be required if the risk is sufficiently high.

Being Secure by Design is not sufficient though. The environment also needs to be Secure in Operations. All software has vulnerabilities, and when one is identified, changes need to be made, and the patch must be implemented before it can be exploited. If the vulnerability is critical and an update is unavailable, new controls may be required to stop it from being exposed to an attacker.

Murphy’s law applies to cyber security as well. You can reduce risk, but you can’t eliminate it. If something can go wrong you have to assume that it will go wrong at some stage. Hence, applications and their environments should be monitored and alerts set up to be triggered if unexpected or suspicious activity occurs.

Objective 2 : Enforcing People and Device Trust

The environment also acts as the gatekeeper to determine who and what is authorised to access the asset and what is not by applying and enforcing the Trust Personas⁴ and Device Profiles⁵ described in chapters 3 and 4. The risk assessment, which determines how the asset might be attacked and what impact this would have on the business, should be used to define how stringent these controls over the people and devices should be for a particular use case or user type.

If the asset is a corporate website, you may place few, if any, constraints over the individual viewing the website or the device they are using. You assume they are inherently untrusted, and you apply very stringent controls over what they are able to do – normally they can only view content or fill in pre-defined forms. However, you should demand far higher levels of assurance over the users who are authorised to update your website’s content and the devices they are using. To illustrate this, the following are two particular risks that you may want to control (other risks also exist!).

• The risk that malicious, embarrassing, illegal or defamatory content is published on the website. You will need a high level of assurance that the individual making the update is who they say they are, introducing controls like multi-factor authentication in case someone steals their password.  You might also prevent any content being updated from the public internet, and ensure it can only be done from a corporate network or when accessed over a separate VPN⁶. This adds additional controls that the user will need to navigate through.
• The risk that malware is published to the website leading to site visitors being infected. If your website contained malware that infected visitors, the impact on your reputation could be significant. You can avoid a malicious individual deliberately uploading malware by restricting who is authorised to modify content, and applying a high Trust Persona over those roles. However, you also need to reduce the risk that a website manager inadvertently uploads malware because they are updating content with a compromised or infected device. For this reason, you may have a policy that only an authorised device managed by your business is used to access the management interface of the website.  This may rely on procedural controls, but it will be more effective if you design the environment to prevent unauthorised devices from logging in.  You can reduce this risk further with controls built into the environment, such as restricting the file types that can be uploaded to the website and installing anti-malware to check files when uploaded or accessed.

A worked illustrative example

Let’s take a look at an example that brings these concepts together. As with other examples, this one is intended to illustrate the concepts and by its nature is simplified and incomplete. It should not be interpreted as a recipe to secure a similar solution in real life.

In this example, we have a basic email server that will store all of a user’s messages, forward new emails sent by the user to the recipients, and receive incoming emails intended for the user. The user will access the server either using an email application installed on their device or via a web application using a browser.

The Risks

1. There is the risk that a malicious party gains access to a user’s email account and accesses sensitive information, leading to loss of IP, breach of privacy law, third-party damages, reputational damage and potential regulatory fines.
2. There is the risk that a malicious party gains access to a user’s email account and sends impersonating emails that may cause the recipients to do things that lead to financial loss, business disruption, significant reputational damage, third-party damages and potential regulatory fines.
3. There is the risk that malware is sent to users via email, causing wider security breaches, business disruption, third-party damages, significant reputational damage and potential regulatory fines.
4. There is the risk that a malicious party sends misleading and/or offensive emails via an external service that damages the reputation of valid corporate email, causing valid emails to be treated as spam and leading to business disruption, financial loss, and significant reputational damage.
5. There is the risk that a malicious party gains access to the email service and deletes messages or renders the service inaccessible to authorised users, causing significant business disruption and reputational damage.
6. There is the risk that an authorised user sends sensitive information to a recipient not authorised to view it either accidentally or deliberately, causing financial loss, third-party damages, reputational damage and potential regulatory fines.

The Environmental Controls

Email is one of the most critical corporate services because it is so pervasive across business processes, it will contain significant quantities of information, it offers an easy channel to send information widely, and people will assume the identity of the sender is accurate. For this reason, it is also one of the services most frequently targeted by hackers, either by hijacking an individual’s account or compromising the system as a whole. For this reason, the email server should be treated as one of the organisation’s “Crown Jewels”. Ideally, it should be placed in a tightly controlled part of the network, potentially separated (or segregated) from other services. Communication over the network should be restricted to receiving email, sending email, and the user accessing their email account either via the email application or via the web browser. The identity of the user should be confirmed with strong authentication involving at least a long and hard to guess password supported by a second-factor. Administrator access to the server should be further constrained so that it can only be achieved using an authorised device from the corporate network and protected with additional security measures such as a VPN.

The server should have a minimal operating service installed, with only those features and functions enabled that are necessary for the email service to operate.

The Difference with Cloud Services

But the idea of a business managing its own email server is rather antiquated.  The majority of organisations now will use a cloud service, such as the ones provided by Microsoft 365 and Google Workspace, rather than running their email servers in their own data centres. With cloud services, the service provider is responsible for some of the security controls, and the customer is responsible for others. This Shared Responsibility Model is a key element of cloud security, and it is important to understand where responsibilities lie to ensure nothing is overlooked. Let’s look at what the situation is with cloud-hosted email services:

• Person. The cloud service provider is responsible for providing the technology to control access to a persons account.  But it is the customer’s responsibility to ensure that user accounts are created when someone joins and are disabled when they no longer need to access the email.  The customer is responsible for ensuring that users don’t share their passwords, and that the password is sufficiently strong either by configuring the rules in the service or educating the users of the policy. The customer may also be able to apply greater or lesser security, such as by enabling or disabling Multi-Factor Authentication. As you can see, the customer is responsible for most of the security related to the authenticity and authority of the user.
• Device. The customer is responsible for ensuring the user’s device is secure and well-managed. The service provider may provide tools to enable this, but it is the customer’s responsibility to decide which of those tools to use and how.
• Environment. Most of the responsibility for the environment’s security sits with the service provider. If a vulnerability were exposed to the internet, enabling an attacker to gain unauthorised access to the information, this would be the service provider’s fault. Sometimes, the customer can adjust the environment’s security to enable or deny the use of a particular functionality or to connect other services up; where this is the case, the customer is accountable for these actions.

Cloud email is an example of Software as a Service (SaaS), and the shared responsibility model is similar across most SaaS services. With Platform as a Service (PaaS) where the customer can configure and develop their own application on the service provider’s platform (e.g. Salesforce) and Infrastructure as a Service (IaaS) where the customer can deploy their own virtual machines onto cloud infrastructure (e.g. AWS and Azure) progressively more responsibilities fall on the customer. The normal allocation of responsibilities can be seen in the diagram below:

The Risk still sits with you

Even though a shared service model allows the customer to outsource and delegate responsibility for the controls to their service provider, this doesn’t mean they have no responsibility at all. The customer still needs to conduct adequate due diligence into the service provider to satisfy themselves that the service provider will put adequate controls in place and can be trusted to maintain those controls to an effective level. While the contract may enable you to hold your service provider liable if they are negligent in their responsibility, the damage to your business will already have been done by that stage.

1. You should read Episode 2 if you haven’t already, where we talk about what assets are and how they may be at risk: https://digility.net/cs4nsp-episode-2-assets-risks/ ↩︎
2. See our article about the principles, disciplines and benefits of being Secure by Design: https://digility.net/secure_by_design/ ↩︎
3. A Penetration Test is a conducted by specialists who will attempt to identify vulnerabilities that could be exploited by malicious individuals. ↩︎
4. See Episode 3 for our description of Trust Personas: https://digility.net/cs4nsp-episode-3-people/ ↩︎
5. See Episode 4 for our description of Device Profiles: https://digility.net/cs4nsp-episode-4-devices/ ↩︎
6. A VPN or Virtual Private Network inserts a more secure and encrypted network channel within an existing network. When coupled with more robust methods of authenticating the users, such as unique certificates installed on a device, this can be used to add additional layers of security around sensitive systems. For instance, it can be used to protect administrator interfaces and prevent them from being directly exposed to the internet or some other less trusted network. ↩︎