Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

Tech Insight: Protecting Against Risks Posed By Anonymization Tools

Snowden and NSA concerns are causing more users to seek anonymization and encryption tools that could cause security headaches for enterprises

The news about Edward Snowden and the NSA's PRISM program has generated an increased interest about encryption and anonymizing tools. More and more people are interested in covering their tracks and making sure that the "watchers" can't watch them. Sites like PRISM-break.org are encouraging the use of nonproprietary Web browsers and anonymizing tools like Tor. While these things are great for personal use, they can cause security issues for enterprises.

One of the primary tenets of information security is knowing what's happening within your network. Without an understanding of the hosts on the network and the traffic traversing it, security groups are essentially running blind. Network security monitoring (NSM) focuses specifically on providing that visibility, but anonymizing services and applications create a blind spot for security pros looking to identify attacks and prevent data exfiltration.

In order to combat unregulated anonymization and encryption software usage, enterprises need to address the issue from several fronts. This begins by conducting a risk assessment centered on controls related to these technologies, and might ultimately lead to creating new policies and amending current ones, providing user awareness training, and implementing new technical controls.

The purpose of the risk assessment is to determine whether the usage of these types of software is a concern for the business. There are several legitimate reasons why anonymizing software might be used for legitimate purposes in a business environment. The new Tortilla software, to be released by CrowdStrike during Black Hat Las Vegas, is a tool that security teams can use for malware analysis and intelligence gathering. However, it is a piece of software that should only be on the workstations of those individuals responsible for that activity and not on the CFO's administrative assistant's computer.

Conducting a risk assessment should answer questions around legitimate use, impact on network visibility, and potential for data loss. Once those questions are answered, an enterprise must then decide how much effort is needed to adjust policies, enhance user awareness, and implement technical controls to address the identified risk.

Policies need to be created or modified so that they clearly explain whether anonymizing and encryption software is allowed and who was allowed to use it. In the average corporate environment, anonymizing software should not be used by anyone outside of the security team, and only corporate-approved encryption software should be allowed. If the company is protecting its endpoints like it should, then end users should not even have the ability to install these types of software on their workstations. Policies should explicitly state approved use cases so there is no question regarding what constitutes proper use.

Once the policies are updated, user awareness training updates should also take place -- that is, if there is a program in place already. The update should be minimal and fit into existing verbiage on what is considered authorized software. If encryption is in use within the enterprise, training for the use of that software should be updated to reflect that only authorized encryption software should be used.

Having defined authorized software and use-case scenarios, it's time to implement the appropriate technical controls. Depending on what security protections are in place already, there could be very little that needs to be done, or there could be quite a lot. For example, many corporate environments restrict administrative permissions on end-user workstations. Users have no permission to install software. This control will prevent the use of most anonymizing and encryption software tools like Tor and, most likely, the Tortilla tool once it is released.

Restricting administrative rights isn't enough, though. Users might find it possible to still use tools that are standalone, or Web-based, and do not require installation. In that case, application whitelisting can be used to prevent those unauthorized pieces of software from being run. Also, some antivirus solutions will detect software like TorBrowser as malicious and alert on it when detected.

At the network layer, there are numerous ways to go about detecting and/or blocking anonymized and/or encrypted traffic. For example, most intrusion detection/prevention systems (IDS/IPS) and next-generation firewalls (NGFW) have the ability to detect Tor traffic with simple signatures and block known proxy sites. Published Tor entry relays and exit nodes can be blocked at the firewall, and application layer proxies can inspect traffic and only allow through what is permitted by policy. Likewise, egress filters should only permit allowed internal IP addresses to communicate outbound using specific ports and protocols.

Depending on the level of risk identified during the risk assessment and because Tor traffic often uses TCP port 443 (most commonly used for HTTPS), some companies may decide to also perform inspection of SSL traffic through an application proxy. This will, of course, raise some privacy concerns because it could expose encrypted, personal information to security team members monitoring traffic. It also requires that all computer systems have the SSL certificate from the proxy on their systems in order to make the process seem transparent since SSL traffic inspection essentially breaks the trust chain. The decision to do so will need to be discussed thoroughly between legal, management, and IT.

It's important to remember that it may still be possible for a skilled and determined attacker to get around some of the controls outlined above, but it will stop the majority of employees. The question that an organization must ask itself is what is it trying to protect against, and base the risk assessment around that question and what impact anonymizing technologies could have on the security of its data.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.2.0, BinaryHeap is not panic-safe. The binary heap is left in an inconsistent state when the comparison of generic elements inside sift_up or sift_down_range panics. This bug leads to a drop of zeroed memory as an arbitrary type, which can result in a memory ...
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, String::retain() function has a panic safety problem. It allows creation of a non-UTF-8 Rust string when the provided closure panics. This bug could result in a memory safety violation when other string APIs assume that UTF-8 encoding is used on the sam...
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, VecDeque::make_contiguous has a bug that pops the same element more than once under certain condition. This bug could result in a use-after-free or double free.
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.50.0, read_to_end() does not validate the return value from Read in an unsafe context. This bug could lead to a buffer overflow.
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.52.0, the Zip implementation has a panic safety issue. It calls __iterator_get_unchecked() more than once for the same index when the underlying iterator panics (in certain conditions). This bug could lead to a memory safety violation due to an unmet safety r...