The classical approach to network security was to isolate your internal network from the rest of the world, or say internet, using the firewall. Your firewall succeeded in preventing outsiders from coming in to your network, while still allowing your internal network users to connect to the external networks. For long many years, this approach worked for most organizations.
But this approach is not effective any longer, because now most users are bring in their own devices (BYOD) which are managed and used by users themselves, not by your network administrators. When network admins have no control over how these devices are used by users and how to deploy security measures on these devices, both the device and your network are not safe. There are countless of instances of successful 'Phishing' attacks by hackers when corporate users were lured or tricked into entering their user 'credentials,' which led to hackers gaining access to penetrate systems of organisations. Such phishing attacks are everyday phenomenon worldwide.
Since the classical network security approach heavily depended upon your hardware, primarily, your firewall, a new and far robust approach to security has emerged in the form of Software-defined Perimeters (SDPs).
-
What is SDP?
Software-defined perimeter, SDP is an evolution over classical network security approach. It gives network admins an opportunity to DEPLOY perimeters around the NETWORK itself. It does not matter where your IT infrastructure lies, e.g., on internet, at hosting centers, within clouds or on a private on-premise enterprise network, you still can deploy SDP around it.
Basically SDP is a method of concealing or hiding your key infrastructure of your network that is connected to the internet (e.g., Routers, Servers, etc.) so that external entities cannot see them. Since SDP relies totally on software (not on hardware) to protect, its applications are much more wide and diverse and more agile in its deployment.
When you are using SPD, you are essentially draping 'a cloak of invisibility' over your servers and other infrastructure so that no one can see it from the outside; however, your authorized users can still access the infrastructure.
In technical terms, you are forming a virtual boundary around your company assets at the 'Network' layer, not the application layer. Remember, this is a very important distinction which make SDP very different from your other 'access' based controls which though restricts their PRIVILEGES of your users, but still allow them wide network access. Another big difference is that a SDP authenticates DEVICES as well as USER IDENTITY.
-
How Does A SDP Work?
Using SDP, you ensure that it is not be technologically possible to connect with your servers, routers etc. unless 'authorized' to do so. With SDP, you would allow access to your users only after they fulfill the 2-criteria:
1. Their 'identity' is fully verified.
2. The state of the 'device' they are using to connect to is also verified properly.
Only when the user and his device both are authenticated, SDP would allow an individual network connection between that device and the server it is trying to access. Don't get confused here.... because the user won't be logged into your larger network, instead he will be given his OWN network connection that no one else can access, and this connection only includes the SERVICES that user has approved access to. If you haven't got it, then please re-read this paragraph!
To aid yourself, you can imagine a webserver that is though connected to the internet, but it does not open connections with anything. It does not accept requests or send responses; it has no open ports and no network access even though it is plugged into the Internet. Isn't it something like a lamp or toaster which is plugged into an electric outlet at the wall, but it is turned off so that electricity does not flow through it?
The default state for server inside your Software-defined Perimeter, is somewhat similar to above analogy...
You are even better off, if you think of SDPs is by imagining a front door that is always kept locked. No one can come through the door, or even look inside, until the person inside the house verifies who the visitor is and what they are doing. Once the visitor is allowed inside, the person in the house locks the door again.
The Cloud Security Alliance first developed the SDP concept. According to them, Software Defined Perimeter (SDP) provides an INTEGRATED security architecture that is otherwise hard to achieve with existing security 'point' products, such as Network Access Control (NAC) or anti-malware solutions. What you need to remember here is that SDP is designed to leverage proven, standards-based components, such as data encryption; remote attestation, mutual transport layer security, Security Assertion Markup Language (SAML) and X.509 certificates. Incorporating these and other standards-based technologies ensures that SDP can be integrated with any organization’s existing security systems.
With SDP, you block hackers from the network, in one swift motion! Because SDP deploys multiple cutting-edge security tools and is easily implemented, even and especially for modern organizations with complex cloud networks, many remote users, and varying access requirements.
The core idea behind SDP is not only to prevent the illegitimate users from accessing certain parts of your network, but also to prevent them getting 'inside' the network itself. In order to achieve this, a SDP system makes use of 'Zero-Trust' security, and the principle of: Authentication first, Access afterwards.
-
SDP and Zero-Trust Security
No doubt, SDP and Zero-Trust are both closely related, as SDP can be used to implement zero trust networks. Since SDP is agnostic of the underlying IP-based infrastructure and it hones in on securing ALL connections using said infrastructure - it is the optimal architecture for achieving zero trust.
Zero trust basically assumes that every person, every machine, every user device and network is malicious. Before they are allowed access to a network, they have to prove their—benevolent—identity. It stipulates that every so called user or device can abuse the 'trust.'
That's why, a zero-trust security system always questions 'anyone' or 'anything' trying to gain access and it does so 'every time.' With a true zero-trust system, your user will be forced to prove his identity using any biometric data every time he attempts to access the network or part of it. Further, the legitimacy of their identity card or token will also have to be verified, where if possible the token is constantly changing. In this way, if either the user or the device they are using is fraudulent, the user is denied access to the network automatically.
So you can say that SDP is one way to implement zero trust security. Your users and devices must both be verified before they can connect, and they have only the minimum network access they need. No device, not even a CEO's laptop, can form a network connection with a resource it is not authorized to use.
+
Black Cloud Approach For Network Security
The underlying guiding principle of SDP for security of your network is using the 'Black Cloud' approach, as you are attempting to hide your Internet-connected infrastructure (servers, routers, etc.) so that external parties and attackers cannot see it.
You are putting a WALL (not firewall) between your network and attackers. They cannot see your network. Therefore, they cannot hack into it. When an attacker is able to see into your 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 your 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. That's is the reason, it eliminates the possibility of 'designing' attack methods for the different components of your network or its security features. Does it make sense to you?
This approach is named 'Black Cloud' 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 first.
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, or 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 the vault.
It is the same with 'Black Cloud' network security. The network can be protected by firewalls, NGFWs, web application security measures, internal multi-factor authentication (MFA), anti-malware, DLP 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. Right?
+
Authentication First, Access Afterwards Approach
With this approach, no user is 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 for an example.
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 your network, its components, internal systems, and applications.
Once a user is allowed to get inside after successful authentication, further access restrictions are imposed. In order to pass those restrictions, a user needs to complete the additional authentication measures. Ideally, both layers of access security should incorporate 'Multi-Factor Authentication (MFA) measures, such as something the user has on their physical person, something the user knows, and the biometric data of the user.
-
What is the difference between SDP and VPNs?
You already know that, a virtual private network (VPN) is an encrypted network that runs over an unencrypted network. It creates 'encrypted' connections between devices and servers so that it is as if they are on their own private network. Traditionally, VPNs have been used to secure and manage access to company infrastructure.
But SDPs are very different from VPNs, though SDPs may incorporate VPNs into their architecture to create secure network connections between user devices and the servers they need to access. VPNs basically allow ALL USERS to access the 'ENIRE' network, but SDP does not.
Unlike a VPN, which listens for inbound connections, SDPs receive no inbound connections. By responding with outbound-only connections, both network and application infrastructure are kept invisible or cloaked to the internet and therefore impossible to attack.
Networking guys who have used VPNs would tell you that if you need to manage several different levels of 'network access', then you would need to deploy multiple VPNs.
Suppose Bob works in accounting department of a company, Carol works in sales, and Alice works in engineering. IF you want to manage their access at the network level, then you would set up three VPNs:
1) an accounting VPN to provide access to the accounting database,
2) a sales VPN for the customer database,
3) an engineering VPN for the codebase.
But these multiple VPNs would make it very difficult to manage, and network security would also be diluted. Because any one who can access the first VPN, he would have access to whole of financial information of this company. You don't want that.. Do you?
Similarly, if Bob's credentials are accidently shared with Carol who belongs to sales department, the again the security would be compromised, and your IT department will not even be aware of it.
Let us now build upon the analogy, suppose there is David who is Chief Financial Officer (DFO) of this company and he frequently needs access to both the accounting database and the customer database.
Should David have to log into two separate VPNs in order to do his work? Or should this company's IT department set up a new VPN (fourth one) that provides access to both accounting and the customer database?
Both options are difficult to manage, and the second option in particular, introduces a high degree of risk. For example, what would happen, if an attacker compromises this new VPN which has a broad access across two databases?
SDPs will make your life easier to manage than VPNs, especially if your internal users need multiple levels of access.
SDPs offer more options than VPNs. With a VPN, once you are in, you are in. With an SDP, you 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.
However, similar to a VPN, if additional security measures are not applied, an SDP could be vulnerable also if an attacker steals someone else’s credentials. Another danger that comes from over-relying 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 a SDP solution with additional security layers, e.g. NGFWs or web application firewalls (WAFs), MFAs, etc. Indeed, the principle of 'Least Privileges' makes things quite tight from security perspective.
-
How Does A User Gain Access Over A SDP?
1. Initiating the request to connect to a service.
The user (the SDP client) initiates a request that goes straight to the SDP controller. In its response, the SDP controller provides a list of what the client is allowed access to, on the basis of predesigned policies.
Once the controller has finished determining whether the client is using the 'appropriate gateway,' SDP controller forwards all the necessary information regarding the access policy to the SDP 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 SDP client (at user's device) 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.
2. Authentication of User Identity.
User identity is typically verified via a third-party identity provider (IdP) such as Okta, Google, or Azure, etc. SDPs may integrate with an SSO solution as well. User authentication can involve a simple username and password combination, but it is more secure to use multi-factor authentication MFA) with some sort of hardware token, single sign-on (SSO), or other methods, such as Security Assertion Markup Language (SAML).
3. Authentication of Device
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. This may also involve checking to make sure the user's device is running up-to-date software, encryption on its hard drive, checking for malware infections, its firewall status, etc. and performing other security inspections. Theoretically, an SDP could even create a blocklist of disallowed devices and check to make sure the device is not on the blocklist.
NOTE:
--------
Some other factors may also be used depending 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.
4. The Approval from SDP Controller
You can think of SDP Controller as a Trust Broker. The controller establishes trust between the SDP Client and backend security controls by authenticating users and devices.
The SDP "controller" is the logical component of the SDP that is responsible for determining which devices and servers should be allowed to connect. The controller then gets the above 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.
Once the user and device are authenticated, the controller passes along approval of the user and device to the SDP gateway. The SDP gateway is where access is actually allowed or denied.
5. Establishing Secure Network Connection
Now the SDP gateway comes into operation and it opens the virtual "gate" to allow the user through. It establishes a secure network connection with the user device on one side of the gateway, and on the other side it establishes a network connection with the SERVICES that the user has access to. REMEMBER, no other users or servers share this connection. These secure network connections typically involve the use of mutual TLS, and may use a VPN.
6. User access
Now the user is able to access previously hidden network resources and can continue using their device like normal. The user operates within an encrypted network to which only they and the services they access belong. You 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, then your user can enjoy a private, safe connection without compromising sensitive information.
-
Kindly write 
your comments on the posts or topics, because when you do that you help me greatly in 
designing new quality article/post on cybersecurity.
your comments on the posts or topics, because when you do that you help me greatly in designing new quality article/post on cybersecurity.You can also share with all of us if the information shared here helps you in some manner.
Life is small and make the most of it!
Also take care of yourself and your beloved ones…
With thanks,
Meena R.
____
This Article Was Written & published by Meena R, Senior Manager - IT, at Luminis Consulting Services Pvt. Ltd, India.
Over the past 16 years, Meena has built a following of IT professionals, particularly in Cybersecurity, Cisco Technologies, and Networking...
She is so obsessed with Cybersecurity domain that she is going out of her way and sharing hugely valuable posts and writings about Cybersecurity on website, and social media platforms.
34,000+ professionals are following her on Facebook and mesmerized by the quality of content of her posts on Facebook.
If you haven't yet been touched by her enthusiastic work of sharing quality info about Cybersecurity, then you can follow her on Facebook:
Click Here to follow her: Cybersecurity PRISM