Top 5 Security Concerns Solved by Zero Trust
Zero trust (ZT) represents a clear pivot in how to think about a cloud security defense. Rather than defending a single, enterprise-wide perimeter, the zero trust approach moves this perimeter to every network, system, user, and device within and outside the organization.
A common analogy used to describe zero trust is that of providing security for a physical building. A security guard sitting at the front desk reception area of the building is the equivalent of a traditional, static, network-based perimeter. In zero trust, not only is there a security guard sitting at the front desk reception area, but one is also stationed at each elevator, each stairwell, and each office doorway on each floor ‘checking your badge,’ so to speak.
Zero Trust teaches us to never trust, always verify, or always check that badge. With that in mind, let’s take a dive into five of the top areas of concern, and how you can secure your enterprise by applying the principles of zero trust.
Concern #1: Network Breach
Zero Trust assumes every request is a potential breach, and every request must be verified as though it originates from an open network. If you assume a network breach, you can minimize the blast radius that is, the impact and severity of a breach, and in turn, reduce the time and cost necessary to respond and clean up the violations. Consider applying the following concepts:
Segmentation is dividing a computer network into subsystems — or segments — to control how traffic flows across the network. For example, you could split up web servers, databases servers and standard user machines each into their own segment. By creating network segments containing only the resources specific to authorized users only, you create an environment of least privilege. Segmentation projects can be tricky. A successful segmentation plan has a few necessary and separate subsections —too many can be overcomplicating, and too few can allow your system’s security to be threatened.
Network Security Groups (NSGs) are one type of segmentation, containing security rules that allow or deny inbound network traffic to, or outbound network traffic from, different types of resources. For each rule, you can specify source and destination, port, and protocol. For a more in-depth discussion, check the Azure documentation here.
Firewalls sit between a trusted network and an untrusted network, such as the internet. Azure Firewall is a cloud-based security service that protects your Azure virtual network resources from incoming and outgoing threats, ensuring that all traffic to and from the internet is denied by default. Traffic is only allowed if it passes various tests, such as the configured firewall rules.
Setting firewall policies is a complicated business. To further complicate it, Azure Firewalls come in standard and premium versions, the standard version providing a subset of functionality. You can read more about Azure firewalls and licensing here.
In zero trust, we hear a lot about endpoints. While not a new concept, the idea of endpoint security has become a critical component of a ZTA. An endpoint is simply the device used to connect to a business network. It represents one of the most common security risks given the sheer number of devices being used to connect to networks since remote work has become more common.
By making endpoints the new network perimeter, organizations can prevent risks and detect suspicious activity no matter where employees are. It only makes sense, then to expand security to include all enterprise assets (devices, infrastructure components, applications, virtual and cloud components) and subjects (end users, applications and other nonhuman entities that request information from resources).
Tools, such as Microsoft Endpoint Manager, can ensure all devices and their installed apps meet your security and compliance policy requirements, regardless of whether the device is owned by your organization or by the user. This protection applies no matter where the device may be connecting from — whether it’s inside the network perimeter, over a VPN, on a home network, or the public internet.
Once discovered by the tool, unmanaged endpoint and network devices can be onboarded to Defender for Endpoint. Then, assessments can be run using Defender for Endpoint’s threat and vulnerability management capabilities, and the output can be used to address issues and reduce an organization’s threat and risk exposure.
Microsoft just announced that Microsoft Defender for Endpoint has extended its configuration management capabilities. Along with Microsoft Endpoint Manager, security management is integrated in a single, dedicated console for unified endpoint security management.
Concern #2: Account or Identity Compromise
Anomalous changes in user access can be a sign that an external party, such as a hacker, is trying to gain access to your network using a user’s credentials. Behaviors you may notice include accessing accounts at odd hours, multiple failed login attempts, and discrepancies between a user and a particular device. A Zero Trust architecture (ZTA) uses policies and real-time signals to determine when to allow access, block access, or require additional proofs like multi-factor authentication (MFA).
Identities are at the core of a ZTA, where only the people, devices and processes that have been granted access to resources can access them. You need to know:
- Who your users are
- What applications they need to access
- Why they need access
- How they routinely connect to those applications
- What controls can be used to secure that access
In the following diagram, all security starts at the base point in a ZTA — identities — and follows through verification, policy enforcement, and segmentation to ensure safety.
Conditional Access policies assess risk levels, for example, a user’s session risk upon login. Based on the risk level associated with a user session, you can enforce in-session controls, that determine which actions a user can carry out, and which may be limited or blocked entirely, as well as how long the session may be active.
You can also use built-in role-based access control (RBAC) in Azure Active Directory to assign permissions to users, groups, and applications at a certain scope, making sure only required access is enabled for the appropriate user. Using RBAC, for example, you can limit the access of users and groups by assigning them roles on Azure resources. Azure role-based access control comes with different built-in roles: “owner,” “reader” and “contributor,” that can be assigned to users, groups, and services. It’s easier to first create and assign access to the “subscription level” and adjust at the resource level.
Multi-factor authentication (MFA) involves the use of two or more factors in authorizing access to secure data, forcing people to use more than one device to confirm their identity. An example of MFA in action is having a one-time passcode sent to two or more devices. No matter what network the request is coming from, you are ‘checking their badge,’ and sometimes twice.
With Azure Active Directory, you can manage and protect identities across infrastructure and apps, and hybrid environments. If you don’t integrate your on-premises and cloud identities, you’ll have more overhead in managing accounts. This overhead increases the likelihood of mistakes and security breaches.
Concern #3: Data Loss through Exfiltration
Data loss prevention (DLP) is a set of technologies that performs both content inspection and analysis as of data as it traverses the network, is in use on a managed endpoint device, or is at rest on a file server. A DLP policy defines how organizations can share and protect that data. It also guides how data can be used in decision making without it being exposed to anyone who shouldn’t have access to it.
Encrypting data at rest is a mandatory step toward data privacy, compliance, and data sovereignty in a zero trust-based security platform. You should also encrypt the data as it moves between the client and storage. In Azure, the first recommendation is to always use the HTTPS protocol, which ensures secure communication over the public Internet. You can enforce the use of HTTPS when calling the REST APIs to access objects in storage accounts by enabling Secure transfer required for the storage account. Connections using HTTP will be refused once this is enabled.
Integrating with Azure Information Protection can be used to automatically set classification labels and optionally, to add encryption protection. Once the integration is turned on, you can apply governance labels, view, and investigate files by classification, and create granular policies to ensure files are being handled properly. If you don’t turn on the integration, you can’t benefit from the ability to automatically scan, label, and encrypt files in the cloud. For more information, see Get started with data discovery and classification.
Concern #4: Resources exposed to the Internet
Securing your internet-exposed services requires applying a combination of controls – patching, network segmentation, multi-factor authentication, and logging. This effort should include servers you manage on infrastructure-as-a-service (IaaS) providers and platform-as-a-service (PaaS) assets such as databases or object storage. It’s important to remember that Azure firewalls, as we discussed above, will be critical to this process.
First, conduct an inventory and ask the following questions:
- Is this service or resource still required?
- If so, does we need this service to be internet-accessible?
- If so, does it need to be completely exposed to all sources on the internet or can it be restricted by IP?
It will be important to answer these questions in the context of the access and data they expose. For example, if your organization exposes database servers to the internet, this can present a serious risk to the information in those databases, and to your organization. It would be better to restrict access to this server via a VPN rather than giving it a public IP address.
Scan the public IP addresses to confirm which ports are open, what services are running, and what protocols are supported. There are many network scanning tools that can help with this. Microsoft Defender for SQL extends the protections for your Azure-native SQL servers to fully support hybrid environments. It protects Azure SQL Databases, Azure SQL Managed instances, and dedicated SQL pools in Azure Synapse, as well as other cloud environments, and on-premises machines.
Azure also allows you to use private IP addresses within the Azure infrastructure, where you can leverage private endpoints. A private endpoint is a network interface that uses a private IP address from your virtual network. This network interface connects you privately and securely to a service powered by Azure Private Link. You can read more about private links in our recent blog post here.
Concern #5: Virtual Machine Attacks
Attacks on virtual machines from the internet are one area where customer tenants have a shared responsibility with their cloud infrastructure provider. That responsibility extends to every virtual machine, ensuring you apply the right security controls.
As with all cloud security prevention techniques, your goal should be to reduce the attack surface. In this case, that means having fewer open ports, especially management ports. But if your legitimate users also use these ports, it’s not practical to keep them closed. To solve this dilemma, Defender for Cloud (formerly the Azure Security Center) helps by offering Just-in-time (JIT) access. With JIT, you can lock down the inbound traffic to your VMs, reducing exposure to attacks while providing easy access to connect to VMs when needed through RDP.
Note: Azure Security Center and Azure Defender are now called Microsoft Defender for Cloud. To stay on top of the ever-changing product name game, you can read more here.
Defender continuously assesses the security state of your cloud resources across virtual machines, networks, applications, data services and even monitors server workloads running in other clouds and on-premises datacenters. Defender has a single dashboard that surfaces alerts and recommendations that can be acted upon immediately. Often, you can remediate issues with a single click within the Defender for Cloud console.
The most important consideration with infrastructure is around configuration management and software updates, so that all deployed infrastructure meets security and policy requirements. Here again, Defender along with Log Analytics helps with configuration and software update management for your on-premises, cross-cloud, and cross-platform infrastructure.
Microsoft recently updated its security guidance for IaaS workloads in Azure here. It’s a great resource for security best practices as well as the detail behind how to implement them.
To implement some or all the best practices we’ve discussed above, your IT team doesn’t have to turn into reluctant systems integrators. Instead, Microsoft Azure has all the tools in one box, natively integrated by design. It’s simply not practical or cost-effective to deploy many disparate security solutions, especially for cloud applications.
Most organizations already have some elements of zero trust in their enterprise infrastructure. If that describes your organization, remember that it’s equally important to continually assess your security state, as cloud workloads change dynamically.
If you’re just starting out, the first step to building a zero-trust network is mapping your requirements; everyone’s processes and needs are different. For example, some companies may have internet-based resources and workloads that cross multiple trust zones, and some won’t.
Zero trust is not a solution you can buy off the shelf. It’s an architecture, a state of mind, and a combination of capabilities. Hitachi Solutions is uniquely poised to aid you in your zero trust journey. Our Azure certified experts will work tirelessly alongside you to ensure your security and success.