During the past couple of years, your organization has probably devoted significant resources (including cash) on upgrading cybersecurity tools, infrastructure and sending staff to vendor training on their products. Your deployments are finally complete, you have new firewalls and proxy gateways, EDR to supplement anti-virus, and DLP to protect against data exfiltration. Now you’re safe and can sit back and relax, right? Think again.
Why? The old Trust but Verify concept is obsolete.
Operating safely in our current threat environment requires something better: Zero Trust (verify before trust is another way to put it). No matter what term you use, it’s important to remember that Zero Trust is a concept – not a product. You probably already have all the hardware and software solutions you need to implement a Zero Trust environment. You simply need to design and architect the proper configuration to achieve it. Okay, “simply” may be an exaggeration. You do need to take some time for this architectural design, coordinate resources and roll out your Zero Trust solution to minimize impact on the enterprise. But trust me, all the proactive effort is worth it.
There are multiple categories where you should verify before trusting. I’m going to take my discussion in a slightly different direction from my colleague, Joseph Karas’ blog.
I’ll focus primarily on networks, although there may be a bit of overlap with other categories. Let’s look at a simplified fictitious example – an enterprise in a single multi-story office building, with physical routers or vLANs, each floor has at least one unique subnet.
|7||Product Engineering and Development|
|6||Sales and Marketing|
|5||Finance: AR, AP|
|4||IT: Data Center, Operations|
|3||IT: Desktop Support and Incident Response|
|1||Building Maintenance, Mailroom|
I bet you’re asking yourself, “What does this have to do with Zero Trust?”
Remember, Zero Trust is a concept. I’ll show you how proper network access configuration supports a Zero Trust objective. You will still need to coordinate Zero Trust efforts with other categories, but you’ll be surprised how much secure your environment will become when you apply some of the following methods.
Should you be concerned about someone in HR mapping a drive to a desktop in finance? You already have security in place with authenticated domain users, so non-domain users can’t make this connection. Now ask yourself, “how does ransomware encrypt data across an entire enterprise?”
One helpful technique is to narrow down the choices of domain users (and domain computers) allowed to map drives to other workstations. To do this, you can configure vLANs and/or routers to block the Microsoft File Sharing Server Message Bloc (SMB) protocols coming from all floors except the third floor (Desktop Support and Incident Response) when you have a business requirement to do so. That way, if someone in the mail room on the first floor clicks the wrong button and becomes infected with ransomware, they can’t encrypt shares on any other floor’s workstations. This move will reduce your ransomware attack surface by over 85%. Instead of all eight floors, now only one floor has inbound access. Trusting inbound workstation connections only to the third floor is Zero Trust in action for the other floors. This enables other Zero Trust categories to efficiently focus on performing verification on third-floor resources before trusting their connections.
Should you be concerned if someone in marketing makes a Remote Desktop (RDP) session connection to a workstation in finance? What possible business use case would justify that? Ask yourself how malicious attacks take place, and you’ll realize that this RDP session could be the tool of a pivot. A way for an attacker to jump from machine to machine looking for high-value targets and an opportunity for privilege escalation. To prevent this, as with blocking local file sharing, you can add a vLAN or router rule to block the RDP port 3389 inbound from all floors except the third floor, where desktop support and/or incident response has an actual business use case requirement for this connection. By doing so, you reduce the ability of a malicious attacker to pivot by over 85%.
For the data center, you can establish different vLANs for different access requirements. Web servers, email servers, SQL database servers, and other client-server resources don’t have requirements for inbound file sharing (SMB) connections by any workstations beyond operations and incident response vLANs. So you can configure their vLANs to block SMB from everywhere else. You can put your VDI/SaaS servers on their own vLAN, since they require all inbound RDP sessions. But you should configure this segment to block all inbound RDP connections except from operations and incident response vLANs. With this tactic, you will further reduce attack surface for your data center resources.
This is a good strategy (it’s sometimes called network segmentation), but I’m sure you can see that the strategy has gaps. What if a single workstation in customer support gets infected by ransomware? This strategy will only protect resources on other floors. All other customer support workstations are still vulnerable targets. Or are they?
Most desktop security solutions include an Operating System (OS) firewall. Most organizations create a strict OS firewall rule to prevent inbound connections while on public internet connection or public Wi-Fi access point. For convenience, they configure the OS firewall to allow all traffic when on the internal enterprise network. But no convenience comes without a cost. Maybe we should take advantage of the OS firewall to further reduce our attack surface.
Let’s take the network segmentation paradigm and deploy it further down to the workstations’ OS firewall, especially on the internal enterprise network. You can create OS firewall rules to block inbound SMB and RDP connections except those from desktop support and incident response subnets. So, if one workstation in customer support becomes infected with ransomware, the damage will be contained, and the remaining workstations on the floor remain operational. If a malicious attacker compromises that workstation, pivoting to further attack is prevented. Yes, we have again greatly reduced the attack surface.
While we’re configuring the OS firewall to improve security, let’s consider DNS, the Domain Name System. These are resources that translate a named resource (i.e., www.website.com) to the TCP/IP address (i.e., 10.20.30.44) required by the OS to identify and connect to network resources. Your enterprise has its own DNS servers in the data center to translate internal enterprise resources, and they forward requests for translating unknown external resources to specified (authorized) public DNS servers. That sounds like no internal desktop OS should ever communicate with a DNS server other than official enterprise DNS servers, right? So let’s add another rule to the OS firewall to block all outbound DNS traffic unless it’s going to an enterprise DNS server. This can prevent DNS hijack attacks in which valid resources are redirected to a malicious resource, possibly to infect workstations or steal credentials. In some cases, malware will attempt to utilize DNS traffic to exfiltrate unseen data. An OS firewall rule to block all DNS traffic except for specified enterprise DNS servers puts Zero Trust in unauthorized DNS traffic. So without spending any money on additional software or hardware resources, and requiring only testing, piloting, and implementing in the enterprise, we’ve reduced the enterprise attack surface. Haven’t we?
I recommend looking for all IT resources and functions that are intended to provide convenience to your workforce. Remember, no convenience comes without cost. Many times that cost is a compromised security posture.
If your enterprise is breached or compromised, you will quickly learn that “there’s no such thing as bad publicity” is a falsehood. I challenge you to investigate applying Zero Trust to secure your environment. You might engage with a cybersecurity consultant to help analyze your environment for the best architectural design and possibly help with implementation as well.
Zero Trust has replaced Trust but Verify as a higher security concept. So my professional advice is that you should seriously start thinking Zero Trust instead of Trust but Verify. The move will be well worth it, as it will further reduce your attack surface and improve your security posture.
About Enterprise Studio
Enterprise Studio by HCL Technologies helps organizations make the connections between IT and business that optimize time and multiply value for realizing the full potential of their digital business plans. Our seasoned technologists, coaches, and educators can help you unlock value from existing IT investments to become a stronger, more adaptive organization – in part by leveraging a BizOps approach so that IT outputs are strongly linked to business outcomes.
Whether you’re an established Global 500 company or a new disruptive force in your industry, we can help you navigate complexities that come with competing in an inter-connected digital era. We are a global solution provider and Tier 1 global value-added reseller of Broadcom CA Technologies and Symantec enterprise software.
Many of our experts at Enterprise Studio are from the former professional services units of CA Technologies and Symantec. For decades, our teams have supported and led organizations to innovation with powerful enterprise software solutions and cutting-edge methodologies – from business and agile management to security, DevOps, AIOps, and automation.