Software-defined Perimeter (SDP)
Software-Defined-Perimeter (SDP) Defined
Software-defined perimeters (SDPs) are used to combat these and other kinds of attacks. They give IT admins the opportunity to deploy perimeters around the network itself. They can be applied in a variety of environments, including on the internet, at hosting centers, within the cloud, or on a private enterprise network.
A software-defined perimeter is a method of concealing infrastructure that is connected to the internet, such as routers and servers, preventing external users from being able to see it. It does not matter whether the infrastructure is hosted in the cloud or on-premises—an SDP can still be deployed to protect it. SDP hinges on the use of software—as opposed to hardware—to protect an environment. Because it is software, its applications are more diverse, and its deployment process is more agile than hardware solutions.
Network Security Before Software-defined Perimeter (SDP)
Traditionally, an enterprise would seek to develop a network security architecture with the principal aim of isolating an internal network from the rest of the world. This was often accomplished using a firewall that would prevent outsiders from coming in while still allowing those inside the network to get out.
In many cases, this setup did an adequate job of keeping external threats from penetrating the system and affecting internal services. Firewalls can prevent threats from entering the interior of the network and stop hackers from getting an in-depth look at an organization's internal network security measures. By limiting hackers’ visibility and the avenues malware would use to levy attacks, traditional security measures have been able to protect many systems with a level of effectiveness.
Weaknesses of the Traditional Setup
However, there are weaknesses inherent to this model. Primarily, because there are so many devices that users manage on their own, each device becomes a vulnerability. If an IT administrator has control over how a device is used and the security measures employed to protect it and the network, both the device and the network are safer. But if the device is managed by an individual user, they may or may not adequately protect it from attack. This can leave the entire network vulnerable.
Further, phishing attacks have been used by hackers to gain access to network resources and information. Because a user only needs to enter credentials—after they are already in the network—to access sensitive areas, a hacker only has to use a phishing attack to collect a user’s credentials. Then they are in. In a phishing attack, the user is tricked into entering their user credentials in a site that the hacker uses to collect their information. The attack most often begins with an email, and after the user clicks on a link, goes to a fake website, and enters their login credentials, the hacker can then get them from the site’s database and use them to penetrate a system.
Principles of SDP?
One of the driving principles of SDPs is users cannot gain access before being authenticated. This makes it different from access-based control setups, which may allow a user to get inside the network but restrict their privileges until they authenticate their identities and are therefore granted the rights to get to sensitive areas.
Another important differentiating factor is that an SDP system authenticates both the user and the device they are using. This provides an additional layer of security because even if a hacker is able to steal a legitimate user’s credentials, if they are on their own device, they still will not be able to get past the SDP’s defenses.
There are some potential security issues with SDP, however. If someone steals both a user’s credentials and device, they still will be able to get into the network. Then, once inside, they may also be able to access the application layer, in addition to the network layer. This can leave your applications vulnerable to attack, particularly if you do not have another layer of security shielding them from intruders.
The need to protect networks using SDP is growing because of how networks and device usage are evolving. The growing scale of networks and devices makes the issue of securing your infrastructure with software-defined perimeter architecture even more acute. Each device that gets added to the network automatically becomes a potential attack surface—as do other networks linked to a primary, secondary, or tertiary one.
This includes devices users bring to the work environment as they take advantage of a bring-your-own-device (BYOD) policy, as well as extensions of the network via cloud or hybrid environments. The more users and systems that get connected, the greater the risk. Using a software-defined perimeter can keep intruders from accessing the network altogether, giving you a stronger security posture.
History of Software-defined Perimeter (SDP)
Cloud Security Alliance, a nonprofit leading the charge in cloud-specific security research and education, formed a software-defined perimeter working group to develop and refine the technology. The principle motivating the group was to control access to the resources within a network based on the user’s identity. In this way, malicious users would be both kept away from sensitive areas within the network and the network itself.
Since its inception, software-defined perimeter solutions have been adopted and developed by many of the leading networking solutions providers in the world. The market size is expected to grow to $13.8 billion between now and 2024. It is also projected to experience a compound annual growth rate (CAGR) totaling 36.5%.
How Does Software-defined Perimeter (SDP) Work?
Software-defined perimeter vendors are charged with the task of not only preventing illegitimate users from accessing certain parts of the network but also from getting inside the network itself. To accomplish this, the system makes use of zero-trust security, what is often referred to as a black cloud approach, and the principle of authentication first and access afterward.
Zero-trust Security
Zero trust assumes that every person, machine, and network is malicious. Before they are allowed access to a network, they have to prove their—benevolent—identity.
To illustrate, think of a concierge, whom we will call George, at a high-end apartment building where you live. When you first move in, you introduce yourself to George and he gives you a card that serves as the key to your apartment. You can also swipe the card to gain access to the gym, business area, meeting rooms, and common areas. The next day, you decide to go to the gym after you finish work. You walk in the front door, and you see George. He nods to you, recognizing your face. You nod back, say a brief greeting, and head toward the gym. You swipe your card to gain access to the locker room, change, then swipe it again to get into the workout area itself.
This is how a traditional security system works. When George sees your face, he trusts that you are who you appear to be. Also, because you have access credentials—your key card—after George nods you in, you can go to various areas of the “infrastructure” of the building. However, if you have an identical twin who steals your key card, they can probably walk in, get a nod from George, and access the same things you can. That is the weakness of a trust-based system. If a device is used and validated one day, and the same device is used the following day, a trust-based system allows access. However, someone who steals the device can abuse this trust.
On the other hand, a zero-trust security system always questions anyone or anything trying to gain access. To mirror a true zero-trust system, George will have to force you to prove your identity using biometric data every time you come into the building. Further, the legitimacy of your key card will also have to be verified, perhaps by using a constantly changing token that can only be received by a legitimate key card. In this way, if either the user or the device they are using is fraudulent, the user is denied access to the network.
Don’t Diverge, Converge - Build a Zero Trust Strategy
Zero Trust strategy enables organizations to build a security-driven network.
Watch the on-demand webinar
How Do SDPs Relate to Zero Trust Security?
A software-defined perimeter fully aligns with zero-trust security principles because of the kinds of verifications it requires. Anyone trying to connect has to first verify their identity. Also, the SDP assesses the state of the device they are using to make sure it does not present any threats. Only after both the device and user have been deemed safe will a connection be allowed to take place.
What is SDP in networking? In a way, it is another type of zero-trust methodology. Its connection dynamic complies with zero trust because whether a user, device, or network is trying to connect, the SDP presumes it is a threat and can interface with the network only after it has proven that it is not.
What is SDP: SDP vs. VPN
SDPs and VPNs are similar in that users cannot connect to them without presenting credentials. Both use a strict authorization scheme to verify users do not present a risk.
However, that is where the similarities end. SDPs are, in some ways, significantly more secure than VPNs. For example, a VPN allows any user that has connected to the network to access the entire ecosystem. SDPs, on the other hand, do not allow all users to access every area of the network. Instead, each user gets their own specific connection.
You can set up each SDP connection in a way that meets the needs of individual users. With a VPN, you have a single secure portal that everyone shares. So deploying an SDP is a lot like giving each user their own individual VPN.
Another key difference is that SDPs can be set up anywhere you want and with a wide variety of infrastructures, simply because they are based on software instead of hardware. This means they can protect your on-premises or cloud infrastructure equally well.
Black Cloud for Network Security
By implementing a black cloud infrastructure for network security, you are putting a wall between your network and attackers. They cannot see the network. Therefore, they cannot hack into it. When an attacker is able to see into the network, they can search for vulnerabilities. Even if your various network components are secured, a hacker may still be able to figure out loopholes.
For example, some firewalls have a hard time stopping zero-day threats. If an attacker is able to see inside a network, part of which is protected by this kind of firewall, they can devise a zero-day attack that may be able to slip past it.
On the other hand, with software-defined perimeter security, the attacker cannot even see inside the network in the first place. This precludes the possibility of designing attack methods for the different components of the network or its security features.
Black cloud is so named because it makes the network behind it “black” or unseen. It is similar to a bank vault that is completely encased in a huge cube made of steel. Before a thief can even begin to try to figure out the combination for the vault, they will have to get through the steel walls around it.
Further, because the thief cannot see past the steel walls, they do not know if the vault is secured by an old-fashioned, spinning combination lock, a biometric reader, or other security devices. The thief also has no way of knowing how the vault’s opening mechanism works. Is it a huge deadbolt, a single latch, or a combination of the two? Because the thief has no idea what is there, they do not know what tools to bring or the technology they need to get inside.
It is the same with black cloud network security. The network can be protected by firewalls, next-generation firewalls (NGFWs), web application security measures, internal multi-factor authentication (MFA), anti-malware, data loss prevention systems, email security—the list goes on. But the thief has no idea what they will face if and when they get past the “steel walls” of the black cloud.
In some ways, software-defined perimeter companies offer something similar to a virtual private network (VPN). Users are kept on the outside unless they have the appropriate credentials. However, SDPs are different, primarily in that network connections are not shared between devices that connect.
Also, SDPs offer more options than VPNs. With a VPN, once you are in, you are in. With an SDP, an administrator can choose which resources a user has access to once they are allowed network visibility and entrance. So while an SDP can incorporate a VPN as an element of its architecture, it is a very different security solution.
Authentication First, Access Afterwards Approach
With an authentication first, access afterwards approach, the user is not allowed to access the network or any of its components. This differs from architectures that allow users to get inside the network but require them to provide credentials to use certain aspects of it. For example, any user can access the network, but only those with the right credentials can use the services provided by the email server.
With an authentication first, access afterwards approach, no one is allowed to get into any facet of the network unless they have first been authenticated. In this way, attackers are denied visibility into the network, its components, internal systems, and applications.
Once a user is inside, it is possible to create further access restrictions that can only be bypassed using additional authentication means. Ideally, both layers of access security should incorporate MFA, which requires multiple authentication measures, such as something the user has on their physical person, something the user knows, and the biometric data of the user.
The authentication first, access afterwards approach is another facet of an SDP that makes it similar to a VPN. With a VPN, a user needs to prove their credentials prior to gaining access to the network. If they do not have the proper credentials, they are not allowed in. In this way, they have no visibility into the network and cannot try to compromise specific aspects of it.
However, similar to a VPN, if additional security measures are not applied, an SDP could be vulnerable if an attacker steals someone else’s credentials. Another danger that comes from overrelying on an authentication first, access afterwards approach is, unlike a VPN, communications happening within the network are not automatically encrypted within the confines of an SDP. Therefore, if a malicious actor gains access, they can potentially spy on the communications of others within the network.
For these reasons, it is important to bolster an SDP solution with additional security layers. Some examples include NGFWs or web application firewalls (WAFs).
Software-defined Perimeter (SDP) Architecture
The technology that powers an SDP approach is able to create a perimeter, securing it using policies that isolate services, keeping them separated from networks that are not secured. This is often accomplished using the principle of least privilege. This means that only those who absolutely need to use specific resources to perform their jobs are allowed access to them.
With least privileged principles implemented, you are protected from multiple threat vectors. Two of these are malicious attackers who will seek to compromise a network using someone else’s credentials and those who may accidentally leave their credentials or access available to someone else.
For example, if someone is allowed to access both the email server and the firewall settings but only needs the email server to perform their job, this will violate the concept of least privilege. If they are to leave their computer running and leave their workstation, someone can slip in and access the firewall settings, changing them to allow a future attack to penetrate the network. With least privileged principles in place, this kind of mistake will only expose the user’s email account to attack instead of both that and the firewall configuration. Therefore, least privilege is an integral aspect of an SDP.
An SDP is able to authenticate users, as well as devices, before allowing either of the two to gain access to the network. To do this, an SDP architecture depends on two primary components: controllers and hosts. SDP controllers are able to determine how SDP hosts communicate. In SDP architecture, the SDP host can either initiate the communication or accept it. A host that initiates communication first connects with the SDP controller. This connection is used to figure out which other SDP hosts the initiating host will be allowed to connect to. The SDP host that receives this communication can only get it if it is sent through an SDP controller.
In SDP architecture, devices that people try to use to access the network or a part of it are referred to as clients. There are different ways the client can try to connect to an area of the network. You can set up an SDP as a gateway that acts as a middleman security feature between the client and the servers the SDP is protecting. In a gateway architecture, the accepting SDP host receives a request from the client, such as an application on a desktop computer. In this way, the SDP gateway “introduces” the client to the server and its resources—only after verifying the legitimacy of the client and its user.
This is how all the components involved in the SDP process work together:
- The client initiates a request that goes straight to the SDP controller. The controller follows up by responding to the client's request. In its response, the SDP controller provides a list of what the client is allowed access to. The resources the client is allowed to access are governed by predesigned policies.
- Once the controller has finished determining whether the client is using the appropriate gateway, the controller forwards all the necessary information regarding the access policy to the gateway. The gateway can then reach out to the client that is running on an endpoint, such as a computer, tablet, or another device.
- The client takes this information and processes it, recognizing the policies it has to run, as well as the gateways with which it must connect. Once the client knows the gateways it needs in order to get the services it wants, it can then initiate an authentication process that is unique to that particular client. This authentication will be based on information about the device that is unique to it, such as its configuration, Internet Protocol (IP) address, and other information, some of which may depend on the context in which the client is connecting. For example, geolocation data can be used to authenticate the legitimacy of the connection. If that client always connects from Los Angeles, but it is suddenly reaching out from North Korea, the system can be programmed to reject the connection attempt.
- The controller then gets the information and checks to see if the client satisfies the requirements for authentication. The controller also examines the security state of the client. The security state is a snapshot of the threat level of the client, and if it does not match a predetermined safe state, the client can be denied access.
- After authentication has occurred, the client is allowed to connect securely to the gateway. At this point, data can be sent directly between the client and the resources it was trying to access.
How to Set-up a Software-defined Perimeter (SDP)
To set up a software-defined perimeter, you have to first verify the identity of the user. This can be done using MFA, single sign-on (SSO), or other methods, such as Security Assertion Markup Language (SAML).
The next step is to verify the security of the device. This needs to be done both before the device is allowed to connect and after the session has finished. Various data points pertaining to the device can be used to do this, including its location, malware status, registry information, antivirus settings, encryption on its hard drive, firewall status, and more. Predefined policies determine the settings and states that will be accepted or rejected. If the device conforms to the policies, it is allowed to connect.
The final step is to ensure the data is protected. This is where the SDP vendor plays a critical role. They have to take the extra step of setting up secure tunnels of communication between the device and the applications it is accessing. If data is encrypted for the entire session, the user can enjoy a private, safe connection without compromising sensitive information.
How Fortinet Can Help
FortiToken Cloud provides administrators with a simple, central authentication system. It helps you grant, deny, revoke, and manage access privileges. This is accomplished through the deployment of two-factor tokens using FortiToken Mobile. Users need to have the tokens issued to them to connect to the protected environment.
The system can interface with a FortiGate environment, making secure connections straightforward and fast. With FortiToken Cloud, you can also easily add deployments if you need to increase the number of users quickly.
FAQs
What is a software-defined perimeter (SDP)?
A software-defined perimeter (SDP) is a method of concealing infrastructure that is connected to the internet, such as routers and servers, preventing external users from being able to see it.
How does a software-defined perimeter work?
A software-defined perimeter prevents illegitimate users and/or devices from accessing certain parts of the network and from getting inside the network itself. To accomplish this, the system makes use of zero-trust security, what is often referred to as a black cloud approach, and the principle of authentication first and access afterwards.
How do you set-up a software-defined perimeter (SDP)?
To set up a software-defined perimeter, you have to first verify the identity of the user. This can be done using multi-factor authentication (MFA), single sign-on (SSO), or other methods, such as Security Assertion Markup Language (SAML). The next step is to verify the security of the device. The final step is to ensure the data transmitted during the connection is protected via secure tunnels between the device and the services it is using.
