As companies shift to remote work amid COVID-19, attackers could exploit the situation to leave companies dead in the water by targeting the very tools that allow them to function. To minimize the threat, security teams must harden defenses around three areas:
Virtual private networks (VPNs):
- Paying special attention to the engineering/capacity required to support more employees for longer stretches of time.
- Ensuring infrastructure is protected against common attacks like distributed denial-of-service (DDoS) and credential-based campaigns.
- Configuring audio/video conferencing services like WebEx, Zoom and GoToMeeting to a federated identity token (SAML or JWT).
- Configuring a company’s Active Directory (AD) domain services to create these tokens for remote laptops/desktops.
- Making sure tools like Slack or Teams integrate with your company’s federated identity services.
- Using strong transport encryption like TLS 1.2 and data-at-rest encryption to protect messages on service providers servers.
VPN Capacity and Availability
For many companies, current VPN infrastructure was sized for a small number of users and is likely far smaller than needed during a disaster or emergency.
With so many more employees working from home, companies must perform a capacity analysis to ensure VPN infrastructure can handle the extra load. To that end:
- Companies must avoid single points of failure and be sure key components are engineered for both redundancy and fail-over (e.g., activate-activate failover or activate-passive failover).
- They should make sure they test their failover capabilities often.
- VPN vendors can help and most have documentation outlining the steps and architecture needed to ensure VPN infrastructure availability.
VPNs should be included in BC/DR plans:
- If a backup data center is part of the corporate BC/DR plan, the VPN infrastructure must also be included and accounted for within that data center.
- Although not every single point of failure can be eliminated, processes and procedures must be developed so normal business operation can be restored as soon as possible.
Protect Against DDoS Attacks
DDoS is especially an issue for VPNs because most solutions have clients connect via a specific URL. Just like any other corporate website or critical web application, the VPN URL is subject to such attacks.
To mitigate this:
- Check with your internet service provider (ISP) to see what DDoS protection services it offers and which third companies it works with.
- Consider contracting with third-party content delivery networks (CDNs) like Akamai, Cloudflare or Radware for additional protection.
Protect Against Social Engineering Attacks
With most VPNs, users authenticate with a password and one-time passcode (OTP) generated from a hard or soft token that changes every minute. In the past, attackers have used social engineering tactics to trick users into revealing both the password and the OTP.
This can be prevented by using certificates created by AD domain controllers to provide two-factor authentication (2FA) into the VPN. To do this:
- The VPN infrastructure must first be configured to use the AD public certificate as the authentication method so that the VPN infrastructure will validate and trust the AD public certificated created by the AD domain controller. This can be done in two ways:
- Use a TLS connection: One method is to configure the VPN controller to send the client AD public certificate to the AD domain controller over a TLS connection. The AD domain controller will validate the certificate and return status to the VPN controller. This method can be slow because it requires a network message be sent between the VPN server and AD domain controller, but that should not be an issue since the messaging happens during the VPN connection phase only, not for every transaction.
- Install the private AD certificate onto the VPN controller. While this method is faster, it is less secure, since it requires the AD private certificate to be on servers other than the AD domain controller.
Next, the AD public certificate must be associated with the VPN users. When a user first logs into a laptop on the corporate network that is part of the domain:
- The AD domain controller creates an AD public certificate and stores it in that user’s keystore.
- Information about the device and the user is stored in the optional part of the AD public certificate. This way, information about the user and device can be logged by the VPN infrastructure when the device connects to the VPN controller. It also provides information about which users and which devices are using the VPN to ensure the VPN infrastructure has the capacity to support the number of users.
Next, the VPN client must also be configured to use the AD public certificate from the keystore as its authentication method. This is normally done by importing the AD public certificate into the VPN client.
Once that is all configured, employees simply log into their laptops using their AD credentials. When they start the VPN client, it will:
- Obtain the AD public certificate from the user (employee) keystore and send the public certificate to the VPN controller for authentication.
- The VPN controller will then validate the certificate before allowing connection to the company internal network.
This setup provides 2FA because the AD public certificate is only accessible after employees have authenticated using their AD credential from a known device with a known certificate. In addition to being easy and friction-less for employees, this method offers a high level of security.
VPN-Specific Baselines to Review
With everything in security, it is the little things that cause breaches. The following are items first-time VPN users should think about and longtime VPN users should review:
- Policies: Organizations should ensure the following are properly documented so both the company and its employees are clear on all corporate remote work policies:
- Which employees may work remotely. Are only critical employees within each department allowed or are all employees allowed/expected to work remotely?
- When employees are allowed to work remotely. Is remote work allowed only by exception or in times of crisis? Is remote work supported only during business hours?
- What sensitive information may or may not be accessed remotely. This will change over time so be flexible.
- Accessible use policy. This should cover both the laptop and any other equipment required to work remotely.
- Personal use. What personal use is allowed for cellphones and tablets when working remotely? This should be similar to your onsite work policy.
- Printing. What documents can be printed when working remotely? How should such documents be handled after use (e.g., shedding)?
- Communication: Document how remote employees should communicate with each other and with customers:
- Voice calls: Will employees use a softphone on a company laptop or their personal cellphone?
- Audio conferencing: What audio conferencing call service should be used (if any)?
- Video conferencing: What video conference call service should be used (if any)?
- Instant messaging (IM): Which service should be used (if any)?
Protect Audio/Video Conferencing Systems
Audio and video conferencing services like WebEx, Zoom and GoToMeeting are also likely targets during the COVID-19 pandemic. To protect them:
- Use a federated identity token such as Security Assertion Markup Language (SAML)or JSON Web Token (JWT). To do this:
- Configure your AD domain services to create one of these tokens and provide it to your laptops/desktops.
- The service’s client can then use these tokens to identify the user and allow access. Overall, the use of a federated identity token should be the same in the office as for remote work.
- Use split-tunneling. All audio and video conferencing services are accessible via the internet, so it doesn’t make sense to go through the VPN connection only to be routed back out to the internet. In fact, forcing something like WebEx or Zoom through the VPN only adds latency, which can quickly render these services unusable for end users. Split-tunneling, however, routes the services’ traffic through the home user’s ISP and not the VPN. Most VPN clients can be configured to do this.
Protecting Instant Messaging (IM) Platforms
Finally, when deciding on which collaboration platform to use – be it Slack, Teams, Trello, etc. – it’s important to consider the following key security requirements:
- Authentication. Make sure the tool supports your federated identity services (SAML or JWT).
- Personal/professional separation. Make sure the tool can keep personal texts/IMs separate from company communications. You wouldn’t want employees to be able to forward a company text/IM to their friends.
- Encryption. Strong transport encryption like TLS 1.2 should be used, as should data-at-rest encryption so that messages on the service provider’s servers are protected. To do this:
- Revoke the data-at-rest encryption keys. This makes the messages unreadable to the service provider.
- Manage the keys carefully. Be sure to monitor and track anyone who accesses the data-at-rest encryption key.
Remote Work and COVID-19: A Security Checklist, March 19, 2020
COVID-19 and the Cloud: Enabling Remote Work and Business as Usual, March 11, 2020
Poll: Likely COVID-19-Themed Attack Vectors, March 17, 2020
Any views or opinions presented in this document are solely those of the Faculty and do not necessarily represent the views and opinions of IANS. Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our written reports, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by the client in connection with such information, opinions, or advice.