3. Where is the perimeter?
Career stage: This was my first role with the title of Architect, more specifically I was an Infrastructure Architect. In the early 2010's, the main talk in infrastructure was this new thing called?"Cloud Computing", and every company wanted to know how to take advantage of it, or if it would be too risky to adopt. Running your own physical data centers comes with a high degree of complexity and cost, but also allows you to maintain full control of each aspect, compared to the cloud infrastructure offerings that had limited choice on how much you could modify them.
?
Challenge: I joined a team of architects as they were in the middle of multiple projects across their sites in both the UK and USA. Cost reduction was a critical subject, but so too was the need for the business to embrace Digital Modernization, another movement happening at the same time as this new Cloud Computing.
One of my first tasks was to take inventory of all the servers, networks, and data centers the company had. Due to a series of company acquisitions, new projects, and natural business expansions, there wasn't a single count or view of everything that was readily available. I worked across several teams, including the dedicated security team, and eventually counted a total of 7,500 servers (across physical and virtual machines). This came as a bit of a shock to my manager, he thought there were only 5,500 at most. I double checked all the details, it was 7,500.
My new friends in the security team were keen to help understand where these extra servers might be, what they were used for, and find any potential risks in the way they had been set up. The first step I took was to identify those that were business critical and should be provided the highest protection, then categorize them based on their business criticality, potential blast radius, and risk scoring.
One of the key diagrams I remember drawing on a whiteboard was the idea of segmenting between the layers of trusted zones, networks, application types, and level of trusted access. It looked a bit like this to start with:
Each of these zones was added to the spreadsheet that listed all 7,500 servers, and soon we had a better idea of server functions and areas of risk based on each zone (1-4). Today, this would be the beginning of your Zero-Trust planning, but that term wasn't common knowledge at this time, so we had to make up our own approach.
After we assessed the servers, firewall rules, and admin accounts used on these servers, we built up a better picture of the risks to each one. We noted if the servers had remote desktop capabilities enabled (RDP), if they were being accessed remotely by a 3rd party vendor (supply chain risk), and if they were directly exposed to the internet, or had to be accessed via a virtual private network (VPN). The result looked like this next diagram, only much more complicated:
The security team now had a much clearer scope of work and a way to prioritize their investigations and remediations, especially as many of these servers had some kind of internet access that wasn't fully controlled and could allow an attacker to again entry into the most critical business systems and sensitive data.
?Other labels may have included:
领英推荐
Today I would also have added which servers were using passwords for access, and those which have modern authentication protocols in place instead. Eradication of passwords, shared use accounts, and overly permissioned access grants, is critical to any modern security plan. Today, over 98% of cyber-attacks would fail if the attacker couldn't get to the credentials they need.
As the conversations switched to assessing the potential of Cloud Computing, we had to consider the change in perimeter. No longer would all our compute capabilities, network controls, and data storage, be run inside of our own data centers. Instead, we would need to decide what could move to the cloud, and how it would be secured. A new diagram was needed, and it looked like this:
With this image we could start to have conversations about how our users gain access to applications that are either hosted in our own datacenters or were moved to operate in the new cloud infrastructure. This kind of diagram is still useful 10+ years later as companies have to continue to work out when they should use the cloud and when they should deploy locally (known as Cloud Edge Computing). These decisions are partly due to security, but also because of network latency, systems redundancy, and data security or sovereignty.
?After several conversations between the engineers and architects across networks, datacenter, and security, the following diagram was created to help communicate some of the key decisions to business decision makers that were less technical but had to have full understanding of options and risks associated.
We can also see that any remote working user that needs to gain access to sensitive business information will first come to the corporate datacenter via a secured VPN connection. This ensures all remote access is funneled through tight security controls before they can gain access to back-end systems. This is also critical for the early adoption of cloud services as it prevents anyone being able to directly gain administrative control of the cloud infrastructure without first being authenticated and authorized by the corporate security controls.
This is just one of many ways to architect hybrid-cloud connectivity, and it likely changed over time as new architectures, security controls, and best practices were updated. Having an image like this, that accurately represents the current state, enables cross-disciplined teams and experts to have complex conversations whilst maintaining a shared understanding of the issues and the options available.
??
What I Learnt: Stepping into the role of Architect put me in a new position to have to answer questions I may not have considered before. When you view a single problem, like Active Directory design and implementation, you may not have the full view of all moving parts. As an Architect, you not only have to consider other design components but also the business decisions and risks associated with them.
For this company, it was a great time to begin a zero-trust approach to network security. For too long external access had been set-and-forget. It was a good challenge to coordinate multiple designs and review assumptions, then tighten up the controls before the attackers could take advantage.
Join me next time as we look at how to solve some complex server issues in "Need a tune up?".
Richard Diver Another great write up. This is especially good for folks who want to work in this field. Your getting an excellent insider’s view!