Introduction

Like any design, the architecture may differ according to the business requirements. A financial services company requires tighter security control than a company handling less critical business solutions. Every company needs a top-class security model deployed on its network. No company is looking for second-class solutions, but you’ll often have a trade-off between cost and functionality. This forced you to choose a design that meets your company’s greatest needs. For instance, a landlocked country doesn’t need a heavy navy presence; instead, they focus their defense strategies on building a more dependable army and air force. You can always consider real-life examples when designing security models.

A wide range of complicated attacks threaten Internet-facing companies today. Most fend off such threats only due to sheer luck. Sometimes companies are not even aware that data theft happened at all. They become aware only when the hackers threaten to release the data if they don’t agree to their demands. You can argue that even cutting edge security models fail to protect some companies from being embarrassed in front of the world when they are exposed by hackers.

The Zero Trust model cannot completely prevent such attacks. Take into consideration Google’s way of designing systems. Google always designs with failure in mind. For their infrastructure system, their rule of thumb is that hardware can fail at any time. They create strategies based on how the system will react when there is a failure. The application will be grouped according to business criticality and they spend more money on monitoring critical applications.

You can model your security infrastructure based on business requirements. It is important to discuss this with various stakeholders before committing to any design approach. If you are passionate about cars and you wanted to buy a new one, you would naturally go for the best available car in the market. What you might not consider due to your passion are the budget, affordability, mileage, and many other things.

As a security consultant, it is always easier to suggest the top-selling and latest security tool available in the market. There is an old saying in IT groups that states, “Nobody gets fired for buying IBM”. There are many real examples where projects start with high expectations and, at the end, the budget skyrockets and the entire project wraps up before getting anything production-ready. This can happen when designing security systems as well if you are not careful.

As a security consultant, your job is to determine the requirements and priorities. You have to defend each extra penny the customer is paying. Setting up a cutting-edge defense system only to protect a blog or a less critical gaming application is not a good use of money or time.

This chapter focuses on how to design a general system based on the Zero Trust network.

It is important to understand the basic requirements and why you do things you’ll do in NSX. This information can be carried on to other areas.

Stakeholder Meetings

Application Architecture

Application architecture can be quite complex and demanding. At first, it might seem this has nothing to do with the security model and its implementation. The application architecture defines how code reacts to certain events and how the servers are organized at different levels. This gives you an important piece of information about the data flow.

In Zero Trust networks, it is vital to understand the packet flow inside the data center. Application dependency mapping documents are sometimes the most difficult thing to achieve in any infrastructure project. As it happens, each application owner is very confident about how their application works in their isolated system. They have factored in all the possibilities and edge cases to make sure all the possible issues are addressed. When it’s deployed to production, many are unaware of how the performance or changes in other applications impact their servers. You need to have a clear understanding of the business logic and application flow to segment these into firewall policies. There are different architecture models available in the market, several of which are discussed in the following sections.

Layered Architecture

Figure 5-1 shows one of the most commonly used web application architectures, the layered model. There is a two-tiered architecture and three-tiered architecture. The logic is separated into different layers and each layer has a particular purpose. The most common initial separation layer is the web tier, which ingests the user requests coming from the Internet. This is the only layer that is Internet-facing, and its responsibility is to cater to web requests.

As most of the user hits happen at this layer, the load balancing feature will have to be applied to this layer for extreme bandwidth scenarios. The web layer is mainly composed of the server, which has a stateless feature. This makes scaling webservers easy.

Next is the application tier, which contains the server that runs the business logic. Here, you take the user requests and run the logic and generate an expected result. As you see, this is one of the core components and has been designed and optimized for different scenarios.

The third layer is the database tier. You have already applied the logic to the user request, so the output might be doing a CRUD (Create, Read, Update, Delete operation) on a database that’s sitting in the database tier.

Layered architecture can be quite useful in the quick development of the software, as the responsibilities are divided across different tiers. But often there are drawbacks with this design. Over time, there is a chance that the codebase will end up as a monolithic design and becomes difficult to manage and upgrade. A tiered architecture, in some cases, can make it difficult for anyone to understand the overall architecture, thereby making the entire system more complex.

Layered Architecture Security Modeling Approach

While designing a layered application architecture (generally known as a three-tier model layer), isolation is important. The application is designed in a way such that each layer has a specific purpose, so the security design should also use this approach. This doesn’t mean you have to go back to a traditional perimeter model in order to deploy the solution. The flow from layer to layer should be properly identified and protected. The webserver should only connect to the application where it is serving the business logic, and all other flows should use DENY mode. In addition, the application that performs the CRUD operations on the database should be allowed to connect only to those specific ports. This will help in achieving real layer-based architecture in security modeling. As you can see, understanding the architecture helps you keep the application and security architecture in sync. This provides more scalable and more reliable security over time.

Managing and Monitoring Servers

Take great care with the placement and security of your management servers. All your infrastructure management servers should be well protected and restricted by LDAP user access. Allowing admin and default credential access is probably the most irresponsible thing anyone can do. In a setup where they don’t have well-defined processes and policies to commission hardware into, the data center will fall for this trap. Companies that are building new data centers usually end up missing some of these key points.

For instance, access to each computer or switch should be restricted only to a valid user. All these servers should be in another management network VLAN, but that is not a valid reason for allowing the default credential. The password-management policy should be followed across the hardware system.

I propose a jump server-based management setup. This simplifies applying all your firewall and access control to a single server or a group. The jump server can be properly deployed with tightened security controls and the latest patches applied and you can be 100% sure that there are no loopholes in it. Users with LDAP access log in to the jump server and, from there, they can navigate further to other servers for management purposes. Even then, only flows that are required should be allowed from these servers. A jump server shouldn’t has full control over the infrastructure. You can divide jump server access according to the organization’s division. The monitoring team that’s accessing the jump server shouldn’t have full control over the servers. Their job is to monitor and report any issues. Likewise, the security team, patching team, etc. should have required permissions only to do their roles. Figure 5-2 shows the access model view.

With the introduction of DevOps, IT teams often have a blend of development and operations skillsets. In such models, you need to take extra care when giving control over the infrastructure to diverse teams. In deployment models, like deploying servers using infrastructure as a code, it is excellent in simplifying manual processes. At the same time, this gives more responsibility to the person who executes it. A manual error or grave mistake can lead to disaster in these cases.

Application Grouping

This chapter discussed the major application design architecture. There are other varieties of architecture that can be used for system design, like microkernel architecture and space-based architecture. The point is that you need to have an initial understanding of the application architecture before you jump into the Zero Trust security model design.

Once you have the information you need and initial discussion with the stakeholders, you can move into the design of the Zero Trust security model.

It is advantageous to use a application-wise, horizontal approach instead of trying to take it all down as a whole. Start with a single application. Register all the servers in that application group. Once you have the list of servers, you are ready to start your work on the particular applications.

In the next steps, you need to determine how each application interacts with other blocks in the data center, such as with other applications, management servers, logging servers, and monitoring and audit servers. It is important to consider the management applications, as well. By design, you should not allow anyone or any groups to have free access to any part of the infrastructure they don’t need.

The T-Shirt Company Example

You have read about the prerequisites and general recommendations to follow before trying to deploy the Zero Trust networks. Now it’s time to delve more deeply into how all these pieces work together in a live production setup.

You have learned about security groups, services, service composers, DFW, third-party integrations, and other useful features. In a live production setup, these will act as an arsenal in the hands of a security consultant. Consultants have to use the right tools to get the right defense model per application. As discussed, there is no one size fits all approach in security. Even though you need to give equal importance to all applications, it is a fact that some applications are more critical than others.

This section uses a fictional T-shirt company to illustrate this process. It’s an online e-commerce store that sells T-shirts.

The first question is often, “why can’t we put everything into a public cloud?”. You could use AWS, Google Cloud, or Azure to achieve this. The question seems reasonable to a normal user, as the main advantage that public cloud vendors profess is that you don’t need to manage your infrastructure any more. This will be done automatically by the service providers.

If you learn one thing and only one thing from this book, it’s this—all the server, storage, application, databases, programming languages, and everything that is used to build an end-to-end web application must promote revenue to the funding company. No one uses a shiny new tool just because it is new and achieves some features that were not there before. The real question almost all CTOs will ask is how will it affect the bottom line. Can the company generate some percentage increase in revenue? Only if there is a financial benefit will most organizations go forward with expenditures.

The choice between a public cloud and an on-premise system depends on the business requirements and challenges. There is no one-size-fits-all solution.

Infrastructure for the T-Shirt Company

As portrayed in Figure 5-3, the T-Shirt company infrastructure is a scalable three-tier application. The application contains modules and services that do a specific job and help the overall system work seamlessly.

On an individual component point of view, each service can act and run independently. For example, the catalogue application runs in a separate virtual machine and uses a separate database (or the same database that’s shared across the application). The isolation you need purely depends on the applications.

As detailed in Figure 5-4, the user request flow looks like this:

1. 1.

   A user requests the IP to DNS server for www.tshirtcompany.com.

    
2. 2.

   The DNS responds with a public IP address of the load balancer, which is the entry point for the infrastructure.

    
3. 3.

   Once the user has the IP address, the browser will connect to the public IP address and will connect to the load balancer.

    
4. 4.

   The load balancer’s job is to redistribute the request to the backend servers according to their load.

    
5. 5.

   The request now hits the frontend webserver and the user will be welcomed with a web page with various options.

    
6. 6.

   The user can search through the catalogue and filter the products based on her interests. All the catalogue entries will be served by the Catalog application, which has a MySQL DB backend.

    
7. 7.

   Once the user has decided on the T-shirt to buy, she can add the product to the Cart application.

    
8. 8.

   After all the required products are added to the cart, the user has to proceed with ordering using the Order application. The Order application has a MongoDB backend.

    
9. 9.

   The Checkout includes different payments options that the user can use to place the order.

    
10. 10.

    Once the order is complete, it will be shown on the order application page. This will also confirm the status of the request.

     
11. 11.

    Separate applications can be used to track the shipping status and the successful completion of the request.

     
12. 12.

    This can be used in conjunction with a messaging queue, which can subscribe to any events about the order status and display them accordingly.

     
13. 13.

    The order is successfully shipped and marked as completed.

     
14. 14.

    The user will be able to see the ordered products in her account. This includes relevant details, like the address of the shipment, and so on.

     
15. 15.

    Options to create a new user, apply coupon codes, and so on, can be added to the design, as needed.

     

These points represent the request flow of an e-commerce application. According to the requirements, you can scale and add complexity to the application as you want. This job is up to the application developers and business owners as to how many features they need to attract new customers. In the modern e-commerce landscape, customers are looking for new and improved user experiences to keep them using the same website.

Say another competitor comes up with an amazing new product based on order history using AI and machine learning. Users might be tempted and gradually move toward other sites, as those competitors showed them products they have an affinity for. This simplifies their advertising costs and improves their margins.

The T-shirt company should be scalable and reliable enough to add such features with minimal effort. In a monolithic application, adding new features is a difficult task.

In this case study, the whole setup runs in a VMware SDDC setup. You are tasked to design the security model to protect these applications.

The T-shirt company purchased VMware NSX and a related toolset to better aid everyone involved in this project. The toolset includes the following:

• VMware vSphere license

• VMware NSX license

• VMware Log Insight

• VMware Network Insight

• TrendMicro/Panorama Checkpoint third-party product

License requirements and related information can easily be obtained from the VMware website. Refer to the VMware official website for information about licensing.

The coming sections analyze each application and the security rules required. You already read about creating rules and security groups. The focus here is on the type of rules that need to be created.

The setup here assumes that this is a greenfield deployment. That means that this is a new project and is not in production yet. Brownfield deployments are what you do on top of existing applications. Both have their challenges.

In a greenfield deployment, you are dealing with unknown facts. The setup is new and even the application developers might not be totally sure how their application behaves

In a brownfield deployment, you have an existing setup that you need to migrate. Activity will be done on a live production setup. You need to be sure about the DENY rules and packet flows. Migrating the existing firewall rules from a traditional firewall to NSX DFW is a challenge. You might need to rewrite the entire firewall rules in some cases.

This next step looks into the firewall rules that are required for the different services, such as those shown in Figure 5-5:

• Load balancer

• Frontend webservers

• Catalog application

• Order application

• User application

• Cart application

• Payment application

• Shipping application

• For MySQL databases

• For MongoDB databases

• RabbitMQ messaging queue

• Management and monitoring servers

Load Balancer

This is the first entry point for all the requests that hit the T-shirt company (TSC) infrastructure. The load balancer can be physical or virtual. NSX has built-in functionalities of a load balancer. There is an option to enable multiple load balancer types in VMware NSX. Inline and one-arm load balancer models can be deployed within an NSX setup without any additional hassle. This will always depend on the use case. As discussed, some infrastructure needs to be extremely scalable and have resource-intensive operations like SSL offloading or complex health checks of the server pools. These options are shown in Figure 5-6.

If the frontend application demands resource-intensive operations, physical appliance-based load balancers like Citrix Netscaler or F5 have to be used. This resolves one problem, but you need to keep in mind that managing and maintaining these physical appliances is outside the scope of the NSX and you’ll need to individually take care of these appliances. There are separate command sets and management tools for administering the load balancer.

For an end-to-end infrastructure automation, this might come as a roadblock. In an immutable infrastructure setup, the infrastructure automation tool should be capable of deploying the entire infrastructure stack using the scripted methods. In the case of the appliance, it won’t be able to take part in the automation process.

All these points need to be kept in mind when you select your load balancing tools. The virtual appliance of popular load balancers can also provide most of the feature sets available in physical load balancers. Figure 5-7 shows the backend.

The load balancer has to forward the request using an algorithm that’s best suited to the application. You can even use a round-robin algorithm where each request is forwarded in a round-robin fashion to the backend pool of servers. There would be a health check script, which can be based on a specific port or ICMP or HTTP request. The purpose is to identify whether the backend pool of servers is available and healthy to forward packets for further processing.

If the load balancer sits outside of NSX, the firewall rules have to be configured in the customer’s firewall. In this case, you can configure the rule in the edge device, as the packets to a particular transport zone must enter through the edge appliances.

The idea is to drop the packet as early as you can, before allowing it to enter into the DC.

Edge Firewall Rules

The rules you define in the edge firewall (see Figure 5-8) will be matched against the packets that enter the NSX. Any other malformed packets will be discarded at this stage.

Here are the required steps:

1. 1)

   Rule moves from the load balancer to the backend pools.

    
2. 2)

   Define the ports on which the frontend webservers will be listening.

    
3. 3)

   Create a service for those ports.

    
4. 4)

   Apply the rule in the edge firewall.

    
5. 5)

   There is a default DENY at the end, so any traffic that is not destined for the frontend servers will be dropped.

    

This example has only considered the production web frontend servers. If there are other physical servers or monitoring servers outside the VMware NSX environment, they have to be included in the rule. Otherwise, the flow will be blocked by default.

Frontend Webserver Pool

Webservers sitting at the frontend are often the most targeted servers. To access the application, you have to first get inside and then spread through the system. Webservers are often placed in the demilitarized zone with high levels of security. A hacker might target these webservers in order to deface the website, thereby causing the company international embarrassment. There may not be any intention to crash or steal assets, but as you know, negative news can be just as harmful. If the incident is faced by a financial company, this can be a big hit to their trust factor.

In most cases, you only have to focus on the ingress and egress flow for the webserver pool. Frontend servers have to be extremely scalable by design. When the load increases, the stateless nature of the application should aid in creating multiple webserver copies according to the incoming request bandwidth. Security should scale along with this. Autoscaling is the most used word nowadays for distributed system designs.

If you are enabling this kind of feature in your webserver design, be sure to enable it on the security modeling too. For instance, if you have to create an additional five webservers to feed bandwidth demands, make sure all the servers are automatically included in the webserver security groups, so that the polices are applied to the respective vNICs.

In doing so, you ensure that the security standards and policies are met. Figure 5-9 shows the frontend flow.

You can apply the same process to a distributed firewall.

These are also micro-segmentation/Zero Trust policy rules.

Figure 5-10 shows the frontend rules.

Once a rule is published on all the hosts, the vNIC will start filtering packets based on the ruleset.

Catalog Application Server

Catalog application servers are responsible for listing inventory from the MySQL database in the backend. All inventory should be logged in to the database.

Inventory can be broken down into multiple sections. For example:

• New items

• T-shirts on discount

• Regular polo T-shirts

This can be designed and pushed into the schema of the database table. Because the webserver to application and then to database connectivity is a generic three-tier architecture, you need to understand which other applications need to access the catalog. The users need to log in and connect to the Catalog server to access the products. From the shipping agent’s point of view, they need to be able to update the inventory and mark the product as out of stock when this is the case.

This applications have to talk to each other to keep others updated. As mentioned, the catalog has to be updated based on availability and quantity. If this synchronization process is not happening seamlessly, the whole system is going to break down sooner or later. Figure 5-11 shows the catalog flow.

The same rules can be deployed in DFW as micro-segmentation/Zero Trust policy rules.

Figure 5-12 shows the catalog server rules.

The catalog server has direct connectivity to the database that stores all the inventory details. This can be treated as one of the critical connections points. Even with Zero Trust policy rules, all the required handling has to be done on a database level to ensure that there are no other vulnerable ports exposed in the system that can be accessed through the Catalog application.

Cart Application Server

Once the user determines which product she wants to buy, she usually adds the item to the cart. Users can add multiple items to their carts. Users then check out once they are finished shopping.

This means the cart needs to be stored somewhere. You can use a MongoDB database for this purpose. MongoDB is a document store database that has its own advantages compared to MySQL. You can use MySQL for the purpose as well.

There are multiple checkpoints to consider before adding the request to the cart. The system must first check the inventory/catalog for the availability of the stock. Then it determines how long it will take the product to reach the user. This means there is a bidirectional connection between the cart and the catalog applications. You can add other features, like a cart expiry, to the system. Since they don’t impact the security model discussed here, this section skips those details. Figure 5-13 shows the cart application’s server connectivity flows.

These are also micro-segmentation/Zero Trust policy rules.

Figure 5-14 shows the cart application’s server DFW rules.

User Application Server

Once the user decides to check out, she has to verify the details before starting the order process. Users have to be registered at the site. If they are not logged in yet, they have to log in and access the cart. Users also have to update their address information if necessary. The user application server can save the user details on the MongoDB backend.

As discussed, there are many advanced features you can enable on a per user basis. You can even apply a discount for loyal users who place regular orders. You can encourage new users to visit regularly. All this will fall under the application design. From a security perspective, identifying the user credentials is important. All relevant measures have to be taken to ensure the database is hardened enough.

If the user is not registered, she has to be redirected to a registration page to enter the details.

Figure 5-15 shows the user application’s server connectivity flows.

These are also micro-segmentation/Zero Trust policy rules.

Figure 5-16 shows the user application’s DFW rules.

Order Application Server

The next step is to place the order. Necessary application checks have to be performed as well. This is also a business-critical application. A user who casually browses the catalog may not buy something every time. But when a user decides to check out, she is going to place an order. The IT infrastructure has to be flawless and completely secure during this operation. This is an area where the company is getting revenue and the employees are getting paid. This process has to be secure and perfect.

The longer the user has to wait before ordering a product, the more she is going to be frustrated. No business wants to lose a purchase at this point.

All the order information will be again saved in a MongoDB database.

Figure 5-17 shows the order application’s server connectivity flows.

These are also micro-segmentation/Zero Trust policy rules.

Figure 5-18 shows the order application’s server DFW rules.

Payment Application Server

The payment application usually forwards the request to the third-party banking interfaces. If the payment application saves the credit card details, there have to be enough security and encryption methods so that the user data is secure. There have been cases where user information (such as credit details) was stolen from websites. If you are going to save the data, make sure you have strict methods in place to secure it. The purpose of the payment application is to interact with the banking interface, do the transaction, and update the response.

The response of the banking interfaces are not in your control, but the necessary rules and ports need to be opened for this transaction to happen.

This section doesn’t list all the details required for payment applications. Only general connectivity flows are listed, as shown in Figure 5-19.

These are also micro-segmentation/Zero Trust policy rules.

Figure 5-20 shows the payment server’s DFW rules.

Shipping Application

Once the order has been placed, the request has to be updated to the shipping application. It is the responsibility of the shipping application to keep track of the request updates. For this, you can use a messaging queue system as an asynchronous communication system for updates (see Figure 5-21).

A messaging queue is a system used in a distributed system for asynchronous communication. In this example, the application will be subscribed to a particular queue for any changes. If there are changes published to the queue by any connected application, they will be updated to all the subscribers. Figure 5-22 shows the shipping application’s server connectivity flows.

These are also micro-segmentation/Zero Trust policy rules.

Figure 5-23 shows the shipping application’s DFW rules.

Database and O&M Servers

Operations and management server connectivity can be complicated. Port connectivity has to be application-specific. It might seem that allowing full access to management systems would be a great idea. This would most likely create a big loophole in your Zero Trust system. Hackers are normally looking for a management server to get easy access to your system, so this particular loophole could be dangerous and could act as a single point of failure.

Make security groups specific to management and monitoring servers and apply only required rules.

You have learned about each component and its respective flows. This sets you up for the requirements to designing better security solutions.

All servers can be added to the nested security groups. Another rule can be created for the traffic to management and monitoring servers (see Figures 5-24 and 5-25).

Understanding the Current Architecture

One key point to mention is to make sure that all the relevant documentation is available and up to date before you even think about starting or changing things. Changing some part of the setup and trying to go back, only to find that there were no references or documentation on how you did it before is a disaster. So up to date documentation is the key.

Before tearing down the design, try to understand which part of the application works well and what advantages you’re getting from this compared to a traditional perimeter appliance-based design. The performance of the hardware appliance would be great if you were using a separate physical server. They are firewall vendors with their own proprietary feature set, which can helpful in solving problems. This may not be available in NSX, but knowing what you don’t have is as important as understanding what you do have. You are not looking to replace feature to feature. Identify the weaknesses in the design. When you have a comprehensive understanding of the strengths and weaknesses, you are in a good place to start planning.

An AS-IS and TO-BE detailing will always be helpful at the beginning of the project. Even SWOT analysis of the two methods will give you a fair idea of where you stand and where you are going to end up. This helps you convey a clear idea of what to expect, even to non-technical managers.

You could be bombarded with a lot of marketing terms and end up believing that the tool can do almost everything. In that case, you will end up being disappointed, even when the newly deployed stack is a considerable improvement in the design. Avoid such pitfalls by including all the stakeholders and ensuring that they understand what they are going to get at the end.

Be sure you back up the current configurations and the export options available in the firewall appliance. VMware NSX has very little support for the import feature from another firewall appliances. This ruleset, imported in a familiar format, will help create the distributed firewall rules.

Register the current requirements of auditing and logging. The same has to be implemented in a new setup, as the requirements for security audits are generic across the industry.

The latter part of the project can follow the greenfield system to design and model the security architecture based on Zero Trust networks.

How Zero Trust Helps: An Example

This section covers different kinds of attacks that can happen to any Internet company. There are distributed denial of service attacks happening daily all over the world. To coordinate such attacks, hackers typically take control of the network’s infrastructure. Hackers sometimes get into the IoT network and use the IoT sensors to launch an attack.

They then illegally use your network. If a botnet was installed on your network and you were not aware, it can be used against any other Internet companies to launch a botnet attack. It is always crucial to have a defense mechanism against these common attack types.

Consider Figure 5-26. You can even take the example of the T-shirt company’s infrastructure.

Without Zero Trust

Without Zero Trust, there is no block of the lateral movement between the machines. Once a server/workstation is affected, the virus/ransomware can easily spread throughout the network (see Figure 5-27).

Because the network is not segmented, the attacker can easily access across the network, unless he hits a firewall policy (see Figure 5-28).

Gradually, the malware looks for any kind of shared service or credential that can be used to hop into another server/workstation and launch attacks. This continues until it meets a definite policy that prevents this. In a network that has no segmentation, this type of attack can cause widespread destruction.

As you saw in the T-shirt company application, you deploy the firewall policies on all the vNICs. If the network is affected by malware, the spread is controlled. The DFW will filter out this traffic as unwanted and illegal and will drop the vNIC itself, as shown in Figure 5-29.

Summary

This chapter explained the core ideas of building a Zero Trust network. This idea can be reviewed further according to your project requirements and implemented across the VMware environment. The benefit you get from this design is very noticeable, as you have more control over your network. The next chapter discusses the tools that can aid you with this process. It covers the REST API and the automation options available with the NSX.