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.