InfoSec News

DoD

National Security Agency releases Securing IPsec Virtual Private Networks

By

InfoSec News

By William Knowles @c4i
Senior Editor
InfoSec News
July 3, 2020

On the heels of the tweet from USCYBERCOM earlier in the week advising users of Palo Alto Networks to patch all devices affected by CVE-2020-2021 immediately, especially if SAML is in use. On Thursday, the National Security Agency released Securing IPsec Virtual Private Networks.

Many organizations currently utilize IP Security (IPsec) Virtual Private Networks (VPNs) to connect remote sites and enable telework capabilities. These connections use cryptography to protect sensitive information that traverses untrusted networks. To protect this traffic and ensure data confidentiality, it is critical that these VPNs use strong cryptography.

This guidance identifies common VPN misconfigurations and vulnerabilities.

Maintaining a secure VPN tunnel can be complex and requires regular maintenance. To maintain a secure VPN, network
administrators should perform the following tasks on a regular basis:

  • Reduce the VPN gateway attack surface
  • Verify that cryptographic algorithms are Committee on National Security Systems Policy (CNSSP) 15-compliant
  • Avoid using default VPN settings
  • Remove unused or non-compliant cryptography suites
  • Apply vendor-provided updates (i.e. patches) for VPN gateways and clients

Reduce the VPN gateway attack surface

VPN gateways tend to be directly accessible from the Internet and are prone to network scanning, brute force attacks, and zero-day vulnerabilities. To mitigate many of these vulnerabilities, network administrators should implement strict traffic filtering rules to limit the ports, protocols, and IP addresses of network traffic to VPN devices. If traffic cannot be filtered to a specific IP address, NSA recommends an Intrusion Prevention System (IPS) in front of the VPN gateway to monitor for undesired IPsec traffic and inspect IPsec session negotiations.

Verify only CNSSP 15-compliant algorithms are in use

All IPsec VPN configurations require at least two items: (1) the Internet Security Association and Key Management Protocol (ISAKMP) or Internet Key Exchange (IKE) policy; and (2) the IPsec policy. If the cryptography on either of these policies is configured to allow obsolete cryptographic algorithms, the entire VPN is at risk and data confidentiality may be lost. Annex B of CNSSP 15 provides guidance on using strong cryptography [1]. As the computing environment evolves and new weaknesses in algorithms are identified, administrators should prepare for cryptographic agility: periodically check CNSSP and NIST guidance for the latest cryptographic requirements, standards, and recommendations.

When configuring ISAKMP/IKE, many vendors support having several possible ISAKMP/IKE policies. The device then chooses the strongest matching policy between the remote and local ends of the VPN. Some vendors do this through priority numbers and others through explicit selection. NSA recommends configuring only those policies that meet the minimum level of security and removing any legacy policies. Also, if priority numbers are used, the strongest ISAKMP/IKE policy should be the highest priority. Many vendors also support configuring multiple IPsec policies; however, these policies are normally explicitly configured for a specific VPN. NSA recommends utilizing the strongest cryptography suites supported by the network device.

The best way to verify that existing VPN configurations are using approved cryptographic algorithms is to review the current ISAKMP/IKE and IPsec security associations (SAs). NSA recommends using this approach when reviewing ISAKMP/IKE and IPsec configurations because it displays the exact cryptography settings that were negotiated. Otherwise, administrators may miss connections where a device is selecting a non-compliant algorithm that was a device default or left over from a previous VPN configuration. If SAs are identified with non-compliant algorithms, administrators should immediately investigate why the VPN negotiated a lower cryptography standard and make appropriate configuration changes. Also, if utilizing pre-shared keys for VPN, NSA recommends that all keys be replaced as they may be compromised.

Avoid using default VPN settings

Due to the complexity of establishing a VPN, many vendors provide default configurations, automated configuration scripts, or graphical user interface wizards to aid in the deployment of VPNs. These tools take care of setting up the various aspects of a VPN to include ISAKMP/IKE and IPsec policies. However, many will configure a wide range of cryptography suites to ensure compatibility with the remote side of a VPN. NSA recommends avoiding these tools as they may allow undesired cryptography suites. If these tools are used, evaluate all configuration settings that the tool deployed. Administrators should then remove any non-compliant ISAKMP/IKE and IPsec policies. As a best practice, administrators should not utilize any default settings and ensure that all ISAKMP/IKE and IPsec policies are explicitly configured for the CNSSP 15-compliant algorithms.

Remove unused or non-compliant cryptography suites

It is very common for vendors to include extra ISAKMP/IKE and IPsec policies by default. These extra policies may include non-compliant cryptographic algorithms. Leaving extra ISAKMP/IKE and IPsec policies as acceptable policies creates a vulnerability to downgrade attacks. In downgrade attacks, a malicious user or Man-in-the-Middle offers only obsolete cryptography suites and forces the VPN endpoints to negotiate non-compliant cryptography suites. In doing so, it leaves the encrypted VPN vulnerable to decryption. Verifying that only compliant ISAKMP/IKE and IPsec policies are configured and all unused or non-compliant policies are explicitly removed from the configuration mitigates this risk. NSA also recommends periodically validating that only compliant policies are configured as the use of automated tools, graphical interfaces, or user error could reintroduce these non-compliant policies.

Apply vendor-provided updates

After ensuring that all configuration settings are using compliant cryptography suites and removing all non-compliant suites, implement a robust patch management procedure. Over the past several years, multiple vulnerabilities have been released related to IPsec VPNs. Many of these vulnerabilities are only mitigated by routinely applying vendor-provided patches to VPN gateways and clients. Many network equipment vendors allow customers to sign up for notification emails for new security alerts. These notifications are an excellent way to stay up-to-date on relevant out-of-cycle patches.

Protect the essential

VPNs are essential for enabling remote access and securely connecting remote sites, but without proper configuration, patch management, and hardening, VPNs are vulnerable to attack. To ensure that the confidentiality and integrity of a VPN is protected, reduce the VPN gateway attack surface, always use CNSSP 15-compliant cryptography suites, avoid using vendor defaults, disable all other cryptography suites, and apply patches in a timely manner.

Works Cited

[1] “Use of Public Standards for Secure Information Sharing.” Committee on National Security Systems, 20 October 2016. [Online] Available at https://www.cnss.gov/CNSS/issuances/Policies.cfm

Related Guidance

Appendix A: Reducing VPN Gateway Attack Surface Examples

Defense Contractor Compromised with MAZE Ransomware

By

InfoSec News

Westech MAZE Ransomware Compromise; InfoSec News asks an Expert About the Fallout

By William Knowles @c4i
Senior Editor
InfoSec News
June 8, 2020

Troubling Cybersecurity/National Security news via Sky News, which is reporting that criminal hackers have stolen confidential information from Westech International. Westech serves as a U.S. military contractor for a number of Washington D.C. based companies such as Northrop Grumman, Booz Allen Hamilton, General Dynamics Information Technology (GDIT), and Science Applications International Corporation.

Westech International provides U.S. government and military clients a wide of services like Testing and Evaluation for the Army Intelligence Electronic Warfare Test Directorate, Mission Systems Support (T&E MSS) to The Joint Interoperability Test Command (JITC), Cybersecurity and unsecured and secured network support for Intelligence Electronic Warfare Test Directorate at Fort Huachuca, AZ and supports the ICBM Ground Subsystem Support Contract (GSSC) for the Minuteman III ICBM project.

A spokesperson for Westech told Sky News that Westech International has confirmed that it been breached and that its computers have been encrypted. “We recently experienced a ransomware incident, which affected some of our systems and encrypted some of our files,” Westech said in a media statement.

A number of news outlets are saying Westech International’s computers were encrypted with the MAZE ransomware, I asked Dan Wolfford, Co-founder & CTO of Dyrwolf, which is the first and only ransomware prevention & recovery platform to help organizations of all sizes protect their data, on his impressions of the MAZE ransomware.

“We believe the group behind MAZE is a ransomware merchant with a strong record of success and a good reputation of keeping up their end of the deal. They also have an interesting revenue sharing strategy, where they pay affiliates a commission for attracting potential customers with their software. We started tracking them in our threat database last year, after researching FALLOUT and SPELEVO exploit kits.”

What is the likelihood of a payload being added to MAZE to jump networks within the organization as has been reported lately?

“This merchant and their affiliates have proven to be creative and adaptive, using malicious ads, traffic redirection, exploit kits, email campaigns, fake websites, fake cryptocurrency apps, browser exploits, impersonation, data exfiltration, and leak extortion. Based on past performance, we believe it is highly likely they will continue to innovate in this space, adding new tactics and techniques to maximize profits.”

Does Westech International have a SIPRNet network connection?

“Most likely yes, because the Defense Information Systems Agency (DISA) Secret IP Router Network (SIPRNet) is available to mission partners and according to Shawn Purvis (Vice President and General Manager, Cyber Division, Northrop Grumman Information Systems), Northrop Grumman is proud to be DISA’s trusted partner.”

InfoSec News has reached out to Westech for further details and comments about the cyberattack including the timeline of the attack, attack vector(s), which cyber-security frameworks they use, and whether or not Westech International paid the ransom. If the attackers or malware they are using has the capability to move laterally, it is conceivable that it could reach a system connected to SIPRNet.

Westech International is a Woman-owned small business founded in 1995 by Dr. Betty Chao and based in Albuquerque, New Mexico.

National Security Agency releases guide to secure video conferencing

By

InfoSec News

By William Knowles @c4i
Senior Editor
InfoSec News
April 29, 2020
[Updated: June 21, 2020]

Last Friday, the National Security Agency released a guide aimed mainly towards U.S. Government employees and military service members are working from home, but is also ideal for business professionals on Selecting and Safely Using Collaboration Services for Telework.

This cybersecurity guidance contains a snapshot of current, commercially-available collaboration tools available for use, along with a list of security criteria to consider when selecting which capability to leverage. In addition, the guidance contains a high-level security assessment of how each capability measures up against the defined security criteria, which can be used to more quickly identify the risks and features associated with each tool.

Criteria to Consider When Selecting a Collaboration Service

The criteria below identify risks and features to consider when choosing collaboration services to support your mission. All criteria should be strongly considered but may not be fully supported based on your own operating environment and constraints. The criteria are intended to align with related USG guidance to include NIST SP 800-171r2 – Protecting Controlled Unclassified Information in Non-Federal Systems and Organizations (Feb 2020) and NIST SP 800-46r2 Guide to Enterprise Telework, Remote Access and BYOD Security (Apr 2016).

1. Does the service implement end-to-end encryption?

End-to-end (E2E) encryption means that content (text, voice, video, data, etc.) is encrypted all the way from sender to recipient(s) without being intelligible to servers or other services along the way. Some apps further support encryption while data is at rest, both on endpoints (e.g. your mobile device or workstation) and while residing on remote storage (e.g. servers, cloud storage). Only the originator of the message and the intended recipients should be able to see the unencrypted content. Strong end-to-end encryption is dependent on keys being distributed carefully. Some services such as large-scale group video chat are not designed with end-to-end encryption for performance reasons.

2. Are strong, well-known, testable encryption standards used?

Even in the absence of end-to-end encryption, NSA recommends the use of strong encryption standards, preferably NIST-approved algorithms and current IETF secure protocol standards. Many collaboration services protect data-in-transit between clients and servers via the Transport Layer Security (TLS) version 1.2 (or later) secure protocol, which is commonly used for sensitive but unclassified information. The use of published protocol standards, such as TLS and DTLSSRTP, is preferred. If the product vendor has created its own encryption scheme or protocol, it should undergo an independent evaluation by an accredited lab. This includes not just cryptographic protocols, but also key generation.

3. Is multi-factor authentication (MFA) used to validate users’ identities?

Without MFA, weak or stolen passwords can be used to access legitimate users’ accounts and possibly impersonate them during the use of the collaboration service. Multi-factor authentication requires that a second form of identification (code, token, out-of-band challenge, etc.) be provided to allow access to an existing account.

4. Can users see and control who connects to collaboration sessions?

The collaboration service should allow organizers to limit access to collaboration sessions to only those who are invited. This can be implemented through such features as session login passwords or waiting rooms, but preferably would support reasonably strong authentication. Users should also be able to see when participants join through unencrypted/unauthenticated means such as telephone calls.

5. Does the service privacy policy allow the vendor to share data with third parties or
affiliates?

While collaboration services must often collect certain basic information needed to operate, they should protect sensitive data such as contact details and content. Collaboration information and conversations should not be shared with third parties. This could include metadata associated with user identities, device information, collaboration session history, or various other information that may put your organization at risk. Information sharing should be spelled out clearly in the privacy policy.

6. Do users have the ability to securely delete data from the service and its repositories as needed?

While no services are likely to support full secure overwrite/deletion capabilities, users should be given the opportunity to delete content (e.g. shared files, chat sessions, saved video sessions) and permanently remove accounts that are no longer used.

7. Has the collaboration service’s source code been shared publicly (e.g. open-source)?

Open-source development can provide accountability that code is written to secure programming best practices and isn’t likely to introduce vulnerabilities or weaknesses that could put users and data at risk.

8. Has the service and/or app been reviewed or certified for use by a security-focused nationally recognized or government body?

NSA recommends that cloud services (which collaboration apps rely on) be evaluated under the Office of Management and Budget (OMB) FEDRAMP program. NSA also recommends that collaboration apps be evaluated by independent testing labs under the National Information Assurance Partnership (NIAP) against the Application Software Protection Profile (PP) [1]. NSA has worked with the DHS S&T Mobile Security R&D Program to develop excellent semi-automatable testing criteria for app vetting based on the application PP [2]. These criteria include tests of how apps interact with platform resources, how they defend themselves from exploitation, the crypto libraries they use, what permissions they request, and many others.

9. Is the service developed and/or hosted under the jurisdiction of a government with laws that could jeopardize USG official use?

Since it is well documented that some countries require that communications be provided to law enforcement and intelligence services, it may not be wise for certain USG missions to be performed on services hosted or developed under certain foreign legal jurisdictions. Users should be aware that the country of origin where products were developed is not always public knowledge. This criterion was not assessed in the table on page 5.

Selecting and Safely Using Collaboration Services for Telework. 

Unclassified and Secure

By

InfoSec News

By William Knowles @c4i
Senior Editor
InfoSec News
April 12, 2020

A new report from the RAND Corporation, by Daniel Gonzales, Sarah Harting, Mary Kate Adgie, Julia Brackup, Lindsey Polley, and Karlyn D. Stanley

The defense industrial base (DIB) is under attack. Foreign actors are stealing large amounts of sensitive data, trade secrets, and intellectual property every day from DIB firms — contributing to the erosion of the DIB and potentially harming U.S. military capabilities and future U.S. military operations. The U.S. Department of Defense (DoD) has taken steps to better secure systems against cyber threats, but most protections in place focus on classified networks, while unclassified networks have become an attractive entrance for adversaries seeking access to cutting-edge technologies and research and development efforts. To address this problem, DoD has increased regulations and introduced new security controls, but the current approach may be insufficient.

This report offers DoD a way ahead to better secure unclassified networks housing defense information — through the establishment and implementation of a cybersecurity program designed to strengthen the protections of these networks. The program offers a means for DoD to better monitor the real-time health of the DIB and ensure that protections are in place to prevent the disclosure of sensitive corporate information from DIB firms or sensitive supply chain information across the DIB. The program also includes a means to offer qualified small DIB firms access to cybersecurity tools for use on unclassified networks, for free or at a discounted rate, to ensure that affordable protections are accessible to all DIB firms. Advanced persistent threats and sophisticated cyber attacks will not stop, but this program can help build stronger defenses, develop more-coordinated responses, and help maintain the technological superiority of U.S. military forces.

Key Findings
DoD’s current approach to defending DIB firms against cyber attacks is inadequate

  • The cybersecurity architectures of small DIB firms are likely to be deficient in several key areas: user authentication, network defenses, vulnerability scanning, software patching, and security information and event management, or cyber attack response.
  • Current DoD cybersecurity requirements are unaffordable for many small and some medium-sized DIB firms.
  • DoD’s voluntary cyber threat sharing service is not available to many DIB firms.
  • New cybersecurity tools can significantly strengthen the cyber defenses of DIB firms, but most small DIB firms cannot afford them

Recommendations

  • DoD should establish a DIB Cyber Protection Program (DCP2) to improve the monitoring and real-time health of the DIB, improve cybersecurity for firms that cannot afford the needed CSTs and professional staff, and offer data and legal protections to DIB firms.
  • The DCP2 would be a voluntary program under which DoD would provide CSTs to DIB firms either free of charge or at significantly reduced licensing costs. In turn, the DIB firms would agree to provide sanitized data produced by the CSTs to a security operations center (SOC) — either one run by DoD or a trusted third-party SOC — devoted exclusively to defending the DIB.
  • The DIB SOC or commercial SOC would provide dynamic intelligence, security alerts, and recommended actions to DIB firms to identify and remediate advanced persistent threat incursions and to prevent the exfiltration of important information from the unclassified network of the DIB firm.
  • The DCP2 would enable real-time threat intelligence to be collected and synthesized across the DIB in ways currently not possible, while respecting the confidentiality and proprietary nature of DIB contractor supply chains.

Download the ebook for free here, or buy the paperback when its available from Amazon on May 15, 2020.

 

Navy Information Warfare

By

 

By William Knowles @c4i
Senior Editor
InfoSec News
October 29, 2019

As a ten-year regular volunteer at the USO O’Hare, there’s a sly grin on my face knowing all the U.S. Navy personnel featured in this video have visited the Terminal 2 center at least once in their careers and should make every InfoSec News reader happy these men and women are learning about information warfare, cybersecurity (both offensive and defensive) and wireless networking, among other security topics, nearly two years of college training over the span of six months.

Hat tip: Soldier Systems