Secure Resource Publishing
Publish web resources through Web Application Firewall (in common people – WAF). For quick deployment and basic protection, standard security profiles for OWASP Top 10. At first, you will have to tighten a lot of nuts in terms of catching false positive events. If right now you do not have WAF – do not despair! If you are testing some kind of trial version of WAF, try using it to solve this problem, or install the open-source solution Nginx + ModSecurity.
If WAF could not be used, then hurriedly (whenever possible) transfer the application to HTTPS, check all passwords (user, admin) for the published application for compliance with the password policy established by the company. Do not forget to check the operating systems and CMS for freshness, as well as the presence of all the necessary patches, in a word – sanitize all areas of the future public service. Expand Kali Linux and use the built-in set of utilities for scanning vulnerabilities, if there is no time for this, use one of the public vulnerability scanners (Detectify, ImmuniWeb, etc.).
What do not do? Do not put on display on the Internet your wonderful proprietary butt on HTTP, in which there may be thousands of vulnerabilities. You do not need to set SSH access to the server or network equipment, if you do not want bruteforce to pour on you, and you do not need to directly publish RDP to the target stations (hello, esteemaudit). If you have doubts about a specific application to which you need to provide access, place it behind a VPN.
We’ve figured out the publication of resources, let’s move on to services whose access to which we couldn’t publish. To do this, we need to organize a VPN.
What should be considered when organizing a VPN?
First of all, evaluate whether you can quickly deploy VPN client software in the workplace, or better use the Clientless approach. Do you have a VPN gateway or firewall with the ability to organize remote access?
If, for example, you have a Fortinet or Check Point firewall with any bundle (NGFW / NGTP / NGTX) in your network, congratulations, IPsec VPN functionality support comes out of the box, and you do not need to buy or install anything additional. All that remains is to put clients at workplaces and configure a firewall.
If right now you don’t have a VPN gateway or firewall, look towards open-source solutions (OpenVPN, SoftEther VPN, etc.) that can be deployed fairly quickly on any server, fortunately, step-by-step guides in The Internet is plentiful.
In addition, it is desirable that your VPN gateway integrates with AD / RADIUS for centralized account management. Also, do not forget to check the password policy and configure protection against brute force.
If you decide to follow the path of installing the remote access client to users’ workstations, you will need to decide which VPN mode to use: Full Tunnel or Split Tunnel. If access for a particular group of users involves working with confidential or highly critical information, then I would recommend using Full Tunnel mode. Thus, all traffic will be driven into the tunnel, Internet access for users can be arranged through a proxy, if desired, traffic can also be listened through DLP. In other cases, you can restrict yourselves to the usual Split Tunnel mode, in which traffic is driven into the tunnel only to the company’s internal networks.
After successful user authentication, you should decide on the authorization: where to give users access, how and where to do it. There are several options.
- Direct access. The user received an IP address from his VPN pool and can go directly to the necessary resources (read – through the firewall). It should be noted here that if you have a simple L4 firewall on which access policies have already been configured (and there are many of them!), Then quickly adapting them to new IP address pools may fail. Even if you have NGFW with policies for users or user groups, logs in AD will not be fixed (unless you have a special client at each workplace), and policies will also not work. In this case, you will have to create policies directly on the VPN gateway or use RADIUS for authentication and integrate it with the firewall client to track user logs.
- Terminal access. If you have NGFW with user policies and a terminal server, then you can do so. When implementing terminal access (for example, using MS RDS), a user who has received remote access logs in to the terminal server. Install a special agent from the manufacturer of the firewalls (for example, FSSO TS) on it. This agent will tell the firewall the IP address of the logged-in user, as a result of which the written security policies for users or user groups will remain unchanged, and you will not have to rush to change policies to NGFW.
Are user jobs protected?
Let’s move on to workplace safety.
Evaluate the security of remote users’ workstations: do you give them workstations with a gold image installed with all the necessary security features (antivirus, host-based IPS / Sandbox, etc.), or do they sit from their home laptops with unknown software? If the answer to this question is home devices, then it would be better, after granting remote access, to drive traffic to NGFW with IDS / IPS, and ideally also to a network sandbox.
One of the good options is also to publish on VDI a specific application for work (browser, email client, etc.). This will allow access only to the specific applications used.
If your company does not allow the connection of removable media, then in the case of remote access, you should not forget about this, limiting this possibility for freshly issued corporate laptops.
As usual, make sure that unsafe protocols and services are disabled, it will be useful to turn on disk encryption (what if your user goes to work in coworking and his corporate laptop is stolen?), Do not forget to select privileged access rights (if the laptop is corporate).
Use centralized account management with remote access (AD / RADIUS), and also remember to consider scenarios in which your Identity Store will be unavailable (for example, create additional local accounts).
It is good practice to use client certificates, self-signed certificates can also be issued on Microsoft CA.
Assume that due to unforeseen circumstances, your remote users still have credentials removed. Two-factor authentication will help to cope with this scourge (OTP push on mobile devices, SMS). But I would not recommend two-factor authentication via corporate email (often for authentication with remote access the same accounts are used as in email, and, therefore, your second factor will be easy to pull out). If you need to quickly organize two-factor authentication, you can look in the direction of public services – for example, Google Authenticator.
Consider how your IT department will operate remote workstations and help users solve everyday problems. Explicitly, remote support staff will need remote access to user workstations.
It is advisable that the workstations “spill over” from the golden image, and you do not have to try to restore the home computers of the employees due to the fact that they installed something wrong, or, what good, caught some ransomware. It is better to give out corporate laptops with pre-known capacities and the composition of the installed software so as not to get a headache with home PCs of employees, because they can be used by children, the system may wildly slow them down or there may not be necessary protective equipment.
It will be useful to remind users before moving on to remote work that the company has existing security policies: you never know how an ordinary user wants to relax at lunchtime at home.
Checklist: make sure you haven’t forgotten anything to make remote access secure
- Publish the necessary web resources safely and wisely (use WAF, check passwords, check the freshness of the OS, CMS).
- Scan for vulnerabilities (using your own vulnerability scanners or public scanners).
- Provide access to internal resources via VPN (do not expose RDP / SSH or applications with which data exchange within the network is not protected).
- Publish specific applications through VDI (Citrix, VMware).
- Set up two-factor authentication (OTP push on mobile devices, SMS).
- Do not forget to take into account the existing configured security policies on the firewalls (adapt them for remote access users or take advantage of the combination of NGFW with ID FW policies and a terminal server).
- Give users corporate laptops for use instead of home PCs (make sure that all necessary security features are installed and updated, that users have their rights selected, password policies are respected, the OS is up-to-date and patched).