Security in Network Design: Key Considerations from a Network Architect’s Perspective
This guest post was authored by Cisco Designated VIP Daniel Dib, CCIE #37149, CCDE #20160011.
Recently I was describing on Twitter the amazing colleagues I’m getting to work with on a project, with CCIE certifications in Enterprise Infrastructure, Data Center, Wireless, and a CCDE certification. Someone responded to me, “Who is responsible for security?” My response was, “We all are.”
While we still definitely need people who specialize in security (there is no doubt about that), it is now the job of everyone to consider security in their network designs. You have to consider security within all network architectures. It is no longer enough to put a firewall at the perimeter and call it a day.
Key considerations for security in network design
Regardless of whether it’s a LAN, data center, or WAN, what are some of the key considerations for security in network design? Let’s have a look at the CCDE v3.0 Written exam blueprint.
Under network security design and integration, we have:
- Segmentation
- Network access control
- Visibility
- Policy enforcement
- CIA triad
- Regulatory compliance
Before we start diving into these CCDE exam topics, let me describe the process of designing a network—and how security can never be an afterthought. So, what differentiates a good network design from a bad one? Is it how redundant it is? Is it the number of firewalls? Is it the number of segments? Is it how fast it converges?
No. The only thing that differentiates a good network design from a bad one is whether it meets the requirements. A network design must always meet the requirements. Not meeting the network’s requirements is obviously bad. But overdelivering can also be bad, and is sometimes referred to as “gold plating.”
So, how do you know what the network requirements are? Usually, the first step in a network design (and perhaps the most important one!) is gathering the requirements. Once the requirements are gathered, I often document them in what is known as a Customer Requirements Document (CRD). The document includes answers to a myriad of questions covering business requirements, functional requirements, technical requirements, and operational requirements.
When creating this document, it is important to understand what type of organization I am dealing with. What is a typical user? What type of traffic flows do they have? How do they use the internet? What type of VPNs do they have? Already, at this phase, I need to understand what the customer and network look like to define what the security requirements are. Now let’s go back to the CCDE blueprint and dive into each area of network security design and integration, as well as how they affect a network’s design.
Network Segmentation
Network segmentation is good, or so you’ve heard. But what is 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 you? 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.
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 switchports so that people can’t connect to random ports? Network access control can be anything from physical security, to policy, and much more.
Visibility
What does visibility have to do with security? Growing up in the ’80s and being named Daniel, The Karate Kid was one of my favorite movies. In The Karate Kid Part III, there is this quote from Terry Silver, the main antagonist in that movie. He says, “A man can’t see, he can’t fight.” 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.
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 gets 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 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.
CIA Triad
The CIA triad sounds like some weird combination of the US Central Intelligence Agency and a Japanese mafia. The good news is that this is not at all what it is.
CIA in a network design is:
- C – Confidentiality
- I – Integrity
- A – Availability
Confidentiality is about keeping the organization’s data private or secret. All data should be private, right? What did the requirements say? A guest network at Starbucks will have different requirements than the Department of Defense (DoD) highly classified networks. This makes sense, right?
Integrity is about ensuring the integrity of the data. How do you know the information I sent you really came from me? What if my packet was altered before it reached you?
My data may be secure and private, and we ensured the packets couldn’t be tampered with, but if my packet doesn’t reach you, what good does it do? A secure system must also be available.
Let’s take a closer look at the components of the CIA triad. Then I’ll let you in on how this all ties together.
Confidentiality is about keeping data private or secret. There are many potential threats here, such as accessing data in transit if it’s not encrypted, using weak algorithms, key loggers, attackers moving laterally after taking over an IoT device, and so on. The main tools for keeping the data secret are having proper access controls, such as using strong passwords, implementing Multi-Factor Authentication (MFA), using least privilege access, and encrypting the data — at rest and in transit. There are also other measures, such as avoiding shoulder surfing, locking the computer, and preventing USB-device access to the computer.
Integrity is about ensuring that the data has not been tampered with. This could happen to data that is in transit or at rest. Having unauthorized access to data is bad enough, but what if they were also able to alter the data? Imagine someone gets access to the system that manages your bills and redirects a payment to themselves. The main protection mechanisms, beyond access control, are digital signatures such as certificates, checksums, and message digests (also referred to as hashes). Certificates are used to verify the identity of the sender. Checksums and message digests are used to verify, using cryptography, that the data has not been altered.
Availability is often overlooked from a security perspective. Having the data unavailable is a security threat as well, though. Ensuring availability comes down to having a proper design in place that meets the availability requirements. This involves having redundant systems and paths, but in addition to redundancy, you also have to consider resiliency. What if you have redundant switches, routers, and firewalls, but they all use the same power source? What happens when you have a power outage? I have worked with environments where they used both AC and DC power as well as UPS and diesel generators to prevent scenarios where redundant components go down with the other components. You also have to consider this from a transport perspective. Having a single transport, such as the internet, puts you at greater risk of making your systems unavailable.
From an attack perspective, the main threat to availability is if your systems get attacked and the attacker crashes the systems. More commonly though, you would see something like a DDoS attack, where your systems are flooded with traffic. Someone could also try to send massive amounts of data into an application, such as a database, to have the system crash. Having your data encrypted by a crypto locker would also be a threat to your availability.
Protecting yourself includes having a good design, where you have considered the availability requirements and what transports to use, as well as implemented security systems that can filter out threats. Take IDS/IPS, for example. Some threats, such as DDoS, are difficult to handle on your own. You may need to rely on your ISP for protection in such scenarios.
Regulatory Compliance
What was it Huey Lewis and the News said? It’s HIPAA to be square? Resistance is futile; you will be assimilated. I don’t recall whether this was from Star Trek or my PCI auditor. Joking aside, regulatory compliance is very important, of course. Regulatory compliance is there to ensure that organizations live up to the standards that are required to keep our data safe. The two most well-known ones are probably Health Insurance Portability and Accountability Act (HIPAA) and the Payment Card Industry Data Security Standard (PCI DSS). HIPAA is used to help keep our medical records safe, for example. PCI DSS is used to create safe payments, so our credit card numbers don’t get leaked.
When it comes to regulatory compliance, there are a lot of requirements that come with them. You have to fulfill the requirements, and there may be auditing involved to ensure that you are doing so. The requirements may include things like segmentation, encryption, access control, and more. While working with regulatory compliance can be tedious, time-consuming, and sometimes feel like you are designing for things that should be obvious, they are there to ensure that organizations meet the minimum standards when working with sensitive things such as medical records and payment information.
This blog post ended up a little longer than I anticipated, but I wanted to give you insight into just how much there is to consider in network design, or any design when it comes to security. Even if you don’t specialize in security, it should still be top of mind in everything you do. Keep in mind though, any design strives to meet the requirements, nothing more, nothing less.
 
If you enjoy talking about network design or are studying for the CCDE certification, join me in the CCDE Certification Community on the Cisco Learning Network. Check out this CCDE: Ask about anything discussion, where you can get your CCDE cert questions answered directly by Cisco. Thanks for sticking around and see you next time!
Ask questions, share ideas, and connect with the CCDE Community.
About Daniel Dib
Daniel Dib, CCIE #37149, CCDE #20160011, is a senior network architect at Conscia Netsafe. He works with creating scalable, modular, and highly available network designs that meet business needs. Daniel started out in implementation and operations and got his CCIE in 2012. In May 2016, he became the second person in Sweden to get CCDE certified.
He often acts as a subject matter expert for his customers with deep expertise in routing, switching, multicast, and fast convergence. He is an active person in the networking community and believes in helping people reach their full potential. He writes technical articles, and blogs and holds member-led study sessions for the members of the Cisco Learning Network.
Follow Cisco Learning & Certifications
Twitter | Facebook | LinkedIn | Instagram
Share:
