HomeBlogGuidesbooksNetwork SecurityDesigning your Cyber Security Infrastructure: A Quick Guide | EP — 3 Secure Network Architecture.

Designing your Cyber Security Infrastructure: A Quick Guide | EP — 3 Secure Network Architecture.

This is Episode 3 of the series where we guide businesses on designing a secure IT Infrastructure. In this episode, I will discuss the challenge of designing a Secure Network Architecture. I have also provided resources to download a template to create your own IT Security Policy.

Network security design and network architecture have often been pushed to a secondary role as organizations invest in technology to solve their security concerns and migration to the cloud and the addition of countless IoT gadgets complicate matters. Network security architecture leverages the organization’s resources while network security design implements the concepts. Well-planned and constructed network security design is critical to minimizing the gaps in the infrastructure often targeted by attackers and essential to controlling access to necessary data within the organization.

Optimizing the network security design for organizations that are adding systems and other technology, housing sensitive data, and adding new points of access for their customers, employees and contractors has added new elements of risk and additional pieces to the IT security puzzle.

Laying the Groundwork —Understanding Your Requirement

Designing a secure infrastructure is like designing a secure office building.

You can hire the best team to build it, but if you don’t know your business practices and the level of security you require, it’s going to leave gaps. These gaps then turn into breaches that could’ve been avoided in the first place.

When designing a network, the process must start with planning; that is, understanding the data that you are trying to protect, on which systems that data is stored, the business impact if the data is compromised and of course the budget that you may have allocated for the project.

In addition, the legacy network, traffic and user population are variables that need to be included as the planning phase concludes with the delivery of (1) Cost (2) Schedule and (3) Performance requirements. The blueprint for the design must include sound design principles as well as planning requirements to build a secure, cost-efficient solution.

t is important to ask these types of questions to understand the network and define the security requirements.

High-Value Systems and Assets

The task of identifying high-value systems and assets is easily the least glamorous aspect of secure network design. However, without going through the process of pinpointing those systems and assets, their locations and value, how are you going to decide the amount of time, effort and budgetary spend that you should allocate to securing your network?

High-Value Systems & Assets can broadly be classified into the following categories:

Information assets

Every piece of information about your business falls into this category. This information has been collected, classified, organized and stored in various forms.

  • Databases: Contains information critical to your business.
  • Data files: Information stored within a file outside of a database.
  • Archived information: Storage of information required by law.

Software assets

  • Application software: Implements business processes.
  • System software: Operating Systems, Mobile OS’, VOIP, etc.

Physical assets

  • Computer equipment: desktops, laptops, phones, servers
  • Communication equipment: PBX, POP gateway, routers, switches
  • Storage media: off/on-site backup media, software inventory, etc.
  • Technical equipment: UPS, server racks, wiring closet(s), etc.

Understanding where your sensitive data lies, which systems house the data, and how to score the criticality of those systems often stops IT security teams in their tracks. This can be a daunting exercise; however, the initial assessment does not need to be perfect, it can be optimized in subsequent exercises.

Network Segmentation

Network segmentation is good, or so you’ve heard. But what  segmentation? Is it enough to have different VLANs? While using different VLANs can provide benefits such as smaller flooding and failure domains, segmentation usually is used to describe two networks that don’t have direct access to each other. There are two forms of segmentation; macro segmentation and micro segmentation.

Macro-Segmentation

Macro-segmentation is used to describe networks that are walled off from each other. For example, (1) a guest network that is separate from the enterprise users’ network, (2) a management network that is separate from the enterprise users, and (3) an IoT network that is isolated from everything else. Macro-segmentation is often implemented using Virtual Routing and Forwarding (VRFs) and/or firewalls.

Micro-Segmentation

There is also micro-segmentation, which describes how to filter within a macro segment. For example, maybe users shouldn’t be able to communicate with each other. Should a printer be able to communicate with another printer? Should one ventilation system be able to communicate with another? Normally they can, since they belong to the same segment, but you may want to restrict it, which would require micro-segmentation. This would often be implemented using some form of Software Defined Networking (SDN) technology or by installing a client on computers and servers, etc.

There are also of course many other types of segments, such as a Demilitarized Zone (DMZ), where you host public services that are reachable from the internet.

Why do we need segmentation, though? 

Well, do ? What did the requirements say? Why we create segmentation comes from the requirements. For example, a network requirement could state, “Guest users may only use the internet and must not have access to any internal networks.” With a requirement like that, you would need to create segments because guest users should be separated from enterprise users. If there is another requirement, such as, “Enterprise users must not have access to each other,” then most likely you need some form of micro-segmentation. The purpose of segmentation is to be able to control what traffic is allowed between segments.

From a security perspective, it is also important to restrict lateral movement. If someone hacks one of our web servers, we don’t want them to have access to, for example, our domain controller. That is why we don’t allow any traffic from the DMZ to our higher security zones, such as where we keep the domain controller.

Example of Poorly Designed Network

An example of a poorly designed network would be the following: Using your POP firewall to segment your Internet-facing systems from your internal resources but ignoring to segment the systems that directly interface with those DMZ systems, such as backend databases, from your DMZ and internal resources. A great example of what not to do was illustrated in the Target hack which involved malicious actors exploiting HVAC systems, laterally moving to POS (Point of Sale) devices and gaining access to the financial information of ~40 million customers. With proper network segmentation of HVAC systems from sales systems & databases, Target would’ve avoided the damage to its business and brand.

Network segmentation can become tedious and time-consuming because your business has many components to compartmentalize but consider the potential fallout to your business and Target’s actual: resignation of Target CEO and legal settlements resulting in over $300 million.

One of the most common mistakes information technology teams make is arbitrarily adding technology to the corporate network. Without adding barriers to systems, attackers can move from one piece of technology to another searching for sensitive information or other targets on the corporate network.

Network Access Control

Let’s say you plug in your computer to a switch port. With no authentication, you have full access to other users, your management network, and the internet. Is this good security? We could argue that it’s bad, but what did the requirements say? When implementing network access control, we must of course consider the security requirements, but also the ease of use. If the network becomes too complicated and complex to use, and error-prone, then our design has failed, even if we met the requirements. What is network access control?

Many forms of network access control come to mind. The most obvious one perhaps is to implement 802.1X in your LAN. This is a mechanism that authenticates users, and optionally their computer, before allowing them access to the LAN. This can be in the form of providing credentials, and/or using certificates. Depending on the user, they may get different levels of access to the network. This can for example leverage Dynamic ACLs (DACL).

There are of course many other methods, such as using firewalls to enforce rules for what traffic can flow between segments. The network may use a proxy, such as Umbrella Secure Internet Gateway (SIG), to enforce what is allowed for use on the internet. This can be enforced in the network or on the client itself.

There may also be things that are so obvious that you didn’t even consider them. What about putting network equipment in a locked room to prevent people from accessing them or shutting down switch ports so that people can’t connect to random ports? Network access control can be anything from physical security to policy and much more.

Principle of Least Privilege (POLP)

Applying the principle of least privilege to standard user accounts means granting a limited set of privileges — just enough privileges for users to get their jobs done, but no more than that. Adherence to and implementing POLP is fundamental to your network design and reduces the risk of malicious actors gaining access to your high-value systems & assets by compromising a low-level user account, device, or application.

POLP can be applied to end users, systems, processes, networks, databases, applications, and every other aspect of your business technology infrastructure.

Examples of POLP in Practice

  • : An employee whose responsibilities include entering information into a database only needs the ability to add records to that database. If malware infects that employee’s computer, the malicious attack is limited to making database entries.
  • : Ideally, an online form that lets users sort records should use a MySQL account that only has sorting privileges. Thus, an attacker who exploits the form has only gained the power to sort records.
  • : A user who rarely needs root privileges should work with reduced privileges the rest of the time. To increase traceability, that user can retrieve root access credentials from a password vault as needed.

Policy Enforcement

How do we enforce our policies, like the requirement that users can’t talk to each other? How is policy enforcement different from network access control? Network access control pertains more to giving access to the network itself while policy enforcement is about preventing access when you already have access.

There’s quite some overlap here, though. Let’s break the word down into its components. Policy is the intent of our network; the translation of our requirements into a set of rules. Enforcement is to ensure that our policy is adhered to. To be able to enforce something, packets must pass through a device that can decide if the packet adheres to the policy or not.

What we need are choke points. When you travel to another country, they have a border. They also control your passport before admitting you. This is policy enforcement at a choke point. This is the same thing that we do in our networks. Traditionally, all our traffic went to some kind of headquarters or data center and passed through a big fat firewall. Most organizations moved away from this design, as it created a less-than-optimal user experience. But what are some of the chokepoints or potential policy enforcement nodes that we have today? There are many, so let me list a few of them.

  • Firewalls
  • Proxies
  • IDS/IPS (often integrated with the FW)
  • Switches
  • Routers
  • Wireless LAN controllers
  • Applications on clients and servers

There are many places where we can enforce policies. The main challenge is most often on getting visibility, though. You can’t enforce a policy if you don’t know what’s in the packet.

The other challenge is often around implementation. If you have a firewall in every branch, and you have 1000 branches, how easy is it to manage this? It would come down to how standardized your design is. This is why many organizations are now using cloud proxies to have fewer choke points and make it more manageable. The other thing I often see in network design is organizations don’t know what their policy is, what apps and systems they have, or what ports they use and the traffic flow. You can’t write a policy if you don’t have enough information to classify what is allowed or not.

Visibility, Monitoring and Prevention

What does visibility have to do with security? If your organization is blind to what is going on in the network, how can you prevent any threats? You can’t! You need visibility to understand traffic flows and what is getting into your network.

How do you get visibility? That’s one big and complicated topic! Did you know that almost all traffic, at least to the internet, is encrypted? This means that it’s getting more and more difficult to see what traffic we have in our networks and hence, how to protect against potential threats. What can we do? We can try to glean information from the packets by looking at DNS requests (if not encrypted), IP addresses (where the packets are going), what ports the packet is using, patterns in the packet, such as size and frequency, and other things. There are well-known prefixes, such as when using Microsoft 365 for example, where we can make a qualified guess about what the traffic is if we recognize the prefix. To get visibility, we often need some form of third-party product that can take information from the network, for example, in the form of Deep Packet Inspection (DPI), NetFlow, packet taps, packet mirroring, etc.

To get full visibility, most likely, you will have to install something at the client. The client is the only place where you can see unencrypted packets — unless you are decrypting the users’ packets using Transport Layer Security (TLS) inspection, of course.

There are many other ways of getting visibility, such as using proxies, firewalls, network access control, and Syslog. The most difficult part, considering the wealth of information, is understanding what is actually going on and how you can prevent attacks such as the exfiltration of your data. If someone logs in from a location where you have no office and they transfer lots of data, wouldn’t you want to know about it? Ideally, visibility should get you insights into incidents such as these.

Using monitoring and prevention tools to defend your network is extremely important. Intrusion detection systems (IDS), intrusion prevention systems (IPS), data loss prevention systems (DLP) and database activity monitoring (DAM) are vital tools that help protect your network by preventing malicious actors from accessing vital systems & assets to your business.

  •  passive monitoring tool strategically placed at the major intersections of your segmented network. Typically deployed with a network tap or a VLAN span port to listen to monitor traffic.
  • similar to an IDS, but actively prevents malicious traffic. Deployed off a network tap to eliminate a point of failure or in-line within your network.
  • monitors and controls endpoint activities to ensure that sensitive data is not lost, misused, or accessed by unauthorized users. Deployed on end-user systems such as desktops, laptops, mobile devices, etc.
  • monitors all activity on a database and provides alerts and reports on that activity. Deployed on a database, but activity stored outside the database is monitored to avoid user/admin tampering.

Security Event Logging

You’re almost there! Your network is segmented, and monitoring and prevention tools are protecting your high-value systems & assets, but your network design must incorporate logging. There’s a common adage: the more logs the better and it’s definitely true because during an audit or breach, it’s always best to have more logs than less. After you verify that the proper level of logging is turned on, the enormity of log data can quickly lead to log fatigue. A secure network design requires a tool to alleviate log fatigue and aggregate, correlate, identify, mitigate, remediate and report malicious activity.

Security Event Logging is broken down into two major categories with both offering a level of full packet capture:

  • : aggregate logs from multiple sources, identify anomalies and take appropriate action through alerting or remediation. Typically deployed with a front end tied to a log data lake on-premise.
  • : a “newer” version of SIEM that incorporates more than just systems such as UBA/UEBA. Deployed on-premise or in the cloud to enable higher efficacy for the collective good.

Your network contains the most critical technology assets of your business organization. You should design your network in a secure manner that eliminates and minimizes single points of failure. The all-or-nothing approach to network security design has left many in IT security contemplating the dozens of variables that could be used in prioritizing how to design the network.

And if You Need Help…


Cyber Security and IT Solutions to secure your digital world

Company

© 2024 ·  KALP SYSTEMS · All Rights Reserved

This is a staging environment