micro segmentation technology

Zero Trust Security Strategy

 

zero trust security strategy

 

Zero Trust Security Strategy

In this fast-paced digital era, where cyber threats are constantly evolving, traditional security measures alone are no longer sufficient to protect sensitive data. This is where the concept of Zero Trust Security Strategy comes into play. In this blog post, we will delve into the principles and benefits of implementing a Zero Trust approach to safeguard your digital assets.

Zero Trust Security is a comprehensive and proactive security model that challenges the traditional perimeter-based security approach. Instead of relying on a trusted internal network, Zero Trust operates on the principle of “never trust, always verify.” It requires continuous authentication, authorization, and strict access controls to ensure secure data flow throughout the network.

Highlights: Zero Trust Security Design

Networks are Complex

Today’s networks are complex beasts, and considering yourself an entirely zero trust network design is a long journey. It means different things to different people. Networks these days are heterogeneous, hybrid, and dynamic. Over time, technologies have been adopted, from punch card coding to the modern-day cloud, container-based virtualization, and distributed microservices.

This complex situation leads to a dynamic and fragmented network along with fragmented processes. The problem is that enterprises over-focus on connectivity without fully understanding security. Just because you connect does not mean you are secure.

Rise in Security Breaches

Unfortunately, this misconception may allow the most significant breaches. As a result, those who can move towards a zero-trust environment with a zero-trust security strategy provide the ability to enable some new techniques that can help prevent breaches, such as zero trust and microsegmentation, zero trust networking along with Remote Browser Isolation technologies that render web content remotely. 

 

Related: For pre-information, you may find the following posts helpful:

  1. Identity Security
  2. Technology Insight For Microsegmentation
  3. Network Security Components

 



Zero Trust and Microsegmentation

Key Zero Trust Security Strategy Discussion points:


  • People overfocus on connectivity and forget security.

  • Control vs visibilty.

  • Starting a data-centric model.

  • Automation and Orchestration.

  • Starting a Zero Trust security journey.

 

Back to basics with the Zero Trust Security Design

Traditional perimeter model

The security zones are formed with a firewall/NAT device between the internal network and the internet. There is the internal “secure” zone, the DMZ (also known as the demilitarized zone), and the untrusted zone (the internet). If this organization needed to interconnect with another at some point in the future, a device would be placed on that boundary similarly. The neighboring organization will likely become a new security zone, with particular rules about traffic going from one to the other, just like the DMZ or the secure area.

 

 Key Components of Zero Trust

To effectively implement a Zero Trust Security Strategy, several crucial components need to be considered. These include:

1. Identity and Access Management (IAM): Implementing strong IAM practices ensures that only authenticated and authorized users can access sensitive resources.

2. Microsegmentation: By dividing the network into smaller segments, microsegmentation limits lateral movement and prevents unauthorized access to critical assets.

3. Least Privilege Principle: Granting users the least amount of privileges necessary to perform their tasks minimizes the risk of unauthorized access and potential data breaches.

Advantages of Zero Trust Security

Adopting a Zero Trust Security Strategy offers numerous benefits for organizations:

1. Enhanced Security: Zero Trust ensures a higher level of security by continually verifying and validating access requests, reducing the risk of insider threats and external breaches.

2. Improved Compliance: With stringent access controls and continuous monitoring, Zero Trust aids in meeting regulatory compliance requirements.

3. Reduced Attack Surface: Microsegmentation and strict access controls minimize the attack surface, making it harder for cybercriminals to exploit vulnerabilities.

Challenges and Considerations

While Zero Trust Security Strategy offers great potential, its implementation comes with challenges. Some factors to consider include:

1. Complexity: Implementing Zero Trust can be complex, requiring careful planning, collaboration, and integration of various security technologies.

2. User Experience: Striking a balance between security and user experience is crucial. Overly strict controls may hinder productivity and frustrate users.

 

Zero trust and microsegmentation 

The concept of zero trust and micro segmentation security allows organizations to execute a Zero Trust model by erecting secure micro-perimeters around distinct application workloads. Organizations can eliminate zones of trust that increase their vulnerability by acquiring granular control over their most sensitive applications and data. It enables organizations to achieve a zero-trust model and helps ensure the security of workloads regardless of where they are located.

 

Control vs. visibility

Zero trust and microsegmentation overcome this with an approach that provides visibility over the network and infrastructure to ensure you follow security principles such as least privilege. Essentially, you are giving up control but also gaining visibility. This provides the ability to understand all the access paths in your network. 

For example, within a Kubernetes environment, administrators probably don’t know how the applications connect to your on-premises data center or get Internet connectivity visibility. Hence, one should strive to give up control for visibility to understand all the access paths. Once all access paths are known, you need to review them consistently in an automated manner.

 

zero trust security strategy
Diagram: Zero trust security strategy. The choice of control over visibility.

 

Zero Trust Security Strategy

The move to zero trust security strategy can assist in gaining the adequate control and visibility needed to secure your networks. However, it consists of a wide spectrum of technologies from multiple vendors. For many, embarking on a zero trust journey is considered a data- and identity-centric approach to security instead of what we initially viewed as a network-focused journey.  

 

Zero Trust Security Strategy: Data-Centric Model

Zero trust and microsegmentation

In pursuit of zero trust and microsegmentation, abandoning traditional perimeter-based security and focusing on the zero trust reference architecture and its data is recommended. One that understands and maps data flows can then create a micro perimeter of control around their sensitive data assets to gain visibility into how they use data. Ideally, you need to identify your data and map its flow. Many claims that zero trust starts with the data. And the first step to building a zero trust security architecture is identifying your sensitive data and mapping its flow.

We understand that you can’t protect what you cannot see; gaining the correct visit of data and understanding the data flow is critical. However, securing your data, even though it is the most crucial step, may not be your first zero trust step. Why? It’s a complex task.

 

zero trust environment
Diagram Data: Zero trust environment. The importance of data.

 

Start a zero trust security strategy journey

For a successful Zero Trust Network ZTN, I would start with one aspect of zero trust as a project recommendation. And then work your way out from there. When we examine implementing disruptive technologies that are complex to implement, we should focus on outcomes, gain small results and then repeat and expand.

 

  • A key point. Zero trust automation

This would be similar to how you may start an automation journey. Rolling out automation is considered risky. It brings consistency and a lot of peace of mind when implemented correctly. But simultaneously, if you start with advanced automation use cases, there could be a large blast radius.

As a best practice, I would start your automation journey with config management and continuous remediation. And then move to move advanced use cases throughout your organization. Such as edge networking, full security ( Firewall, PAM, IDPS, etc.), and CI/CD integration.

 

  • A key point: You can’t be 100% zero trust

It is impossible to be 100% secure. You can only strive to be as secure as possible without hindering agility. It is similar to that of embarking on a zero-trust project. It is impossible to be 100% zero trust as this would involve turning off everything and removing all users from the network. We could use single-packet authorization without sending the first packet! 

 

Do not send a SPA packet

When doing so, we would keep the network and infrastructure dark without sending the first SPA packet to kick off single-packet authentication. However, lights must be on, services must be available, and users must access the services without too much interference. Users expect some downtime. Nothing can be 100% reliable all of the time.

Then you can balance velocity and stability with practices such as Chaos Engineering Kubernetes. But users don’t want to hear of a security breach.

 

zero trust journey
Diagram: Zero trust journey. What is your version of trust?

 

  • A key point. What is trust?

So the first step toward zero trust is to determine a baseline. This is not a baseline for network and security but a baseline of trust. And zero trust is different for each organization, and it boils down to the level of trust; what level does your organization consider zero trust?  What mechanism do you have in place?

There are many avenues of correlation and enforcement to reach the point where you can call yourself a zero trust environment. It may never become a zero trust environment but is limited to certain zones, applications, and segments that share a standard policy and rule base.

 

  • A key point: Choosing the vendor

Also, can zero trust security vendors be achieved with a single vendor regarding vendor selection? No one should consider implementing zero trust with one vendor solution. However, many zero trust elements can be implemented with a SASE definition known as Zero Trust SASE.

In reality, there are too many pieces to a zero-trust project, and not one vendor can be an expert on them. Once you have determined your level of trust and what you expect from a zero-trust environment, you can move to the main zero-trust element and follow the well-known zero-trust principles. Firstly, automation and orchestration. You need to automate, automate and automate.

 

zero trust reference architecture
Diagram: Zero trust reference architecture.

 

Zero Trust Security Strategy: The Components

Automation and orchestration

Zero trust is impossible to maintain without automation and orchestration. Firstly, you need to have identification of data along with access requirements. All of this must be defined along with the network components and policies. So if there is a violation, here is how we reclaim our posture without human interventionThis is where automation comes to light; it is a powerful tool in your zero trust journey and should be enabled end-to-end throughout your enterprise.

An enterprise-grade zero trust solution must work quickly with the scaling ability to improve the automated responses and reactions to internal and external threats. The automation and orchestration stage defines and manages the micro perimeters to provide the new and desired connectivity. Ansible architecture consists of Ansible Tower and the Ansible Core based on the CLI for a platform approach to automation.

 

Zero trust automation

With the matrix of identities, workloads, locations, devices, and data continuing to grow more complicated, automation provides a necessity. And you can have automation in different parts of your enterprise and at different levels. 

You can have pre-approved playbooks stored in a Git repository that can be version controlled with a Source Control Management system (SCM). Storing playbooks in a Git repository puts all playbooks under source control, so everything is better managed.

Then you can use different security playbooks already approved for different security use cases. Also, when you bring automation into the zero-trust environments, the Ansible variables can separate site-specific information from the playbooks. This will be your playbooks more flexible. You can also have a variable specific to the inventory known as the Ansible inventory variable.

 

  • Schedule zero trust playbooks under version control

For example, you can kick off a playbook to run at midnight daily to check that patches are installed. If there is a deviation from a baseline, the playbook could send notifications to relevant users and teams.

 

Ansible Tower: Delegation of Control

I use Ansible Tower, which has a built-in playbook, scheduling, and notifications for many of my security baselines. I can combine this with the “check” feature so less experienced team members can run playbook “sanity” checks and don’t have the need or full requirement to perform change tasks.

Role-based access control can be tightly controlled for even better delegation of control. You can integrate Ansible Towers with your security appliances for advanced security uses. Now we have tight integration with security and automation. Integration is essential; unified automation approaches require integration between your automation platform and your security technologies. 

 

Security integration with automation

For example, we can have playbooks that automatically collect logs for all your firewall devices. These can be automatically sent back to a log storage backend for analysts, where machine learning (ML) algorithms can perform threat hunting and examine for any deviations.

Also, I find Ansible Towers workflow templates handy and can be used to chain different automation jobs into one coherent workflow. So now we can chain different automation events together. Then you can have actions based on success, failure, or always.

 

  • A key point – Just alert and not block

You could just run a playbook to raise an alert. It does not necessarily mean you should block. I would only block something when necessary. So we are using automation to instantiate a playbook to bring those entries that have deviated from the baseline back into what you consider to be zero trust. Or we can automatically move an endpoint into a sandbox zone. So the endpoint can still operate but with less access. 

Consider that when you first implemented the network access control (NAC), you didn’t block everything immediately; you allowed it to bypass and log in for some time. From this, you can then build a baseline. I would recommend the same thing for automation and orchestration. When I block something, I recommend human approval to the workflow.

 

zero trust automation
Diagram: Zero trust automation. Adaptive access.

 

Zero Trust Least Privilege, and Adaptive Access

Enforcement points and flows

As you build out the enforcement points, it can be yes or no. Similar to the concept of the firewall’s binary rules, they are the same as some of the authentication mechanisms work. However, it would be best to monitor anomalies regarding things like flows. You must stop trusting packets as if they were people. Instead, they must eliminate the idea of trusted and untrusted networks. 

 

Identity centric design

Rather than using IP addresses to base policies on, zero trust policies are based on logical attributes. This ensures an identity-centric design around the user identity, not the IP address. This is a key component of zero trust, how you can have adaptive access for your zero trust versus a simple yes or no. Again, following a zero trust identity approach is easier said than done. 

 

  • A key point: Zero trust identity approach

With a zero trust identity approach, the identity should be based on logical attributes, for example, the multi-factor authentication (MFA), transport layer security (TLS) certificate, the application service, or the use of a logical label/tag. Tagging and labeling are good starting points as long as those tags and labels make sense when they flow across different domains. Also, consider the security controls or tagging offered by different vendors.

How do you utilize the different security controls from different vendors, and more importantly, how do you use them adjacent to one another? For example, Palo Alto utilizes an App-ID, a patented traffic classification system. Please keep in mind vendors such as Cisco have end-to-end tagging and labeling when you integrate all of their products, such as the Cisco ACI and SD-Access.

Zero trust environment and adaptive access

Adaptive access control uses policies that allow administrators to control user access to applications, files, and network features based on multiple real-time factors. Not only are there multiple factors to consider, but these are considered in real-time. What we are doing is responding to potential threats in real-time by continually monitoring user sessions for a variety of factors. We are not just looking at IP or location as an anchor for trust.

 

  • Pursue adaptive access

Anything tied to an IP address is useless. Adaptive access is more of an advanced zero trust technology, likely later in the zero trust journey. Adaptive access is not something you would initially start with.

 

 Micro segmentation and zero trust security
Diagram: Micro segmentation and zero trust security.

 

Zero Trust and Microsegmentation 

VMware introduced the concept of microsegmentation to data center networking in 2014 with VMware NSX micro-segmentation. And it has grown in usage considerably since then. It is challenging to implement and requires a lot of planning and visibility.

Zero trust and microsegmentation security enforce the security of a data center by monitoring the flows inside the data center. The main idea is that in addition to network security at the perimeter, data center security should focus on the attacks and threats from the internal network.

 

Small and protected isolated sections

With zero trust and microsegmentation security, the traffic inside the data center is differentiated into small isolated parts, i.e., micro-segments depending on the traffic type and sensitivity level. A strict micro-granular security model that ties security to individual workloads can be adopted.

Security is not simply tied to a zone; we are going to the workload level to define the security policy. By creating a logical boundary between the requesting resource and protected assets, we have minimized lateral movement elsewhere in the network, gaining east-west segmentation.

 

Zero trust and microsegmentation

It is often combined with micro perimeters. By shrinking the security perimeter of each application, we can control a user’s access to the application from anywhere and any device without relying on large segments that may or may not have intra-segment filtering.

 

  • Use case: Zero trust and microsegmentation:  5G

Micro segmentation is the alignment of multiple security tooling along with aligning capabilities with certain policies. One example of building a micro perimeter into a 5G edge is with containers. The completely new use cases and services included in 5G bring large concerns as to the security of the mobile network. Therefore, require a different approach to segmentation.

 

Micro segmentation and 5G

In a 5G network, a micro segment can be defined as a logical network portion decoupled from the physical 5G hardware. Then we can chain several micro-segments chained together to create end-to-end connectivity that maintains application isolation. So we have end-to-end security based on micro segmentation, and each micro segment can have fine-grained access controls.

 

  • A key point: Zero trust and microsegmentation: The solutions

A significant proposition for enabling zero trust is micro segmentation and micro perimeters. Their use must be clarified upfront. Essentially, their purpose is to minimize and contain the breach (when it happens). Rather than using IP addresses to base segmentation policies, the policies are based on logical constructs. Not physical attributes. 

 

Monitor flows and alert

Ideally, favor vendors with micro segmentation solutions that monitor baseline flows and alert on anomalies. These should also assess the relative level of risk/trust and alert on anomalies.  They should also continuously assess the relative level of risk/trust on the network session behavior observed. This may include unusual connectivity patterns, excessive bandwidth, excessive data transfers, and communication to URLs or IP addresses with a lower level of trust. 

 

Micro segmentation in networking

The level of complexity comes down to what you are trying to protect. This can be something on the edges, such as a 5G network point, IoT, or something central to the network. Both of which may need physical and logical separation. A good starting point for your micro segmentation journey is to build a micro segment but not in enforcement mode. So you are starting with the design but not implementing it fully. The idea is to watch and gain insights before you turn on the micro segment.

 

Containers and Zero Trust

Let us look at a practical example of applying the zero trust principles to containers. There are many layers within the container-based architecture to which you can apply zero trust. For communication with the containers, we have two layers. Nodes and services in the containers with a service mesh type of communication with a mutual TLS type of solutions. 

The container is already a two-layer. We have the nodes and services. The services communicate with an MTLS solution to control the communication between the services. Then we have the application. The application overall is where you have the ingress and egress access points. 

Docker container security

 

The OpenShift secure route

OpenShift networking SDN is similar to a routing control platform based on Open vSwitch that operates with the OVS bridge programmed with OVS rules. OVS networking has what’s known as a route construct. These routes provide access to specific services. Then, the service acts as a software load balancer to the correct pod. So we have a route construct that sits in front of the services. This abstraction layer and the OVS architecture bring many benefits to security.

 

openshift sdn
Diagram: Openshift SDN.

 

The service is the first level of exposing applications, but they are unrelated to DNS name resolution. To make servers accepted by FQDN, we use the OpenShift route resource, and the route provides the DNS. In Kubernetes’s words, we use Ingress, which exposes services to the external world. However, in Openshift, it is a best practice to use a routing set. Routes are an alternative to Ingress.

 

OpenShift security: OpenShift SDN and the secure route 

One of the advantages of the OpenShift route construct is that you can have secure routes. Secure routes provide advanced features that might not be supported by standard Kubernetes Ingress controllers, such as TLS re-encryption, TLS passthrough, and split traffic for blue-green deployments. 

Securing containerized environments is considerably different from securing the traditional monolithic application because of the inherent nature of the microservices architecture. A monolithic application has few entry points, for example, ports 80 and 443. 

Not every monolithic component is exposed to external access and must accept requests directly. Now with a secure openshift route, we can implement security where it matters most and at any point in the infrastructure. 

 

Context Based Authentication

For zero trust, it depends on what you can do with the three different types of layers. The layer you want to apply zero trust depends on the context granularity. For context-based authentication, you need to take in as much context as possible to make access decisions, and if you can’t, what are the mitigating controls?

You can’t just block. We have identity versus the traditional network-type parameter of controls. If you cannot rely on the identity and context information, you rely on and shift to network-based controls as we did initially. Network-based controls have been around for decades and create holes in the security posture. 

However, suppose you are not at a stage to implement access based on identity and context information. In that case, you may need to keep the network-based control and look deeper into your environment where you can implement zero trust to regain a good security posture. This is a perfect example of why you implement zero trust in isolated areas.

 

  • Examine zero trust layer by layer.

So it would help if you looked layer by layer for specific use cases and then at what technology components you can apply zero trust principles. So it is not a question of starting with identity or micro segmentation. The result should be a combination of both. However, identity is the critical jewel to look out for and take in as much context as possible to make access decisions and keep threats out. 

 

Take a data-centric approach. Zero trust data

Gaining visibility into the interaction between users, apps, and data across many devices and locations is imperative. This allows you to set and enforce policies irrespective of location. A data-centric approach takes location out of the picture. It comes down to “WHAT,” which is always the data. What are you trying to protect? So you should build out the architecture method over the “WHAT.”

 

Zero Trust Data Security

  • Step 1: Identify your sensitive data 

You can’t protect what you can’t see. Everything managed desperately within a hybrid network needs to be fully understood and consolidated into a single console. Secondly, once you know how things connect, how do you ensure they don’t reconnect through a broader definition of connectivity?

You can’t just rely on IP addresses anymore to implement security controls. So here, we need to identify and classify sensitive data. By defining your data, you can identify sensitive data sources to protect. Next, simplify your data classification. This will allow you to segment the network based on data sensitivity. When creating your first zero trust micro perimeter, start with a well-understood data type or system.

 

  • Step2: Zero trust and microsegmentation

Micro segmentation software that segments the network based on data sensitivity  

Secondly, you need to segment the network based on data sensitivity. Here we are defining a micro perimeter around sensitive data. Once you determine the optimal flow, identify where to place the micro perimeter.  Remember that virtual networks are designed to optimize network performance; they can’t prevent malware propagation, lateral movement, or unauthorized access to sensitive data. Like the VLAN, it was used for performance but became a security tool.

 

A final note: Firewall micro segmentation

Enforce micro perimeter with physical or virtual security controls. There are multiple ways to enforce micro perimeters. For example, we have NGFW from a vendor like Check Point, Cisco, Fortinet, or Palo Alto Networks.  If you’ve adopted a network virtualization platform, you can opt for a virtual NGFW to insert into the virtualization layer of your network. You don’t always need an NGFW to enforce network segmentation; software-based approaches to microsegmentation are also available.

 

Conclusion:

In conclusion, Zero Trust Security Strategy is an innovative and robust approach to protect valuable assets in today’s threat landscape. By rethinking traditional security models and enforcing strict access controls, organizations can significantly enhance their security posture and mitigate risks. Embracing a Zero Trust mindset is a proactive step towards safeguarding against ever-evolving cyber threats.

 

zero trust network design

Zero Trust Network Design

Zero Trust Network Design

In today's interconnected world, where data breaches and cyber threats have become commonplace, traditional perimeter defenses are no longer enough to protect sensitive information. Enter Zero Trust Network Design is a security approach that prioritizes data protection by assuming that every user and device, inside or outside the network, is a potential threat. In this blog post, we will explore the Zero Trust Network Design concept, its principles, and its benefits in securing the modern digital landscape.

Zero trust network design is a security concept that focuses on reducing the attack surface of an organization’s network. It is based on the assumption that users and systems inside a network are untrusted, and therefore, all traffic is considered untrusted and must be verified before access is granted. This contrasts traditional networks, which often rely on perimeter-based security to protect against external threats.

Key Points:

-Identity and Access Management (IAM): IAM plays a vital role in Zero Trust by ensuring that only authenticated and authorized users gain access to specific resources. Multi-factor authentication (MFA) and strong password policies are integral to this component.

-Network Segmentation: Zero Trust advocates for segmenting the network into smaller, more manageable zones. This helps contain potential breaches and restricts lateral movement within the network.

-Continuous Monitoring and Analytics: Real-time monitoring and analysis of network traffic, user behavior, and system logs are essential for detecting any anomalies or potential security breaches.

-Enhanced Security: By adopting a Zero Trust approach, organizations significantly reduce the risk of unauthorized access and lateral movement within their networks, making it harder for cyber attackers to exploit vulnerabilities.

-Improved Compliance: Zero Trust aligns with various regulatory and compliance requirements, providing organizations with a structured framework to ensure data protection and privacy.

-Greater Flexibility: Zero Trust allows organizations to embrace modern workplace practices, such as remote work and BYOD (Bring Your Own Device), without compromising security. Users can securely access resources from anywhere, anytime.

Implementing Zero Trust requires a well-defined strategy and careful planning. Here are some key steps to consider:

1. Assess Current Security Infrastructure: Conduct a thorough assessment of existing security measures, identify vulnerabilities, and evaluate the readiness for Zero Trust implementation.

2. Define Trust Boundaries: Determine the trust boundaries within the network and establish access policies accordingly. Consider factors like user roles, device types, and resource sensitivity.

3. Choose the Right Technologies: Select security solutions and tools that align with your organization's needs and objectives. These may include next-generation firewalls, secure web gateways, and identity management systems.

Highlights: Zero Trust Network Design

Never Trust, Always Verify

The core concept of zero-trust network design and segmentation is never to trust, always verify. This means that all traffic, regardless of its origin, must be verified before access is granted. This is achieved through layered security controls, including authentication, authorization, encryption, and monitoring.

firewalling device

Authentication is used to verify the identity of users and devices before allowing access to resources. Authorization is used to determine what resources a user or device is allowed to access. Encryption is used to protect data in transit and at rest. Monitoring is used to detect threats and suspicious activity.

Zero Trust Network Segmentation

Zero-trust network design, including zero-trust network segmentation, is becoming increasingly popular as organizations move away from perimeter-based security. By verifying all traffic rather than relying on perimeter-based security, organizations can reduce their attack surface and improve their overall security posture. Segmentation can work at different layers of the OSI Model.

data center network microsegmentation

With a zero-trust network segmentation approach, networks are segmented into smaller islands with specific workloads. In addition, each segment has its own ingress and egress controls to minimize the “blast radius” of unauthorized access to data.

Related: For pre-information, you may find the following helpful:

  1. DNS Security Designs
  2. Zero Trust Access
  3. SD WAN Segmentation



Zero Trust Architecture

Key Zero Trust Network Design Discussion Points:


  • Zero Trust principles.

  • TCP weak connectivitiy model.

  • Develop a Zero Trust architecture.

  • Issues of the traditional perimeter.

  • The use of micro perimeters.

Back to Basics: Zero Trust Network Design

Challenging Landscape

The drive for a zero trust networking and software defined perimeter is again gaining momentum. The bad actors are getting increasingly sophisticated, resulting in a pervasive sense of unease in traditional networking and security methods. So why are our network infrastructure and applications open to such severe security risks? This Zero Trust tutorial will recap some technological weaknesses driving the path to Zero Trust network design and Zero Trust SASE.

We give devices IP addresses to connect to the Internet and signposts three pathways. None of these techniques ensures attacks will not happen. They are like preventive medicine. However, with bad actor sophistication, we need to be more at a total immunization level to ensure that attacks cannot even touch your infrastructure by implementing a zero trust security strategy and software defined perimeter solutions.

Understanding Zero Trust Network Design:

Zero Trust Network Design is a security framework that aims to prevent and mitigate cyber-attacks by continuously verifying and validating every access request. Unlike the traditional perimeter-based security model, Zero Trust Network Design leverages several core principles to achieve a higher level of security:

1. Least Privilege: Users and devices are granted only the minimum level of access required to perform their specific tasks. This principle ensures that the potential damage is limited even if a user’s credentials are compromised.

2. Micro-Segmentation: Networks are divided into smaller, isolated segments, making it more challenging for an attacker to move laterally and gain unauthorized access to critical systems or data.

3. Continuous Authentication: Zero-trust network Design emphasizes multi-factor authentication and continuous verification of user identity and device health rather than relying solely on static credentials like usernames and passwords.

4. Network Visibility: Comprehensive monitoring and logging are crucial components of Zero Trust Network Design. Organizations can detect anomalies and potential security breaches in real-time by closely monitoring network traffic and inspecting all data packets.

Benefits of Zero Trust Network Design:

Implementing Zero Trust Network Design offers numerous benefits for organizations seeking to protect their sensitive data and mitigate cyber risks:

1. Enhanced Security: By assuming that all users and devices are untrusted, Zero Trust Network Design provides a higher security level against internal and external threats. It minimizes the risk of unauthorized access and helps organizations detect and respond to potential breaches more effectively.

2. Improved Compliance: Many industries have strict regulatory requirements for protecting sensitive data. Zero Trust Network Design addresses these compliance challenges by providing granular control over access permissions and ensuring that only authorized individuals can access critical information.

3. Reduced Attack Surface: Zero-trust network Design reduces potential attackers’ attack surface by segmenting networks and implementing strict access controls. This proactive approach makes it significantly harder for cybercriminals to move laterally within the network and gain access to sensitive data.

4. Simplified User Experience: Contrary to common misconceptions, implementing Zero Trust Network Design does not have to sacrifice user experience. With modern identity and access management solutions, users can enjoy a seamless and secure authentication process regardless of location or device.

Highlighting zero trust network segmentation

Zero-trust network segmentation is a process in which a network is divided into smaller, more secure parts. This can be done by using software firewalls, virtual LANs (VLANs), or other network security protocols. The purpose of zero-trust network segmentation, also known as microsegmentation, is to decrease a network’s attack surface and reduce the potential damage caused by a network breach. It also allows for more granular control over user access, which can help prevent unauthorized access to sensitive data.

Microsegmentation also allows for more efficient deployment of applications and more detailed monitoring and logging of network activity. By leveraging the advantages of microsegmentation, organizations can increase their network’s security and efficiency while protecting their data and resources.

Zero Trust: Changing the Approach to Security

Zero Trust is about fundamentally transforming the underlying philosophy and approach to enterprise security—shifting from outdated and demonstrably ineffective perimeter-centric methods to a dynamic, identity-centric, and policy-based system. Policies are at the heart of Zero Trust—after all, its primary architectural components are Policy Decision Points and Policy Enforcement Points. In our Zero Trust world, policies are the structures organizations create to define which identities are permitted access to resources under which circumstances.

zero trust networking
Diagram: Define Zero Trust: The standard three pathways.

Introduction to Zero Trust Network Design

The idea behind the Zero Trust model and software-defined perimeter (SDP) is a connection-based security architecture designed to stop attacks. It doesn’t expose the infrastructure and its applications. Instead, it enables you to know the authorized users by authenticating, authorizing, and validating the devices they are on before connecting to protected resources.

A Zero-Trust architecture allows you to operate while vulnerabilities, patches, and configurations are in progress. Essentially, it cloaks applications or groups of applications so they are invisible to attack.

zero trust network design
Diagram: Zero Trust Network Design. The Principles. Source cimcor.

Zero Trust principles

Zero Trust Network ZTN and SDP are a security philosophy and set of Zero Trust principles, which, taken together, represent a significant shift in how security should be approached. Foundational security elements used before Zero Trust often achieved only coarse-grained separation of users, networks, and applications.

On the other hand, Zero Trust enhances this, effectively requiring that all identities and resources be segmented from one another. Zero Trust enables fine-grained, identity-and-context-sensitive access controls driven by an automated platform. Although Zero Trust started as a narrowly focused approach of not trusting any network identities until authenticated and authorized.

Traditional security boundaries

Traditionally, security boundaries were placed at the edge of the enterprise network in a classic “castle wall and moat” approach. However, a significant issue with this was the design and how we connected. Traditional non-zero Trust security solutions have been unable to bridge the disconnect between network and application-level security. Traditionally, users (and their devices) obtained broad access to networks, and applications relied upon authentication-only access control.

Issue 1 – We Connect First and Then Authenticate

Connect first, authenticate second.

TCP/IP is a fundamentally open network protocol that facilitates easy connectivity and reliable communications between distributed computing nodes. It has served us well in enabling our hyper-connected world but—for various reasons—doesn’t include security as part of its core capabilities.

TCP has a weak security foundation

Transmission Control Protocol (TCP) has been around for decades and has a weak security foundation. When it was created, security was out of scope. TCP can detect and retransmit error packets but leave them to their default; communication packets are not encrypted, which poses security risks. In addition, TCP operates with a Connect First, Authenticate, Second operation model, which is inherently insecure. It leaves the two connecting parties wide open for an attack. When clients want to communicate and access an application, they first set up a connection.

Then only once the connect stage has been carried out successfully can the authentication stage occur. And once the authentication stage has been carried out, we can only begin to pass the data. 

zero trust network design
Diagram: Zero Trust security. The TCP model of connectivity.

From a security perspective, the most important thing to understand is that this connection occurs purely at a network layer with no identity, authentication, or authorization. The beauty of this model is that it enables anyone with a browser to easily connect to any public web server without requiring any upfront registration or permission. This is a perfect approach for a public web server but a lousy approach for a private application.

The potential for malicious activity

With this process of Connect First and Authenticate Second, we are essentially opening up the door of the network and the application without knowing who is on the other side. Unfortunately, with this model, we have no idea who the client is until they have carried out the connect phase, and once they have connected, they are already in the network. Maybe the requesting client is not trustworthy and has bad intentions. If so, once they connect, they can carry out malicious activity and potentially perform data exfiltration. 

Developing a Zero Trust Architecture

A zero-trust architecture requires endpoints to authenticate and be authorized before obtaining network access to protected servers. Then, real-time encrypted connections are created between requesting systems and application infrastructure. With a zero-trust architecture, we must establish trust between the client and the application before the client can set up the connection. Zero Trust is all about trust – never trust, always verify.

The trust is bi-directional between the client and the Zero Trust architecture ( that can take forms ) and the application to the Zero Trust architecture. It’s not a one-time check; it’s a continuous mode of operation. Once sufficient trust has been established, we move into the next stage, authentication. Once authentication has been set, we can connect the user to the application. Zero Trust access events flip the entire security model and make it more robust. 

  • We have gone from connecting first, authenticating second to authenticate first, connect second.
zero trust model
Diagram: The Zero Trust model of connectivity.

Example of a zero-trust network access

Single Pack Authorization ( SPA)

The user cannot see or know where the applications are located. SDP hides the application and creates a “dark” network by using Single Packet Authorization (SPA) for the authorization.

SPAs’ goal, also known as Single Packet Authentication, is to overcome the open and insecure nature of TCP/IP, which follows a “connect then authenticate” model.  SPA is a lightweight security protocol that validates a device or user’s identity before permitting network access to the SDP. The purpose of SPA is to allow a service to be darkened via a default-deny firewall.

SPA Use Case
Diagram: SPA Use Case. Source mrash Github.

The systems use a One-Time-Password (OTP) generated by algorithm 14 and embed the current password in the initial network packet sent from the client to the Server. The SDP specification mentions using the SPA packet after establishing a TCP connection. In contrast, the open-source implementation from the creators of SPA15 uses a UDP packet before the TCP connection.

single packet authorization

Issue 2 – Fixed perimeter approach to networking and security

Traditionally, security boundaries were placed at the edge of the enterprise network in a classic “castle wall and moat” approach. However, as technology evolved, remote workers and workloads became more common. As a result, security boundaries necessarily followed and expanded from just the corporate perimeter.

The traditional world of static domains

The traditional world of networking started with static domains. Networks were initially designed to create internal segments separated from the external world by a fixed perimeter. The classical network model divided clients and users into trusted and untrusted groups. The internal network was deemed trustworthy, whereas the external was considered hostile.

The perimeter approach to network and security has several zones. We have, for example, the Internet, DMZ, Trusted, and then Privileged. In addition, we have public and private address spaces that separate network access from here. Private addresses were deemed more secure than public ones as they were unreachable online. However, this trust assumption that all private addresses are safe is where our problems started. 

zero trust architecture
Diagram: Zero Trust security meaning. The issues with traditional networks and security.

The fixed perimeter 

The digital threat landscape is concerning. We are getting hit by external threats to your applications and networks from all over the world. They also come internally within your network, and we have insider threats within a user group and internally as insider threats across user group boundaries. These types of threats need to be addressed one by one.

One issue with the fixed perimeter approach is that it assumes trusted internal and hostile external networks. However, we must assume that the internal network is as hostile as the external one.

Over 80% of threats are from internal malware or malicious employees. The fixed perimeter approach to networking and security is still the foundation for most network and security professionals, even though a lot has changed since the design’s inception. 

zero trust network
Diagram: Traditional vs zero trust network. Source is thesslstore

We get hacked daily!

We are now at a stage where 45% of US companies have experienced a data breach. The 2022 Thales Data Threat Report found that almost half (45%) of US companies suffered a data breach in the past year. However, this could be higher due to the potential for undetected breaches.

We are getting hacked daily, and major networks with skilled staff are crashing. Unfortunately, the perimeter approach to networking has failed to provide adequate security in today’s digital world. It works to an extent by delaying an attack. However, a bad actor will eventually penetrate your guarded walls with enough patience and skill.

If a large gate and walls guard your house, you would feel safe and think you are fully protected while inside the house. However, the perimeter protecting your home may be as large and thick as possible. There is still a chance that someone can climb the walls, access your front door, and enter your property. However, if a bad actor cannot even see your house, they cannot take the next step and try to breach your security.

Issue 3 – Dissolved perimeter caused by the changing environment

The environment has changed with the introduction of the cloud, advanced BYOD, machine-to-machine connections, the rise in remote access, and phishing attacks. We have many internal devices and a variety of users, such as on-site contractors that need to access network resources.

There is also a trend for corporate devices to move to the cloud, collocated facilities, and off-site to customer and partner locations. In addition, it is becoming more diversified with hybrid architectures.

zero trust network design
Diagram: Zero Trust concept.

These changes are causing major security problems with the fixed perimeter approach to networking and security. For example, with the cloud, the internal perimeter is stretched to the cloud, but traditional security mechanisms are still being used. But it is an entirely new paradigm. Also, some abundant remote workers work from various devices and places.

Again, traditional security mechanisms are still being used. As our environment evolves, security tools and architectures must evolve. Let’s face it: the network perimeter has dissolved as your remote users, things, services, applications, and data are everywhere. In addition, as the world moves to the cloud, mobile, and the IoT, the ability to control and secure everything in the network is no longer available.

Phishing attacks are on the rise.

We have witnessed increased phishing attacks that can result in a bad actor landing on your local area network (LAN). Phishing is a type of social engineering where an attacker sends a fraudulent message designed to trick a person into revealing sensitive information to the attacker or to deploy malicious software on the victim’s infrastructure, like ransomware. The term “phishing” was first used in 1994 when a group of teens worked to obtain credit card numbers from unsuspecting users on AOL manually.

Phishing attacks
Diagram: Phishing attacks. Source is helpnetsecurity

Hackers are inventing new ways.

By 1995, they had created a program called AOHell to automate their work. Since then, hackers have continued to invent new ways to gather details from anyone connected to the internet. These actors have created several programs and types of malicious software that are still used today.

Recently, I was a victim of a phishing email. Clicking and downloading the file is very easy if you are not educated about phishing attacks. In my case, the particular file was a .wav file. It looked safe, but it was not.

Issue 4 – Broad-level access

So, you may have heard of broad-level access and lateral movements. Remember, with traditional network and security mechanisms, when a bad actor lands on a particular segment, i.e., a VLAN, known as zone-based networking, they can see everything on that segment. So this gives them broad-level access. But, generally speaking, when you are on a VLAN, you can see everything in that VLAN, and VLAN-to-VLAN communication is not the hardest thing to do, resulting in lateral movements.

The issue of lateral movements

Lateral movement is the technique attackers use to progress through the organizational network after gaining initial access. Adversaries use lateral movement to identify target assets and sensitive data for their attack. Lateral movement is the tenth step in the MITRE Att&ck framework. It is the set of techniques attackers use to move in the network while gaining access to credentials without being detected.

No intra-VLAN filtering

This is made possible as, traditionally, a security device does not filter this low down on the network, i.e., inside of the VLAN, known as intra-VLAN filtering. A phishing email can easily lead the bad actor to the LAN with broad-level access and the capability to move laterally throughout the network. 

For example, a bad actor can initially access an unpatched central file-sharing server; they move laterally between segments to the web developers’ machines and use a keylogger to get the credentials to access critical information on the all-important database servers.

They can then carry out data exfiltration with DNS or even a social media account like Twitter. However, firewalls generally do not check DNS as a file transfer mechanism, so data exfiltration using DNS will often go unnoticed. 

zero trust network design
Diagram: Zero trust application access. One of the many security threats is lateral movements.

Issue 5 – The challenges with traditional firewalls

The limited world of 5-tuple

Traditional firewalls typically control access to network resources based on source IP addresses. This creates the fundamental challenge of securing admission. Namely, we need to solve the user access problem, but we only have the tools to control access based on IP addresses.

As a result, you have to group users, some of whom may work in different departments and roles, to access the same service and with the same IP addresses. The firewall rules are also static and don’t change dynamically based on levels of trust on a given device. They provide only network information.

Maybe the user moves to a more risky location, such as an Internet cafe, its local Firewall, or antivirus software that has been turned off by malware or even by accident. Unfortunately, a traditional firewall cannot detect this and live in the little world of the 5-tuple.  Traditional firewalls can only express static rule sets and not communicate or enforce rules based on identity information.

TCP 5 Tuple
Diagram: TCP 5 Tuple. Source is packet-foo.

Issue 6 – A Cloud-focused environment

Upon examining the cloud, let’s compare a public parking space. A public cloud is where you can put your car compared to your vehicle in your parking garage. In a public parking space, we have multiple tenants who can take your area, but we don’t know what they can do to your car.

Today, we are very cloud-focused, but when moving applications to the cloud, we need to be very security-focused. However, the cloud environment is less mature in providing the traditional security control we use in our legacy environment. 

So, when putting applications in the cloud, you shouldn’t leave security to its default. Why?? Firstly, we operate in a shared model where the tenant after you can steal your encryption keys or data. There have been a lot of cloud breaches. We have firewalls with static rulesets, authentication, and key management issues in cloud protection.

Control point change

One of the biggest problems is that the perimeter has moved when you move to a cloud-based application. Servers are no longer under your control. Mobile and tablets exacerbate the problem as they can be located everywhere. So, trying to control the perimeter is very difficult. More importantly, firewalls only have access to and control network information and should have more content.

Defining this perimeter is what ZTNA architecture and software-defined perimeter are doing. Cloud users now manage firewalls by moving their applications to the cloud, not the I.T. teams within the cloud providers.

So when moving applications to the cloud, even though cloud providers provide security tools, the cloud consumer has to integrate security to have more visibility than they have today.

zero trust cloud
Diagram: ZTNA. Zero Trust cloud security.

Before, we had clear network demarcation points set by a central physical firewall creating inside and outside trust zones. Anything outside was considered hostile, and anything on the inside was deemed trusted.

1. Connection-centric model

The Zero Trust model flips this around and considers everything untrusted. To do this, there are no longer pre-defined fixed network demarcation points. Instead, the network perimeter initially set in stone is now fluid and software-based.

Zero Trust is connection-centric, not network-centric. Each user on a specific device connected to the network gets an individualized connection to a particular service hidden by the perimeter.

Instead of having one perimeter every user uses, SDP creates many small perimeters purposely built for users and applications. These are known as micro perimeters. Clients are cryptographically signed into these microperimeters.

security micro perimeters
Diagram: Security micro perimeters.

2. Micro perimeters: Zero trust network segmentation

The micro perimeter is based on user and device context and can dynamically adjust to environmental changes. So, as a user moves to different locations or devices, the Zero Trust architecture can detect this and set the appropriate security controls based on the new context.

The data center is no longer the center of the universe. Instead, the user on specific devices, along with their service requests, is the new center of the universe.

Zero Trust does this by decoupling the user and device from the network. The data plane is separated from the network to remove the user from the control plane. The control plane is where the authentication happens first.

Then, the data plane, the client-to-application connection, transfers the data. Therefore, the users don’t need to be on the network to gain application access. As a result, they have the least privilege and no broad-level access.

  • Concept: Zero trust network segmentation

Zero-trust network segmentation is gaining traction in cybersecurity due to its ability to provide increased protection to an organization’s network. This method of securing networks is based on the concept of “never trust, always verify,” meaning that all traffic must be authenticated and authorized before it can access the network.

This is accomplished by segmenting the network into multiple isolated zones accessible only through specific access points, which are carefully monitored and controlled.

Network segmentation is a critical component of a zero-trust network design. By dividing the network into smaller, isolated units, it is easier to monitor and control access to the network. Additionally, segmentation makes it harder for attackers to move laterally across the network, reducing the chance of a successful attack.

Zero-trust network design segmentation is essential to any organization’s cybersecurity strategy. By utilizing segmentation, authentication, and monitoring systems, organizations can ensure their networks are secure and their data is protected.

A final issue 7 – The I.P. address conundrum

Everything today relies on I.P. addresses for trust, but there is a problem: I.P. addresses lack user knowledge to assign and validate the device’s trust. There is no way for an I.P. address to do this. I.P. addresses provide connectivity but do not get involved in validating the trust of the endpoint or the user.

Also, I.P. addresses should not be used as an anchor for network locations as they are today because when a user moves from one place to another, the I.P. address changes. 

security flaws
Diagram: Three main network security flaws.

Can’t have security related to an I.P. address.

But what about the security policy assigned to the old IP addresses? What happens with your change I.P.s? Anything tied to I.P. is ridiculous, as we don’t have a good hook to hang things on for security policy enforcement. There are several facets to policy. For example, the user access policy touches on authorization, the network access policy touches on what to connect to, and user account policies touch on authentication.

With either one, there is no policy visibility with I.P. addresses. This is also a significant problem for traditional firewalling, which displays static configurations; for example, a stationary design may state that this particular source can reach this destination using this port number. 

Security-related issues to I.P.

  1. This has no meaning. There is no indication of why that rule exists and under what conditions a packet should be allowed from one source to another.
  2. No contextual information is taken into consideration. When creating a robust security posture, we must consider more than ports and IP addresses.

For a robust security posture, you need complete visibility into the network to see who, what, when, and how they connect with the device. Unfortunately, today’s Firewall is static and only contains information about the network.

On the other hand, Zero Trust enables a dynamic firewall with the user and device context to open a firewall for a single secure connection. The Firewall remains closed at all other times, creating a ‘black cloud’ stance regardless of whether the connections are made to the cloud or on-premise. 

The rise of the next-generation firewall?

Next-generation firewalls are more advanced than traditional firewalls. They use the information in layers 5 through 7 (session layer, presentation layer, and application layer) to perform additional functions. They can provide advanced features such as intrusion detection, prevention, and virtual private networks.

Today, most enterprise firewalls are “next generation” and typically include IDS/IPS, traffic analysis and malware detection for threat detection, URL filtering, and some degree of application awareness/control.

Like the NAC market segment, vendors in this area began a journey to identity-centric security around the same time Zero Trust ideas began percolating through the industry. Today, many NGFW vendors offer Zero Trust capabilities, but many operate with the perimeter security model.

Still, IP-based security systems

NGFWs are still IP-based systems offering limited identity and application-centric capabilities. In addition, they are static firewalls. Most do not employ zero-trust segmentation, and they often mandate traditional perimeter-centric network architectures with site-to-site connections and don’t offer flexible network segmentation capabilities. Similar to conventional firewalls, their access policy models are typically coarse-grained, providing users with broader network access than what is strictly necessary.

Diagram: Cloud Application Firewall.

Conclusion:

Zero Trust Network Design represents a paradigm shift in network security, recognizing that traditional perimeter defenses are no longer sufficient to protect against the evolving threat landscape. By implementing this approach, organizations can significantly enhance their security posture, minimize the risk of data breaches, and ensure compliance with regulatory requirements. As the digital landscape evolves, Zero Trust Network Design offers a robust framework for safeguarding sensitive information in an increasingly interconnected world.

 

Summary: Zero Trust Network Design

Traditional network security measures are no longer sufficient in today’s digital landscape, where cyber threats are becoming increasingly sophisticated. Enter zero trust network design, a revolutionary approach that challenges the traditional perimeter-based security model. In this blog post, we will delve into the concept of zero-trust network design, its key principles, benefits, and implementation strategies.

Understanding Zero Trust Network Design

Zero-trust network design is a security framework that operates on the principle of “never trust, always verify.” Unlike traditional perimeter-based security, which assumes trust within the network, zero-trust treats every user, device, or application as potentially malicious. This approach is based on the belief that trust should not be automatically granted but continuously verified, regardless of location or network access method.

Key Principles of Zero Trust

Certain key principles must be followed to implement zero trust network design effectively. These principles include:

1. Least Privilege: Users and devices are granted the minimum level of access required to perform their tasks, reducing the risk of unauthorized access or lateral movement within the network.

2. Microsegmentation: The network is divided into smaller segments or zones, allowing granular control over network traffic and limiting the impact of potential breaches or lateral movement.

3. Continuous Authentication: Authentication and authorization are not just one-time events but are verified throughout a user’s session, preventing unauthorized access even after initial login.

Benefits of Zero Trust Network Design

Implementing a zero-trust network design offers several significant benefits for organizations:

1. Enhanced Security: By adopting a zero-trust approach, organizations can significantly reduce the attack surface and mitigate the risk of data breaches or unauthorized access.

2. Improved Compliance: Zero trust network design aligns with many regulatory requirements, helping organizations meet compliance standards more effectively.

3. Greater Flexibility: Zero trust allows organizations to embrace modern workplace trends, such as remote work and cloud-based applications, without compromising security.

Implementing Zero Trust

Implementing a trust network design requires careful planning and a structured approach. Some key steps to consider are:

1. Network Assessment: Conduct a thorough assessment of the existing network infrastructure, identifying potential vulnerabilities or areas that require improvement.

2. Policy Development: Define comprehensive security policies that align with zero trust principles, including access control, authentication mechanisms, and user/device monitoring.

3. Technology Adoption: Implement appropriate technologies and tools that support zero-trust network design, such as network segmentation solutions, multifactor authentication, and continuous monitoring systems.

Conclusion:

Zero trust network design represents a paradigm shift in network security, challenging traditional notions of trust and adopting a more proactive and layered approach. By implementing the fundamental principles of zero trust, organizations can significantly enhance their security posture, reduce the risk of data breaches, and adapt to evolving threat landscapes. Embracing the principles of least privilege, microsegmentation, and continuous authentication, organizations can revolutionize their network security and stay one step ahead of cyber threats.

Zero trust security for full protection and data safety outline diagram. Labeled educational scheme with network, identity and device verification for safe information protection vector illustration.

Remote Browser Isolation

Remote Browser Isolation

In today's digital landscape, where cyber threats continue to evolve at an alarming rate, businesses and individuals are constantly seeking innovative solutions to safeguard their sensitive information. One such solution that has gained significant attention is Remote Browser Isolation (RBI). In this blog post, we will explore RBI, how it works, and its role in enhancing security in the digital era.

Remote Browser Isolation, as the name suggests, is a technology that isolates web browsing activity from the user's local device. Instead of directly accessing websites and executing code on the user's computer or mobile device, RBI redirects browsing activity to a remote server, where the web page is rendered and interactions are processed. This isolation prevents any malicious code or potential threats from reaching the user's device, effectively minimizing the risk of a cyberattack.

Remote browser isolation offers several compelling benefits for organizations. Firstly, it significantly reduces the surface area for cyberattacks, as potential threats are contained within a remote environment. Additionally, it eliminates the need for frequent patching and software updates on endpoint devices, reducing the burden on IT teams. This section will outline these advantages in detail, showcasing how remote browser isolation can enhance cybersecurity posture.

Implementing remote browser isolation requires careful planning and consideration. This section will explore different approaches to implementation, including on-premises solutions and cloud-based services. It will also discuss the integration challenges that organizations might face and provide insights into best practices for successful deployment.

While remote browser isolation offers immense security benefits, it is crucial to address potential challenges that organizations may encounter during implementation. This section will highlight common obstacles such as compatibility issues, user experience concerns, and cost considerations. By proactively addressing these challenges, organizations can ensure a seamless and effective transition to remote browser isolation.

Highlights: Remote Browser Isolation

Challenging Landscape

Our digital environment has been transformed significantly. Unlike earlier times, we now have different devices, access methods, and types of users accessing applications from various locations. This makes it more challenging to know which communications can be trusted. The perimeter-based approach to security can no longer be limited to just the enterprise’s physical location.

A Fluid Perimeter

In this modern world, the perimeter is becoming increasingly difficult to enforce as organizations adopt mobile and cloud technologies. Hence, the need for Remote Browser Isolation (RBI) has become integral to the SASE definition. For example, Cisco Umbrella products have several Zero Trust SASE components, such as the CASB tools, and now RBI is integrated into one solution.

network security components

It’s Just a matter of time

Under these circumstances, the perimeter is more likely to be breached; it’s just a matter of time. A bad actor would then be relatively free to move laterally, potentially accessing the privileged intranet and corporate data on-premises and in the cloud. Therefore, we must assume that users and resources on internal networks are as untrustworthy as those on the public internet and design enterprise application security with this in mind. 

Related: Before you proceed, you may find the following posts helpful for pre-information:

  1. Cisco Umbrella CASB
  2. Ericom Shield
  3. SDP Network
  4. Zero Trust Access

 



Remote Browser Isolation (RBI)

Key Remote Browser Isolation Discussion points:


  • The perimeter approach can no longer be trusted. 

  • Software Defined Perimeter and security checking.

  • Mico egmentation.

  • Introducing RBI and its capabilities.

  • The RBI components.

 

Back to basics with remote browser isolation

Remote browser isolation (RBI), also known as web isolation or browser isolation, is a web security solution developed to protect users from Internet-borne threats. So, we have on-premise isolation and remote browser isolation.

On-premise browser isolation functions similarly to remote browser isolation. But instead of taking place on a remote server, which could be in the cloud, the browsing occurs on a server inside the organization’s private network, which could be at the DMZ. So why would you choose on-premise isolation as opposed to remote browser isolation?

Firstly, performance. On-premise isolation can reduce latency compared to some types of remote browser isolation that need to be done in a remote location.

The Concept of RBI

The RBI concept is based on the principle of “trust nothing, verify everything.” By isolating web browsing activity, RBI ensures that any potentially harmful elements, such as malicious scripts, malware, or phishing attempts, cannot reach the user’s device. This approach significantly reduces the attack surface and provides an added layer of protection against threats that may exploit vulnerabilities in the user’s local environment.

So, how does Remote Browser Isolation work in practice? When a user initiates a web browsing session, the RBI solution establishes a secure connection to a remote server instead of directly accessing the website. The remote server acts as a virtual browser, rendering the web page, executing potentially dangerous code, and processing user interactions.

Only the harmless visual representation of the webpage is transmitted back to the user’s device, ensuring that any potential threats are confined to the isolated environment.

Key RBI Advantages

One of the critical advantages of RBI is its ability to protect against known and unknown threats. Since the browsing activity is isolated from the user’s device, even if a website contains an undiscovered vulnerability or a zero-day exploit, the user’s device remains protected. This is particularly valuable in today’s dynamic threat landscape, where new vulnerabilities and exploits are constantly discovered.

Furthermore, RBI offers a seamless user experience, allowing users to interact with web pages just as they would with a traditional browser. Whether it’s submitting forms, watching videos, or accessing web applications, users can perform their desired actions without compromising security. From an IT perspective, RBI also simplifies security management, as it enables centralized control and monitoring of browsing activity, making it easier to identify and address potential threats.

As organizations increasingly adopt cloud-based infrastructure and embrace remote work, Remote Browser Isolation has emerged as a critical security solution. By isolating web browsing activity, businesses can protect their sensitive data, intellectual property, and customer information from cyber threats. RBI significantly reduces the risk of successful attacks, enhances overall security posture, and provides peace of mind to organizations and individuals.

What within the perimeter makes us assume it can no longer be trusted?

Security becomes less and less tenable once there are many categories of users, device types, and locations. Users are diverse, so it is impossible, for example, to slot all vendors into one user segment with uniform permissions.

As a result, access to applications should be based on contextual parameters such as who and where the user is. Sessions should be continuously assessed to ensure they’re legit. 

We need to find ways to decouple security from the physical network and, more importantly, application access from the network. In short, we need a new approach to providing access to the cloud, network, and device-agnostic applications. This is where Software-Defined Perimeter (SDP) comes into the picture.

What is a Software-Defined Perimeter (SDP)?

SDP VPN complements zero trust, which considers internal and external networks and actors untrusted. The network topology is divorced from the trust. There is no concept of inside or outside of the network.

This may result in users not automatically being granted broad access to resources simply because they are inside the perimeter. Primarily, security pros must focus on solutions where they can set and enforce discrete access policies and protections for those requesting to use an application.

SDP lays the foundation and secures the access architecture, which enables an authenticated and trusted connection between the entity and the application. Unlike security based solely on IP, SDP does not grant access to network resources based on a user’s location.

Access policies are based on device, location, state, associated user information, and other contextual elements. Applications are considered abstract, so whether they run on-premise or in the cloud is irrelevant to the security policy.

Periodic Security Checking

Clients and their interactions are periodically checked to comply with the security policy. Periodic security checking protects against additional actions or requests not allowed while the connection is open. For example, let’s say you have a connection open to a financial application, and users access the recording software to record the session.

In this case, the SDP management platform can check whether the software has been started. If so, it employs protective mechanisms to ensure smooth and secure operation.

Microsegmentation

Front-end authentication and periodic checking are one part of the picture. However, we need to go a layer deeper to secure the application’s front door and the numerous doors within, which can potentially create additional access paths. Primarily, this is the job of microsegmentation. Microsegmentation can be performed at all layers of the OSI Model.

data center network microsegmentation

It’s not sufficient to provide network access. We must enable granular application access for dynamic segments of 1. In this scenario, a microsegment is created for every request. Microsegmentation creates the minimal accessible network required to complete specific tasks smoothly and securely. This is accomplished by subdividing more extensive networks into small, secure, and flexible micro-perimeters.

Introducing Remote Browser Isolation (RBI)

SDP provides mechanisms to prevent lateral movement once users are inside the network. However, we must also address how external resources on the internet and public clouds can be accessed while protecting end-users, their devices, and the networks they connect. This is where remote browser isolation (RBI) and technologies such as Single Packet Authorization come into the picture.

What is Remote Browser Isolation? Initially, we started with browser isolation, which protects the user from external sessions by isolating the interaction. Essentially, it generates complete browsers within a virtual machine on the endpoint, providing a proactive approach to isolate users’ sessions from, for example, malicious websites, emails, and links. However, these solutions do not reliably isolate the web content from the end-user’s device on the network.

Remote browser isolation takes local browser isolation to the next level by enabling the rendering process to occur remotely from the user’s device in the cloud. Because only a clean data stream touches the endpoint, users can securely access untrusted websites from within the perimeter of the protected area.

 

Remote Browser Isolation
Diagram: Remote Brower Isolation.

SDP, along with Remote Browser Isolation (RBI)

Remote browser isolation complements the SDP approach in many essential ways. When you access a corporate asset, you operate within the SDP. But when you need to access external assets, RBI is required to keep you safe.

Zero trust and SDP are about authentication, authorization, and accounting (AAA) for internal resources, but secure ways must exist to access external resources. For this, RBI secures browsing elsewhere on your behalf.

No SDP solution can be complete without including rules to secure external connectivity. RBI takes zero trust to the next level by securing the internet browsing perspective. If access is to an internal corporate asset, we create a dynamic tunnel of one individualized connection. For external access, RBI transfers information without full, risky connectivity.

This is particularly crucial when it comes to email attacks like phishing. Malicious actors use social engineering tactics to convince recipients to trust them enough to click on embedded links.

Quality RBI solutions protect users by “knowing” when to allow user access while preventing malware from entering endpoints, entirely blocking malicious sites, or protecting users from entering confidential credentials by enabling read-only access.

The RBI Components

To understand how RBI works, let’s look under the hood of Ericom Shield. With RBI, for every tab a user opens on their device, the solution spins up a virtual browser in its dedicated Linux container in a remote cloud location. For additional information on containers, in particular Docker Container Security.

For example, if the user is actively browsing 19 open tabs on his Chrome browser, each will have a corresponding browser in its remote container. This sounds like it takes a lot of computing power, but enterprise-class  RBI solutions do a lot of optimizations to ensure that it is not eating up too much of the endpoint resources.

If a tab is unused for some time, the associated container is automatically terminated and destroyed. This frees up computing resources and also eliminates the possibility of persistence.

As a result, whatever malware may have resided on the external site being browsed is destroyed and cannot accidentally infect the endpoint, server, or cloud location. When the user shifts back to the tab, he is reconnected in a fraction of a second to the exact location but with a new container, creating a secure enclave for internet browsing. 

Website rendering

Website rendering is carried out in real time from the remote browser. The web page is translated into a media stream, which then gets streamed back to the end-user via HTML5 protocol. In reality, the browsing experience is made out of images. When you look at the source code on the endpoint browser, you will find that the HTML code consists solely of a block of Ericom-generated code. This block manages to send and receive images via the media stream.

Whether the user is accessing the Wall Street Journal or YouTube, they will always get the same source code from Ericom Shield. This is ample proof that no local download, drive-by download, or any other contact that may try to hook up into your endpoint will ever get there, as it does not come into contact with the endpoint. It runs only remotely in a container outside the local LAN. The browser farm does all the heavy — and dangerous — lifting via container-bound browsers that read and execute the user’s uniform resource locator (URL) requests. 

Closing Points: Remote Browser Isolation

SDP vendors have figured out device user authentication and how to secure sessions continuously. However, vendors are now looking for a way to secure the tunnel through to external resource access. 

If you use your desktop to access a cloud application, your session can be hacked or compromised. But with RBI, you can maintain one-to-one secure tunneling. With a dedicated container for each specific app, you are assured of an end-to-end zero-trust environment. 

RBI, based on hardened containers and with a rigorous process to eliminate malware through limited persistence, forms a critical component of the SDP story. Its power is that it stops known and unknown threats, making it a natural evolution from the zero-trust perspective.

In conclusion, remote browser isolation is crucial to enhancing security in the digital era. By isolating web browsing activity from the user’s device, RBI provides an effective defense against a wide range of cyber threats. With its ability to protect against known and unknown threats, RBI offers a proactive approach to cybersecurity, ensuring that organizations and individuals can safely navigate the digital landscape. Remote Browser Isolation will remain vital to a comprehensive security strategy as the threat landscape evolves.

Summary: Remote Browser Isolation

In today’s digital landscape, where cyber threats loom large, ensuring robust web security has become a paramount concern for individuals and organizations. One innovative solution that has gained significant attention is remote browser isolation. In this blog post, we explored the concept of remote browser isolation, its benefits, and its potential to revolutionize web security.

Understanding Remote Browser Isolation

Remote browser isolation is a cutting-edge technology that separates the web browsing activity from the local device, creating a secure environment for users to access the internet. By executing web browsing sessions in isolated containers, any potential threats or malicious code are contained within the remote environment, preventing them from reaching the user’s device.

Enhancing Protection Against Web-Based Attacks

One key advantage of remote browser isolation is its ability to protect users against web-based attacks, such as drive-by downloads, malvertising, and phishing attempts. By isolating the browsing session in a remote environment, even if a user unknowingly encounters a malicious website or clicks on a harmful link, the threat is confined to the isolated container, shielding the user’s device and network from harm.

Mitigating Zero-Day Vulnerabilities

Zero-day vulnerabilities pose a significant challenge to traditional web security measures. These vulnerabilities refer to software flaws that cybercriminals exploit before a patch or fix is available. The risk of zero-day exploits can be significantly mitigated with remote browser isolation. Since the browsing session occurs in an isolated environment, even if a website contains an unknown or unpatched vulnerability, it remains isolated from the user’s device, rendering the attack ineffective.

Streamlining BYOD Policies

Bring Your Device (BYOD) policies have become prevalent in many organizations, allowing employees to use their devices for work. However, this brings inherent security risks, as personal devices may lack robust security measures. By implementing remote browser isolation, organizations can ensure that employees can securely access web-based applications and content without compromising the security of their devices or the corporate network.

Conclusion:

Remote browser isolation holds immense potential to strengthen web security by providing an innovative approach to protecting users against web-based threats. By isolating browsing sessions in secure containers, it mitigates the risks associated with malicious websites, zero-day vulnerabilities, and potential exploits. As the digital landscape continues to evolve, remote browser isolation emerges as a powerful solution to safeguard our online experiences and protect against ever-evolving cyber threats.

Cyber security threat. Computer screen with programming code. Internet and network security. Stealing private information. Using technology to steal password and private data. Cyber attack crime

Software defined perimeter (SDP) A disruptive technology

 

software-defined perimeter

 

Software Defined Perimeter

In today’s digital landscape, where the security of sensitive data is paramount, traditional security measures are no longer sufficient. The ever-evolving threat landscape demands a more proactive and robust approach to protecting valuable assets. Enter the Software Defined Perimeter (SDP), a revolutionary concept changing how organizations secure their networks. In this blog post, we will delve into the world of SDP and explore its benefits, implementation, and prospects.

Software Defined Perimeter, also known as a Zero Trust Network, is a security framework that provides secure access to applications and resources, regardless of the user’s location or network. Unlike traditional perimeter-based security models, which rely on firewalls and VPNs, SDP takes a more dynamic and adaptive approach.

 

Highlights: Software Defined Perimeter

  • A Disruptive Technology

There has been tremendous growth in the adoption of software defined perimeter solutions and the zero trust network design over the last few years. This has resulted in SDP VPN becoming a disruptive technology, especially when replacing or working with the existing virtual private network. Why? Because the steps that software-defined perimeter proposes are needed.

  • Challenge With Todays Security

Today’s network security architectures, tools, and platforms are lacking in many ways when trying to combat current security threats. From a bird’s eye view, the stages of zero trust software defined perimeter are relatively simple. SDP requires that endpoints, both internal and external to an organization, must authenticate and then be authorized before being granted network access. Once these steps occur, two-way encrypted connections between the requesting entity and the intended protected resource are created.

 

For pre-information, you may find the following post helpful:

  1. SDP Network
  2. Software Defined Internet Exchange
  3. SDP VPN

 



Software-Defined Perimeter.

Key Software Defined Perimeter Discussion points:


  • The issues with traditional security and networking constructs.

  • Identity-driven access.

  • Discussing Cloud Security Alliance (CSA).

  • Highlighting Software Defined Perimeter capabilities.

  • Dynamic Tunnelling. 

 

Back to basics with Software Defined Perimeter

A software-defined perimeter constructs a virtual boundary around company assets. This separates it from access-based controls restricting user privileges but allowing broad network access. The three fundamental pillars on which a software-defined perimeter is built are Zero Trust:

It leverages micro-segmentation to apply the principle of the least privilege to the network. It ultimately reduces the attack surface. Identity-centric: It’s designed around the user identity and additional contextual parameters, not the IP address.

 

Benefits of Software-Defined Perimeter:

1. Enhanced Security: SDP employs a Zero Trust approach, ensuring that only authorized users and devices can access the network. This eliminates the risk of unauthorized access and reduces the attack surface.

2. Scalability: SDP allows organizations to scale their networks without compromising security. It seamlessly accommodates new users, devices, and applications, making it ideal for expanding businesses.

3. Simplified Management: With SDP, managing access controls becomes more straightforward. IT administrators can easily assign and revoke permissions, reducing the administrative burden.

4. Improved Performance: By eliminating the need for backhauling traffic through a central gateway, SDP reduces latency and improves network performance, enhancing the overall user experience.

 

Implementing Software-Defined Perimeter:

Implementing SDP requires a systematic approach and careful consideration of various factors. Here are the key steps involved in deploying SDP:

1. Identify Critical Assets: Determine the applications and resources that require enhanced security measures. This could include sensitive data, intellectual property, or customer information.

2. Define Access Policies: Establish granular access policies based on user roles, device types, and locations. This ensures that only authorized individuals can access specific resources.

3. Implement Authentication Mechanisms: Incorporate strong authentication measures such as multi-factor authentication (MFA) or biometric authentication to verify user identities.

4. Implement Encryption: Encrypt all data in transit to prevent eavesdropping or unauthorized interception.

5. Continuous Monitoring: Regularly monitor network activity and analyze logs to identify suspicious behavior or anomalies.

 

The Software-Defined Perimeter Proposition

Security policy flexibility is offered with fine-grained access control that dynamically creates and removes inbound and outbound access rules. Therefore, a software-defined perimeter minimizes the attack surface for bad actors to play with—small attack surface results in a small blast radius. So less damage can occur.

A VLAN has a relatively large attack surface, mainly because the VLAN contains different services. SDP eliminates the broad network access that VLANs exhibit. SDP has a separate data and control plane. A control plane sets up the controls necessary for data to pass from one endpoint to another. Separating the control from the data plane renders protected assets “black,” thereby blocking network-based attacks. You cannot attack what you cannot see.

 

The IP Address; Is Not a Valid Hook

We should know that IP addresses are lost in today’s hybrid environment. SDP provides a connection-based security architecture instead of an IP-based one. This allows for many things. For one, security policies follow the user regardless of location. Let’s say you are doing forensics on an event 12 months ago for a specific IP.

However, that IP address is a component in a test DevOps environment. Do you care? Anything tied to IP is ridiculous, as we don’t have the right hook to hang things on for security policy enforcement.

 

Software-defined perimeter; Identity-driven access

Identity-driven network access control is more precise in measuring the actual security posture of the endpoint. Access policies tied to IP addresses cannot offer identity-focused security. SDP enables the control of all connections based on pre-vetting who can connect and to what services.

If you do not meet this level of trust, you can’t, for example, access the database server, but you can access public-facing documents. Users are granted access only to authorized assets preventing lateral movements that will probably go unnoticed when traditional security mechanisms are in place.

 

 

Information and infrastructure hiding

SDP does a great job of information and infrastructure hiding. The SDP architectural components ( the SDP controller and gateways ) are “dark, ” providing resilience against high and low-volume DDoS attacks. A low bandwidth DDoS attack may often bypass traditional DDoS security controls. However, the SDP components do not respond to connections until the requesting clients are authenticated and authorized, allowing only good packets through.

A suitable security protocol that can be used here is single packet authorization (SPA). Single Packet Authorization, or Single Packet Authentication, gives the SDP components a default “deny-all” security posture.

The “default deny” can be achieved because if an accepting host receives any packet other than a valid SPA packet, it assumes it is malicious. The packet will get dropped, and a notification will not get sent back to the requesting host. This stops reconnaissance at the door by silently detecting and dropping bad packets.

 

Sniffing a SPA packet

However, SPA can be subject to Man-In-The-Middle (MITM) attacks. If a bad actor can sniff a SPA packet, they can establish the TCP connection to the controller or AH client. But there is another level of defense in that the bad actor cannot complete the mutually encrypted connection (mTLS) without the client’s certificate.

SDP brings in the concept of mutually encrypted connections, also known as two-way encryption. The usual configuration for TLS is that the client authenticates the server, but TLS ensures that both parties are authenticated. Only validated devices and users can become authorized members of the SDP architecture.

We should also remember that the SPA is not a security feature that can be implemented to protect all. It has its benefits but does not take over from existing security technologies. SPA should work alongside them. The main reason for its introduction to the SDP world is to overcome the problems with TCP. TCP connects and then authenticates. With SPA, you authenticate first and only then connect.

 

SPA Use Case
Diagram: SPA Use Case. Source mrash Github.

 

The World of TCP & SDP

When clients want to access an application with TCP, they must first set up a connection. There needs to be direct connectivity between the client and the applications. So this requires the application to be reachable and is carried out with IP addresses on each end. Then once the connect stage is done, there is an authentication phase.

Once the authentication stage is done, we can pass data. Therefore, we have the connect, then authenticate, and data pass a stage. SDP reverses this.

zero trust security
Diagram: Zero trust security. The opposite of the TCP: Connect Firsts and then Authenticate

 

 

The center of the software-defined perimeter is trust.

In Software-Defined Perimeter, we must establish trust between the client and the application before the client can set up the connection. The trust is bi-directional between the client and the SDP service and the application to the SDP service. Once trust has been established, we move into the next stage, authentication.

Once this has been established, we can connect the user to the application. This flips the entire security model and makes it more robust. The user has no idea of where the applications are located. The protected assets are hidden behind the SDP service, which in most cases is the SDP gateway, or some call this a connector.

 

  • Cloud Security Alliance (CSA) SDP
    • With the Cloud Security Alliance SDP architecture, we have several components:

Firstly, the IH & AH: are the clients initiating hosts (IH) and the service accepting hosts (AH). The IH devices can be any endpoint device that can run the SDP software, including user-facing laptops and smartphones. Many SDP vendors have remote browser isolation-based solutions without SDP client software. The IH, as you might expect, initiates the connections.

With an SDP browser-based solution, the user uses a web browser to access the applications and only works with applications that can speak across a browser. So it doesn’t give you the full range of TCP and UDP ports, but you can do many things that speak natively across HTML5.

Most browser-based solutions don’t give you the additional security posture checks of assessing the end user device than an endpoint with the client installed.

 

Software-Defined Perimeter: Browser-based solution

The AHs accept connections from the IHS and provide a set of services protected securely by the SDP service. The AHs are under the administrative control of the enterprise domain. They do not acknowledge communication from any other host and will not respond to non-provisioned requests. This architecture enables the control plane to remain separate from the data plane achieving a scalable security system.

The IH and AH devices connect to an SDP controller that secures access to isolated assets by ensuring that the users and their devices are authenticated and authorized before granting network access. After authenticating an IH, the SDP controller determines the list of AHs to which the IH is authorized to communicate. The AHs are then sent a list of IHs that should accept connections.

Aside from the hosts and the controller, we have the SDP gateway component that provides authorized users and devices access to protected processes and services. The protected assets are located behind the gateway that can be architecturally positioned in multiple locations such as the cloud or on-premise. The gateways can exist in multiple locations in parallel.

 

Dynamic Tunnelling

A user with multiple tunnels to multiple gateways will be expected in the real world. It’s not a static path or a one-to-one relationship but a user-to-application relationship. The applications can exist everywhere, whereby the tunnel is dynamic and ephemeral.

For a client to connect to the gateway, latency or SYN SYN/ACK RTT testing should be performed to determine the Internet links’ performance. This ensures that the application access path always uses the best gateway, improving application performance.

Remember that the gateway only connects outbound on TCP port 443 (mTLS), and as it acts on behalf of the internal applications, it needs access to the internal apps. As a result, depending on where you position the gateway, either internal to the LAN, private virtual private cloud (VPC) or in the DMZ protected by local firewalls, ports may need to be opened on the existing firewall.

 

Future of Software-Defined Perimeter:

As the digital landscape evolves, secure network access becomes even more crucial. The future of SDP looks promising, with advancements in technologies like Artificial Intelligence and Machine Learning enabling more intelligent threat detection and mitigation.

In an era where data breaches are a constant threat, organizations must stay ahead of cybercriminals by adopting advanced security measures. Software Defined Perimeter offers a robust, scalable, and dynamic security framework that ensures secure access to critical resources.

By embracing SDP, organizations can significantly reduce their attack surface, enhance network performance, and protect sensitive data from unauthorized access. The time to leverage the power of Software Defined Perimeter is now.

 

software-defined perimeter

Zero trust security for full protection and data safety outline diagram. Labeled educational scheme with network, identity and device verification for safe information protection vector illustration.

Zero Trust: Single Packet Authorization | Passive authorization

Single Packet Authorization

In today's fast-paced world, where digital security is paramount, traditional authentication methods are often susceptible to malicious attacks. Single Packet Authorization (SPA) emerges as a powerful solution to enhance the security of networked systems. In this blog post, we will delve into the concept of SPA, its benefits, and how it revolutionizes network security.

Single Packet Authorization is a security technique that adds an extra layer of protection to your network. Unlike traditional methods that rely on passwords or encryption keys, SPA operates on the principle of allowing access to a specific service or resource based on the successful authorization of a single packet. This approach significantly reduces the attack surface and enhances security.

To grasp the inner workings of SPA, it is essential to understand the handshake process. When a connection attempt is made, the server sends a challenge to the client. The client, in turn, must construct a valid response packet using cryptographic algorithms. This response is then verified by the server, granting access if successful. This one-time authorization greatly reduces the chances of unauthorized access and brute-force attacks.

1. Enhanced Security: SPA adds an additional layer of security by limiting access to authorized users only. This reduces the risk of unauthorized access and potential data breaches.

2. Minimal Attack Surface: Unlike traditional authentication methods, which involve multiple packets and handshakes, SPA relies on a single packet. This significantly reduces the attack surface and improves overall security posture.

3. Protection Against DDoS Attacks: SPA can act as a deterrent against Distributed Denial of Service (DDoS) attacks. By requiring successful authorization before granting access, SPA mitigates the risk of overwhelming the network with malicious traffic.

Implementing SPA can be done through various tools and software solutions available in the market. It is crucial to choose a solution that aligns with your specific requirements and infrastructure. Some popular SPA implementations include fwknop, SPAProxy, and PortSentry. These tools offer flexibility, customization, and ease of integration into existing systems.

Highlights: Single Packet Authorization

The Role of Authorization

Authorization is arguably the most critical process in a zero-trust network, so an authorization decision should not be taken lightly. Ultimately, every flow and request will require a decision.

For the authorization decision to be effective, enforcement must be in place. In most cases, it takes the form of a load balancer, a proxy, or a firewall. We use the policy engine to decide which interacts with this component. The enforcement component ensures that clients are authenticated and passes context for each flow/request to the policy engine. By comparing the request and its context with policy, the policy engine informs the enforcer whether the request is permitted. As many enforcement components as possible should exist throughout the system and should be close to the workload.

authorization

Reverse Security 

Even though we are looking at disruptive technology to replace the virtual private network and offer secure segmentation, one thing to keep in mind with zero trust network design and software defined perimeter (SDP) is that it’s not based on entirely new protocols, such as the use of spa single packet authorization and single packet authentication. So we have reversed the idea of how TCP connects.

It started with authentication and then a connected approach, but traditional networking and protocols still play a large part. For example, we still use encryption to ensure only the receiver can read the data we send. We can, however, use encryption without authentication, which validates the sender.

zero trust environment

The importance of authenticity

However, the two should go together to stand any chance in today’s world. Attackers can circumvent many firewalls and secure infrastructure. As a result, message authenticity is a must for zero trust, and without an authentication process, a bad actor could change, for example, the ciphertext without the reviewer ever knowing.

Encryption and authentication

Even though encryption and authenticity are often intertwined, their purposes are distinct. By encrypting your data, you ensure confidentiality-the promise that only the receiver can read it. Authentication aims to verify that the message was sent by what it claims to be.

It is also interesting to note that authentication has another property. Message authentication requires integrity, which is essential to validate the sender and ensure the message is unaltered.

Encryption is possible without authentication, though this is a poor security practice.



Single Packet Authentication.

Key Single Packet Authorization Discussion points:


  • The issues with traditional security and networking constructs. TCP connectivity model.

  • Introducing Zero Trust Networking and MTLS.

  • Discussing SPA and its operations.

  • What can SPA offer?

  • Securitiy benefits of introducing SPA.

Related: Before you proceed, you may find the following post helpful:

  1. Identity Security
  2. Zero Trust Access

Back to Basics: Single Packet Authorization (SPA)

SPA: A Security Protocol

Single Packet Authorization (SPA) is a security protocol allowing users to access a secure network without entering a password or other credentials. Instead, it is an authentication protocol that uses a single packet—an encrypted packet of data—to convey a user’s identity and request access. This packet can be sent over any network protocol, such as TCP, UDP, or SCTP, and is typically sent as an additional layer of authentication beyond the network and application layers.

SPA works by having the user’s system send a single packet of encrypted data to the authentication server. The authentication server then uses a unique algorithm to decode the packet containing the user’s identity and request for access. If the authentication is successful, the server will send a response packet that grants access to the user.

SPA is a secure and efficient way to authenticate and authorize users. It eliminates the need for multiple authentication methods and sensitive data storage. SPA is also more secure than traditional authentication methods, as the encryption used in SPA is often more secure than passwords or other credentials.

Additionally, since the packet sent is encrypted, it cannot be intercepted and decoded, making it an even more secure form of authentication.

single packet authorization

The Mechanics of SPA:

SPA operates by employing a shared secret between the client and server. When a client wishes to access a service, it generates a packet containing a specific data sequence, including a timestamp, payload, and cryptographic hash. The server, equipped with the shared secret, checks the received packet against its calculations. The server grants access to the requested service if the packet is authentic.

Benefits of SPA:

1. Enhanced Security: SPA drastically reduces the attack surface by eliminating the need for open ports or exposed services. Since SPA relies on a single packet, it significantly reduces the risk of unauthorized access.

2. Protection against Network Scans: Traditional authentication methods are often vulnerable to network scans that attempt to identify open ports for potential attacks. SPA mitigates this risk by rendering the network invisible to scanning tools.

3. Flexibility and Convenience: SPA allows users to access services from any location, even through firewalls or network address translation (NAT). This flexibility eliminates the need for complex VPN setups or port forwarding configurations.

4. DDoS Mitigation: SPA can effectively mitigate Distributed Denial of Service (DDoS) attacks by rejecting packets that do not adhere to the predefined authentication criteria. This helps safeguard the availability of network services.

Implementing SPA:

Implementing SPA requires deploying specialized software or hardware components that support the single packet authorization protocol. Several open-source and commercial solutions are available, making it feasible for organizations of all sizes to adopt this innovative security technique.

Back to Basics: Zero Trust

Five fundamental assertions make up a zero-trust network:

  • Networks are always assumed to be hostile.

  • The network is always at risk from external and internal threats.

  • To determine trust in a network, locality alone is not sufficient.

  • A network flow, device, or user must be authenticated and authorized.

  • Policies must be dynamic and derived from as many data sources as possible to be effective.

In a traditional network security architecture, different networks are divided into firewall-protected zones. It is determined which network resources each zone is permitted to access based on its level of trust. With this model, there is a solid defense in depth. In DMZs, traffic can be tightly monitored and controlled over resources deemed more risky, like those facing the public internet.

Perimeter Defense

Perimeter defenses protecting your network are less secure than you might think. Hosts behind the firewall have no protection, so when a host in the “trusted” zone is breached, which is just a matter of time, access to your data center can be breached. The zero trust movement strives to solve the inherent problems in placing our faith in the network.

Instead, it is possible to secure network communication and access so effectively that the physical security of the transport layer can be reasonably disregarded.

Typically, we examine the IP address of the remote system and ask for a password. Unfortunately, these strategies alone are insufficient for a zero-trust network, where attackers can communicate from any IP and insert themselves between themselves and a trusted remote host. Therefore, utilizing strong authentication on every flow in a zero-trust network is vital. The most widely accepted method is a standard named X.509.

zero trust security
Diagram: Zero trust security. Authenticate first and then connect.

A key aspect of zero trust network ZTN and zero trust principles is to authenticate and authorize network traffic, i.e., the flows between the requesting resource and the intended service. Simply securing communications between two endpoints is not enough. Security pros must ensure that each flow is authorized.

This can be done by implementing a combination of security technologies such as Single Packet Authorization (SPA), Mutual Transport Layer Security (MTLS), Internet Key Exchange (IKE), and IP security (IPsec).

IPsec can use a unique security association (SA) per application; only authorized flows can construct security policies. While IPsec is considered to operate at Layer 3 or 4 in the open systems interconnection (OSI) model, application-level authorization can be carried out with X.509 or an access token.

Mutually authenticated TLS (MTLS)

Mutually authenticated TLS (Transport Layer Security) is a system of cryptographic protocols used to establish secure communications over the Internet. It guarantees that the client and the server are who they claim to be, ensuring secure communications between them. This authentication is accomplished through digital certificates and public-private key pairs.

Mutually authenticated TLS is also essential for preventing man-in-the-middle attacks, where a malicious actor can intercept and modify traffic between the client and server. Without mutually authenticated TLS, an attacker could masquerade as the server and thus gain access to sensitive data.

To set up mutually authenticated TLS, the client and server must have digital certificates. The server certificate is used to authenticate the server to the client, while the client certificate is used to authenticate the client to the server. Both certificates are signed by the Certificate Authority (CA) and can be stored in the server and client’s browsers. The client and server then exchange the certificates to authenticate each other.

Once the certificates have been exchanged and verified, the client and server can securely communicate. Mutually authenticated TLS also provides encryption and integrity checks, ensuring the data is not tampered with in transit.

This enhanced version of TLS, known as mutually authenticated TLS (MTLS), is used to validate both ends of the connection. The most common TLS configuration is the validation, which ensures the client is connected to a trusted entity. However, the authentication doesn’t happen the other way around, so the remote entity communicates with a trusted client. This is the job of mutual TLS. As I said, mutual TLS goes one step further and authenticates the client.

The pre-authentication stage

You can’t attack what you cannot see. The mode that allows pre-authentication is Single Packet Authorization. UDP is the preferred base for pre-authentication because UDP packets, by default, do not receive a response. However, TCP and even ICMP can be used with the SPA. Single Packet Authorization is a next-generation passive authentication technology beyond what we previously had with port knocking, which uses closed ports to identify trusted users. SPA is a step up from port knocking.

The typical port-knocking scenario involves a port-knocking server configuring a packet filter to block all access to a service, such as the SSH service until a port-knocking client sends a specific port-knocking sequence. For instance, the server could require the client to send TCP SYN packets to the following ports in order: 23400 1001 2003 65501.

If the server monitors this knock sequence, the packet filter reconfigures to allow a connection from the originating IP address. However, port knocking has its limitations, which SPA addresses; SPA retains all of the benefits of port knocking but fixes the rules.

As a next-generation Port Knocking (PK), SPA overcomes many limitations PK exhibits while retaining its core benefits. However, PK has several limitations, including difficulty protecting against replay attacks, the inability to reliably support asymmetric ciphers and HMAC schemes, and the fact that it is trivially easy to mount a DoS attack by spoofing an additional packet into a PK sequence while it is traversing the network (thereby convincing the PK server that the client does not know the proper sequence).

SPA solves all of these shortcomings. As part of SPA, services are hidden behind a default-drop firewall policy, SPA data is passively acquired (usually via libpcap), and standard cryptographic operations are implemented for SPA packet authentication and encryption/decryption.

Firewall Knock Operator

Fwknop (short for the “Firewall Knock Operator”) is a single-packet authorization system designed to be a secure and straightforward way to open up services on a host running an iptables- or ipfw-based firewall. It is a free, open-source application that uses the Single Packet Authorization (SPA) protocol to provide secure access to a network.

Fwknop sends a single SPA packet to the firewall containing an encrypted message with authorization information. The message is then decrypted and compared against a set of rules on the firewall. If the message matches the rules, the firewall will open access to the service specified in the packet.

Fwknop is an ideal solution for users who need to access services on a remote host without having to configure the firewall each time manually. It is also a great way to add an extra layer of security to already open services.

To achieve strong concealment, fwknop implements the SPA authorization scheme. SPA requires only a single packet encrypted, non-replayable, and authenticated via an HMAC to communicate desired access to a service hidden behind a firewall in a default-drop filtering stance. The main application of SPA is to use a firewall to drop all attempts to connect to services such as SSH to make exploiting vulnerabilities (both 0-day and unpatched code) more difficult. Because there are no open ports, any service SPA hides cannot be scanned with, for example, NMAP.

Supported Firewalls

The fwknop project supports four firewalls: We have support for iptables, firewalld, PF, and ipfw across Linux, OpenBSD, FreeBSD, and Mac OS X. There is also support for custom scripts so that fwknop can be made to support other infrastructure such as ipset or nftables.

fwknop client user interface
Diagram: fwknop client user interface. Source mrash GitHub.

Example use case: SSHD protection

Users of Single Packet Authorization (SPA) or its less secure cousin, Port Knocking (PK), usually access SSHD running on the same system as the SPA/PK software. A SPA daemon temporarily permits access to a passively authenticated SPA client through a firewall configured to drop all incoming SSH connections. This is considered the primary SPA usage.

In addition to this primary use, fwknop also makes robust use of NAT (for iptables/firewalld firewalls). A firewall is usually deployed on a single host and acts as a gateway between networks. Firewalls that use NAT (at least for IPv4 communications) commonly provide Internet access to internal networks on RFC 1918 address space and access to internal services by external hosts.

Since fwknop integrates with NAT, users on the external Internet can access internal services through the firewall using SPA. Additionally, it allows fwknop to support cloud computing environments such as Amazon’s AWS, although it has many applications on traditional networks.

SPA Use Case
Diagram: SPA Use Case. Source mrash Github.

Single Packet Authorization and Single Packet Authentication

Single Packet Authorization (SPA) uses proven cryptographic techniques to make internet-facing servers invisible to unauthorized users. Only devices seeded with the cryptographic secret can generate a valid SPA packet and establish a network connection. This is how it reduces the attack surface and becomes invisible to hostile reconnaissance.

SPA Single Packet Authorization was invented over ten years ago and was commonly used for superuser SSH access to servers where it mitigates attacks by unauthorized users. The SPA process happens before the TLS connection, mitigating attacks targeted at the TLS ports.

As mentioned, SDP didn’t invent new protocols; it was more binding existing protocols. SPA used in SDP was based on RFC 4226 HMAC-based One-Time Password “HOTP.” It is another layer of security and is not a replacement for the security technologies mentioned at the start of the post.

Reconnaissance: The first step

The first step in an attack is reconnaissance, whereby an attacker is on the prowl to locate a target. This stage is easy and can be automated with tools such as NMAP. However, SPA ( and port knocking ) employs a default-drop stance that provides service only to those IP addresses that can prove their identity via a passive mechanism.

No TCP/IP stack access is required to authenticate remote IP addresses. Therefore, NMAP cannot tell that a server is running when protected with SPA, and whether the attacker has a zero-day exploit is irrelevant.

 

zero trust security model
Diagram: Zero trust security model.

The idea around SPA and Single Packet Authentication is that a single packet is sent, and based on that packet, an authentication process is carried out. The critical point is that nothing is listening on the service, so you have no open ports. For the SPA service to operate, there is nothing explicitly listening.

When the client sends an SPA packet, it will be rejected, but a second service identifies it in the IP stack and then authenticates it. If the SPA packet is successfully authenticated, the server will open a port in the firewall, which could be based on Linux iptables, so the client can establish a secure and encrypted connection with the intended service.

A simple Single Packet Authentication process flow

The SDP network gateway protects assets, and this component could be containerized and listened to for SPA packets. In the case of an open-source version of SDP, this could be fwknop, which is a widespread open-source SPA implementation. When a client wants to connect to a web server, it sends a SPA packet. When the requested service receives the SPA packet, it will open the door once the credentials are verified. However, the service still has not responded to the request.

When the fwknop services receive a valid SPA packet, the contents are decrypted for further inspection. The inspection reveals the protocol and port numbers to which the sender requests access. Next, the SDP gateway adds a rule to the firewall to establish a mutual TLS connection to the intended service. Once this mutual TLS connection is established, the SDP gateway removes the firewall rules, making the service invisible to the outside world.

single packet authorization
Diagram: Single Packet Authorization: The process flow.

Fwknop uses this information to open firewall rules, allowing the sender to communicate with that service on those ports. The firewall will only be opened for some time and can be configured by the administrator. Any attempts to connect to the service must know the SPA packet, and even if the packet can be recreated, the packet’s sequence number needs to be established before the connection. This is next to impossible, considering the sequence numbers are randomly generated.

Once the firewall rules are removed, let’s say after 1 minute, the initial MTLS session will not be affected as it is already established. However, other sessions requesting access to the service on those ports will be blocked. This permits only the sender of the IP address to be tightly coupled with the requested destination ports. It’s also possible for the sender to include a source port, enhancing security even further.

What can Single Packet Authorization offer

Let’s face it: robust security is hard to achieve. We all know that you can never be 100% secure. Just have a look at OpenSSH. Some of the most security-conscious developers developed OpenSSH, yet it occasionally contains exploitable vulnerabilities.

Even when you look at some attacks on TLS, we have already discussed the DigiNotar forgery in a previous post on zero-trust networking. Still, one that caused a significant issue was the THC-SSL-DOS attack, where a single host could take down a server by taking advantage of the asymmetry performance required by the TLS protocol.

Single Packet Authorization (SPA) overcomes many existing attacks and, combined with the enhancements of MTLS with pinned certificates, creates a robust security model addition; SPA defeats many a DDoS attack as only a limited amount of server performance is required to operate.

SPA provides the following security benefits to the SPA-protected asset:

    • SPA blackens the gateway and protects assets that sit behind the gateway. The gateway does not respond to connection attempts until it provides an authentic SPA. Essentially, all network resources are dark until security controls are passed.
    • SPA also mitigates DDoS attacks on TLS. TLS is likely publicly reachable online, and running the HTTPS protocol is highly susceptible to DDoS. SPA mitigates these attacks by allowing the SDP gateway to discard the TLS DoS attempt before entering the TLS handshake. As a result, there will be no exhaustion from targeting the TLS port.
    • SPA assists with attack detection. The first packet to an SDP gateway must be a SPA packet. If a gateway receives any other type of packet, it should be viewed and treated as an attack. Therefore, the SPA enables the SDP to identify an attack based on a malicious packet.

Summary: Single Packet Authorization

In this blog post, we explored the concept of SPA, its key features, benefits, and potential impact on enhancing network security.

Section 1: Understanding Single Packet Authorization

At its core, SPA is a security technique that adds an additional layer of protection to network systems. Unlike traditional methods that rely on usernames and passwords, SPA utilizes a single packet sent to the server to grant access. This packet contains encrypted data and specific authorization codes, ensuring that only authorized users can gain entry.

Section 2: The Key Features of SPA

One of the standout features of SPA is its simplicity. Using a single packet simplifies the process and minimizes the potential attack surface. SPA also offers enhanced security through its encryption and strict authorization codes, making it difficult for unauthorized individuals to gain access. Furthermore, SPA is highly customizable, allowing organizations to tailor the authorization process to their needs.

Section 3: Benefits of Single Packet Authorization

Implementing SPA brings several notable benefits to the table. Firstly, SPA effectively mitigates the risk of brute-force attacks by eliminating the need for traditional login credentials. Additionally, SPA enhances security without sacrificing usability, as users only need to send a single packet to gain access. This streamlined approach saves time and reduces the likelihood of human error. Lastly, SPA provides detailed audit logs, allowing organizations to monitor and track authorized access more effectively.

Section 4: Potential Impact on Network Security

The adoption of SPA has the potential to revolutionize network security. By leveraging this technique, organizations can significantly reduce the risk of unauthorized access, data breaches, and other cybersecurity threats. SPA’s unique approach challenges traditional authentication methods and offers a more robust and efficient alternative.

Conclusion:

Single Packet Authorization (SPA) is a powerful security technique with immense potential to bolster network security. With its simplicity, enhanced protection, and numerous benefits, SPA offers a promising solution for organizations seeking to safeguard their digital assets. By embracing SPA, they can take a proactive stance against cyber threats and build a more secure digital landscape.

Cyber security threat. Young woman using computer and coding. Internet and network security. Stealing private information. Person using technology to steal password and private data. Cyber attack crime

SDP Network

 

 

SDP Network

In today’s interconnected world, where threats to data security are becoming increasingly sophisticated, businesses are constantly searching for ways to protect their sensitive information. Traditional network security measures are no longer sufficient in safeguarding against cyber attacks. Enter the Software Defined Perimeter (SDP), a revolutionary approach to network security that offers enhanced protection and control. In this blog post, we will delve into the concept of SDP and explore its various benefits.

Software Defined Perimeter, also known as a Zero Trust Network, is an architecture that focuses on secure access to resources based on the user’s identity and device. It moves away from the traditional method of relying on a static perimeter defense and instead adopts a dynamic approach that adapts to the ever-changing threat landscape.

 

Highlights: SDP Network

  • Creating a Zero Trust Environment

Software-Defined Perimeter is a security framework that shifts the focus from traditional perimeter-based network security to a more dynamic and user-centric approach. Instead of relying on a fixed network boundary, SDP creates a “Zero Trust” environment, where users and devices are authenticated and authorized individually before accessing network resources. This approach ensures that only trusted entities gain access to sensitive data, regardless of their location or network connection.

  • Zero trust framework

The zero-trust framework for networking and security is here for a good reason. There are various bad actors: ranging from the opportunistic and targeted to state-level, and all are well prepared to find ways to penetrate a hybrid network. As a result, there is now a compelling reason to implement the zero-trust model for networking and security.

SDP network brings SDP security, also known as software defined perimeter, which is heavily promoted as a replacement for the virtual private network (VPN) and, in some cases, firewalls for ease of use and end-user experience.

  • Dynamic tunnel of 1

It also provides a solid SDP security framework utilizing a dynamic tunnel of 1 per app per user. This offers security at the segmentation of a micro level, providing a secure enclave for entities requesting network resources. These are micro-perimeters and zero trust networks that can be hardened with technology such as SSL security and single packet authorization.

 

For pre-information, you may find the following useful:

  1. Remote Browser Isolation
  2. Zero Trust Network

 



SDN Network.

Key SDP Network Discussion points:


  • The role of SDP security. Authentication and Authorization.

  • SDP and the use of Certificates.

  • SDP and Private Key storage.

  • Public Key Infrastructure (PKI).

  • A final note on Certificates.

 

Back to basics with an SDP network

A software-defined perimeter is a security approach that controls resource access and forms a virtual boundary around networked resources. Think of an SDP network as a 1-to-1 mapping. Unlike a VLAN that can have many hosts within, all of which could be of different security levels.

Also, with an SDP network, we create a security perimeter via software versus hardware; an SDP can hide an organization’s infrastructure from outsiders, regardless of location. Now we have a security architecture that is location agnostic. As a result, employing SDP architectures will decrease the attack surface and mitigate internal and external network bad actors. The SDP framework is based on the U.S. Department of Defense’s Defense Information Systems Agency’s (DISA) need-to-know model from 2007.

 

Benefits of Software-Defined Perimeter:

1. Enhanced Security: SDP provides an additional layer of security by ensuring that only authenticated and authorized users can access the network. By implementing granular access controls, SDP reduces the attack surface and minimizes the risk of unauthorized access, making it significantly harder for cybercriminals to breach the system.

2. Improved Flexibility: Traditional network architectures often struggle to accommodate the increasing number of devices and the demand for remote access. SDP enables businesses to scale their network infrastructure effortlessly, allowing seamless connectivity for employees, partners, and customers, regardless of location. This flexibility is particularly valuable in today’s remote work environment.

3. Simplified Network Management: SDP simplifies network management by centralizing access control policies. This centralized approach reduces complexity and streamlines granting and revoking access privileges. Additionally, SDP eliminates the need for VPNs and complex firewall rules, making network management more efficient and cost-effective.

4. Mitigated DDoS Attacks: Distributed Denial of Service (DDoS) attacks can cripple an organization’s network infrastructure, leading to significant downtime and financial losses. SDP mitigates the impact of DDoS attacks by dynamically rerouting traffic and preventing the attack from overwhelming the network. This proactive defense mechanism ensures that network resources remain available and accessible to legitimate users.

5. Compliance and Regulatory Requirements: Many industries are bound by strict regulatory requirements, such as healthcare (HIPAA) or finance (PCI-DSS). SDP helps organizations meet these requirements by providing a secure framework that ensures data privacy and protection. Implementing SDP can significantly simplify the compliance process and reduce the risk of non-compliance penalties.

 

Feature 1: Dynamic Access Control

One of the primary features of SDP is its ability to dynamically control access to network resources. Unlike traditional perimeter-based security models, which grant access based on static rules or IP addresses, SDP employs a more granular approach. It leverages context-awareness and user identity to dynamically allocate access rights, ensuring that only authorized users can access specific resources. This feature eliminates the risk of unauthorized access, making SDP an ideal solution for securing sensitive data and critical infrastructure.

Feature 2: Zero Trust Architecture

SDP embraces the concept of Zero Trust, a security paradigm that assumes no user or device can be trusted by default, regardless of their location within the network. With SDP, every request to access network resources is subject to authentication and authorization, regardless of whether the user is inside or outside the corporate network. By adopting a Zero Trust architecture, SDP eliminates the concept of a network perimeter and provides a more robust defense against both internal and external threats.

Feature 3: Application Layer Protection

Traditional security solutions often focus on securing the network perimeter, leaving application layers vulnerable to targeted attacks. SDP addresses this limitation by incorporating application layer protection as a core feature. By creating micro-segmented access controls at the application level, SDP ensures that only authenticated and authorized users can interact with specific applications or services. This approach significantly reduces the attack surface and enhances the overall security posture.

Feature 4: Scalability and Flexibility

SDP offers scalability and flexibility to accommodate the dynamic nature of modern business environments. Whether an organization needs to provide secure access to a handful of users or thousands of employees, SDP can scale accordingly. Additionally, SDP seamlessly integrates with existing infrastructure, allowing businesses to leverage their current investments without the need for a complete overhaul. This adaptability makes SDP a cost-effective solution with a low barrier to entry.

 

SDP Security

Authentication and Authorization

So when it comes to creating an SDP network and SDP security, what are the ways to authenticate and authorize?

Well, firstly, trust is the main element within an SDP network. Therefore, mechanisms that can associate themselves with authentication and authorization to trust at a device, user, or application level are necessary for zero-trust environments.

When something presents itself to a zero-trust network, it must go through several SDP security stages before access is granted. Essentially the entire network is dark, meaning that resources drop all incoming traffic by default, providing an extremely secure posture. A more secure, robust, and dynamic network of geographically dispersed services and clients can be created based on this simple premise.

 

  • A key point: The difference between Authentication and Authorization.

Before we go any further, it’s essential to understand the difference between authentication and authorization. Upon examination of an end host in the zero-trust world, we have a device and a user forming an agent. The device and user authentication are carried out first before agent formation.

Authentication of the device will come first and second for the user. After these steps, authorization is performed against the agent. Authentication means confirming your identity, while authorization means granting access to the system.

 

The consensus among SDP network vendors

Generally, with most zero-trust and SDP VPN network vendors, the agent is only formed once valid device and user authentication have been carried out. And the authentication methods used to validate the device and user can be separate. A device that needs to identify itself to the network can be authenticated with X.509 certificates.

A user can be authenticated by other means, such as a setting from an LDAP server if the zero trust solution has that as an integration point. The authentication methods between the device and users don’t have to be tightly coupled, providing flexibility.

zero trust networks
Diagram: Zero trust networks. Some of the zero trust components are involved.

 

SDP Security with SDP Network: X.509 certificates

IP addresses are used for connectivity, not authentication, and don’t have any fields to implement authentication. The authentication must be handled higher up the stack. So we need to use something else to define identity, and that would be the use of certificates. X.509 certificates are a digital certificate standard that allows identity to be verified through a chain of trust and is commonly used to secure device authentication. X.509 certificates can carry a wealth of information within the standard fields that can fulfill the requirements to carry particular metadata.

To provide identity and bootstrap encrypted communications, X.509 certificates use two cryptographic keys, mathematically-related pairs consisting of public and private keys. The most common are RSA (Rivest–Shamir–Adleman) key pairs.

The private key is secret and held by the certificate’s owner, and the public key, as the names suggest, is not secret and distributed. The public key can encrypt the data that the private key can decrypt and vice versa. If the correct private key is not held, it is impossible to decrypt encrypted data using the public key.

 

SDP Security with SDP Network: Private key storage

Before we start discussing the public key, let us examine how we secure the private key. If bad actors get their hands on the private key, it lights out for device authentication.

Once the device presents a signed certificate, one way to secure the private key would be to configure some access rights to the key. However, if a compromise occurs, we are left in the undesirable world of elevated access, exposing the unprotected key.

The best way to secure and store private device keys is to use crypto processors such as a trusted platform module (TPM). The cryptoprocessor is essentially a chip that is embedded in the device.

The private keys are bound to the hardware without being exposed to the system’s operating system, which is far more vulnerable to compromise than the actual hardware. TPM binds the private software key to the hard creating a very robust device authentication.

 

SDP Security with SDP Network: Public Key Infrastructure (PKI)

How do we ensure that we have the correct public key? This is the role of the public key infrastructure (PKI). There are many types of PKI, with certificate authorities (CA) being the most popular. In cryptography, a certificate authority is an entity that issues digital certificates.

A certificate can be a pointless blank paper unless it is somehow trusted. This is done by digitally signing the certificate to endorse the validity. It is the responsibility of the certificate authorities to ensure all details of the certificate are correct before signing it. PKI is a framework that defines a set of roles and responsibilities used to distribute and validate public keys in an untrusted network securely.

For this, a PKI leverages a registration authority (RA). You may wonder what the difference between an RA and a CA is. The RA interacts with the subscribers to provide CA services. The RA is subsumed by the CA, which takes total responsibility for all actions of the RA.

The registration authority accepts requests for digital certificates and authenticates the entity making the request. This binds the identity to the public key embedded in the certificate, cryptographically signed by the trusted 3rd party.

 

Not all certificate authorities are secure!

However, all certificate authorities are not bulletproof from attack. Back in 2011, DigiNotar was at the mercy of a security breach. The bad actor took complete control of all eight certificate-issuing servers in which they issued rogue certificates that had not yet been identified. It is estimated that over 300,000 users had their private data exposed by rogue certificates.

Browsers immediately blacklist DigiNotar’s certificates, but it does highlight the issues of using a 3rd party. While Public Key Infrastructure is used at large on the public internet backing X.509 certificates, it’s not recommended for zero trust SDP. At the end of the day, when you think about it, you are still using 3rd party for a pretty important task. It would be best if you were looking to implement a private PKI system for a zero-trust approach to networking and security.

You could also implement a temporary one-time password (TOTP) if you are not looking for a fully automated process. This allows for human control over the signing of the certificates. Remember that much trust must be placed in whoever is responsible for this step.

 

Conclusion:

As businesses continue to face increasingly sophisticated cyber threats, the importance of implementing robust network security measures cannot be overstated. Software Defined Perimeter offers a comprehensive solution that addresses the limitations of traditional network architectures.

By adopting SDP, organizations can enhance their security posture, improve network flexibility, simplify management, mitigate DDoS attacks, and meet regulatory requirements. Embracing this innovative approach to network security can safeguard sensitive data and provide peace of mind in an ever-evolving digital landscape.

Organizations must adopt innovative security solutions as cyber threats evolve to protect their valuable assets. Software-Defined Perimeter offers a dynamic and user-centric approach to network security, providing enhanced protection against unauthorized access and data breaches.

With enhanced security, granular access control, simplified network architecture, scalability, and regulatory compliance, SDP is gaining traction as a trusted security framework in today’s complex cybersecurity landscape. Embracing SDP can help organizations stay one step ahead of the ever-evolving threat landscape and safeguard their critical data and resources.

 

sdp security