Intro

Welcome to Adventures in Security. In this lesson, we explore remote access to cloud and on-premise resources and how to secure it with secure protocols (VPN, SSL, SSH, IPsec), also with strong authentication and zero trust networking. You can download the script for this video, which also includes all the graphics that I use, from the link above.

Overview

Remote access often requires users and services to access highly classified data and categorize systems from hostile environments. Hostile environments include public and home networks, wireless and wired. As we move through this lesson, remember that remote access solutions should be flexible, secure, transparent to users, compatible with the anytime-anywhere resource access model, and budget-friendly. These security objectives help manage risk, as shown in this graphic. Remote access breaches that bypass physical and logical security safeguards increase probability of data loss during remote access from high-risk locations with non-company-owned devices. Threat actors can use compromised remote access devices to pivot to other cloud or on-premise resources. Remote access devices are open to theft or other means of physical compromise, and infrequently connecting devices might not be fully updated with patches or secure configurations. The security safeguards discussed in this video help manage these risks.

Remote Access Risks

Three general remote access methods are dial-up, VPN, or terminal access using a thin client. Dial-up modems are rarely used today. it's insecure and really slow. Connecting with a virtual private network, or VPN, enables a secure tunnel through which classified data passes. We cover this in more detail later. With dial-up and VPN, the endpoint looks like any other device on the network with all the associated rights and permissions. However, a thin client solution enables remote access to services and data with limited exchange of information. Information is not stored on the client, and the client can only access the resources needed to run host-based applications and services.

Remote Access Types

Related to the three access methods are four access types. When a user connects to perform a specific task, like checking email or accessing thin client enabling resources, it is service-specific access. One example is remotely accessing email via outlook on web or OWA, but service access can also provide connection to non-web-enabled applications and services. Remote control access allows help desk personnel or administrators to remotely access endpoint devices. This is a common threat vector and easily leveraged by threat actors when security does not take steps to harden it. Screen scraping provides only display data to users. This is commonly done with terminal services or use of VDE, virtual desktop environments. Finally, remote node access is another name for dial-up access.

Four General Remote Access Safeguards

There are four general safeguards that help secure remote access: strong authentication, limiting access to only those who need it, encryption, and zero trust.

Strong Authentication

Let's look at each. Strong authentication is usually thought of as the use of two or more instances of something a user has, a token, something a user is, biometrics, and something a user knows, password. In this example, we have something a user knows and something a user is. I use a simple probability calculation to show how using more than one factor significantly strengthens the identity verification process. The probabilities I use are not a reflection of any standard likelihood of a password or fingerprint vulnerability because authentication vulnerabilities depend on the uniqueness of the factor and the authentication solution used. Passwords are stolen every day, making password-only access a weak verification factor. Further, biometrics are not perfect, with possible vulnerabilities in enrollment, storage, and scanning errors. These vulnerabilities result in factor failure probabilities. Our password has a 0.30, or 30 percent, probability of being compromised and used to access the resources. The fingerprint has a 0.20 probability of compromise and use. The overall probability of authentication compromise significantly drops to .06 when the password and fingerprint are both required for identity verification. As shown, when multiple things need to happen to reach a result, we multiply the probabilities. Strong authentication usually does not rely on one factor, including only the use of certificates. How we strengthen remote authentication depends on the subject, the object, and possibly other session characteristics. For a more detailed look at access control methods read the article above. After identity verification, we need to determine allowed access or authorization based on read, write, and other privileges that we want the user to have. Two of the most common approaches to managing access are RBAC and ABAC.

RBAC

With RBAC, the organization establishes roles, the data owner approves role access based on business need, and users are assigned to the roles. Access enforces least privilege, need to know, and separation of duties. When a user authenticates, the RBAC system grants access based on approved role access.

ABAC

This is a good approach for general office access, but it can fall short when trying to control access across various remote access conditions, Attribute based access control, or ABAC, extends RBAC by extending access rules to potential session characteristics. The characteristics checked depend on the business policies in place, covering device used, device owner (employee or company), device health, time of day, day of week, resources requested, and other possible session characteristics. Authentication strength can also be adjusted based on attributes. For example, an employee-owned device connecting from a public network might require multi-factor authentication. Just a password might be good enough for the same employee or device combination if attempting to connect over the organization's internal network.

Limiting Remote Access

Remote access should be limited to only employees who absolutely need it should have it; today, that's almost everybody. However, security should work with data and process owners to limit access to what is needed for remote work. For example, employees working from home during business hours likely need access based on their assigned roles, access secured based on risk. In-office employees seeking access after business hours might be limited to email only. Again, flexible access based on risk usually requires use of ABAC, or attribute-based access control.

TACACS+ & RADIUS

Two popular tools for remote access control are TACAS+, terminal access controller access control system, a Cisco propriety proprietary protocol, and RADIUS. TACACS+ enables secure authentication for network device administration, integrating authentication and authorization processes. RADIUS, remote authentication dial-in user service, is a remote standard protocol used for remote user authentication. Although it includes dial-in in its name, it's used for all types of remote access with dial-in no longer a realistic solution for business. The table shows the differences between TACACS+ and RADIUS. RADIUS uses UDP over ports 1812 and 1645 for authentication and 1813 and 1646 for accounting. TACACS uses TCP port 49 for all operations.

Remote Patchways/Protocols

Remote access almost always results in data of some classification passing over a public network, including the internet. We usually protect this data in transit using one of four encrypted pathways: TLS, SSH, IPSec, and VPN. These protocols are used to secure sessions between devices on the same network, between end-user devices and an ISP, between two private networks, and for access to services using high-risk communication protocols or methods.

TLS

TLS, or transport layer security, facilitates authentication between two devices, enables secure transit of data by encrypting the traffic, and replaces broken SSL. It's commonly used to protect information traveling over the internet. For a more detailed look at how TLS works, watch the video above.

SSH

SSH is often used by network administrators, securely connecting to network devices, and performing maintenance tasks.

IPSec

IP security, or IPSec encrypts traffic on the network and between networks. For a detailed look at how both of these work watch the video above.

VPN

Virtual private networks, or VPN, are popular for connecting both remote users and dispersed organization locations, providing session confidentiality. Several protocols or protocol sets enable the creation of a VPN.

VPN Protocols

PPTP, point-to-point tunneling protocol, operates at layer 2, is used on IP networks, and encapsulates PPP, or point-to-point packets. L2TP, layer 2 tunneling protocol, is an extension of PPTP that encapsulates PPP traffic, and is considered more secure than PPTP. IPSec, or IP security, is an IETF standard suite of protocols that secures traffic over an IP network. In addition to confidentiality, it also supports authentication. SSL VPN uses transport layer security, TLS, to establish a secure authenticated connection. IPSec, operating at layer 3, is commonly used to establish VPN connections between an organization's facilities. It's harder to use for remote user access requiring installation and management of endpoint agents.

SSL VPN

SSL VPN only requires endpoint browsers that connect to a cloud or on-premise appliance, establishing an authenticated secure connection. The appliance enables access based on business policies, allowing access to only what is needed for business operation, and restricting access based on risk. Let's see how this works. First, the remote user establishes a TLS connection with a VPN gateway. The connection can be one of two modes: portal or tunnel. In portal mode, VPN works like a standard HTTPS connection, presenting users with a web page portal that links with browser-friendly resources and limits the number of simultaneous connections. Tunnel mode enables more connections and access to both browser-friendly and legacy resources not designed for browser access. Both modes enable use of business policies to control access to resources. A segmented or zero trust design helps enforce policies limiting access based on resource location. The gateway uses LDAP access for authentication and configured business policies to determine allowed resource access. SSL VPN is easy to deploy, largely transparent to users, easy to support, and supports least privileged access.

SSL VPN vs. IPSec VPN

To summarize the differences between IPSec and SSL VPN, IPsec VPN management efforts significantly increase as the number of remote access entities increases, whereas SSL VPN remains simple to manage regardless of scope increases. IPsec VPN requires endpoint configuration and management adding to its management challenges. SSL VPN does not require the same level of management, and because of its management challenges, IPsec can be more expensive than SSL VPN.

VPN Vulnerabilities

Although widely used for remote access security, VPN is not a perfect solution. Threat actors have ways to circumvent its protection. Man-in-the-middle, or on-path, attacks for example, can enable interception of VPN traffic, especially traffic traveling over public networks. But threat actors can also bypass secure session links by compromising user devices, enabling access to any resources the user has access to. It's critical to harden remote access devices, protecting them with host-based safeguards, detecting or blocking unwanted traffic, encrypting locally stored data.

Remote Access Hardening

Host-based safeguards include IPS/IDS, firewalls, and anti-virus. These three safeguards enable anomaly detection and prevention. In addition to detection safeguards, hardening also includes physical security. Policies define physical security requirements for remote access devices employee training and consistent sanctions for non-compliance help secure ensure employees properly protect physical access to their devices. Logical access controls. Encryption supported by authentication methods commensurate with risk help prevent access to stored or processed data. No local admin access. Non-admin employees should never have local admin access to their devices preventing elevated privileged malicious access and preventing users from disabling safeguards. Allowed application listing. Users should not be able to install any applications not on an approved application list enabling better control over remote device vulnerabilities. No shared accounts . Accountability allows us to track who did what and when. It's critical for audits and forensic reconstruction of events before during and after an incident. In addition named accounts provide granular least privilege, need to know, and separation of duties enforcement based on specific users and their roles. Each individual should have a unique account ID and password. Only under special circumstances should employees share a common account and never allow shared account access to EUDs processing or storing highly sensitive data. Strong authentication. Lost or stolen devices can contain significant amounts of classified information making them prime targets. Strong device authentication protected by strong authentication is a great way to thwart threat actor access. Further, denying access to a device also helps prevent access to cloud resources, resources the user has authorized access to. Strong authentication consists of a combination of password enforcement, certificate requirements, maximum failed login attempts, inactivity timers, and encrypted configuration files. Reasonable group policy refresh interval. Threats and associated risks change, requiring frequent changes across group policies. Organizations should establish effective intervals for policy refreshes including managing devices that do not connect very often. Ability to track lost or stolen devices and block or wipe them. Again mobile devices are subject to loss and theft, potentially making locally stored data available, and enabling threat actor access to cloud and on-premise resources, and the last two disabling use of third-party cookies and patching. Well, that's it for this lesson. If you have questions, please ask. ...and until next time, be careful what you click.

Outro

you