Like all security managers, I work to implement the right tools to defend against specific threats. Sometimes, however, a tool implemented for one purpose might be valuable in other ways.
About two years ago, we installed a Web-filtering application that blocks user access to selected Web site categories. The business objectives we needed to meet included preventing employee access to sites that might either prompt complaints of a hostile work environment (e.g., pornography or hate sites) or allow workstations to browse to sites with known malicious intent. The software worked well, and we successfully met our business objectives.
Recently, our human resources department requested that we check daily for patterns of unwanted Internet behavior. In other words, they want to know if someone is making repeated attempts to visit sites that are illegal. Identifying patterns of behavior helps identify employees who are intentionally attempting to connect to prohibited sites. Although most sites are blocked, there is a delay between the time a site goes live and the point at which the Web-filtering vendor adds the URL to the filtering database.
This was an easy request to fulfill. When the Web-filtering software blocks a site, it logs the URL, the computer name and IP address, date, time, and other general information. I had one of my analysts develop a script that checks the Web filter log and uses thresholds to report possible misuse. When we placed the script into production, it worked as expected — with one added benefit.
We identified several workstations that, during a seven-day period, had each attempted more than 1,000 prohibited connections. In fact, one PC had attempted more than 5,000. Analysis of the blocked sites showed that in each instance there were a limited number of malicious sites listed as targets. Further, the attempts were typically made during specific time periods. The result was a connection attempt every 1.5 seconds.
What we had found were several workstations that had been compromised and were attempting to call home. The problem wasn’t systemic. Out of more than 20,000 workstations, we discovered less that 10 that required attention. However, this incident confirmed that no defensive point solution, even when integrated into a layered defense, is 100 percent effective.
We have an active, automated patching program. Antivirus software is centrally managed, with updates made almost immediately upon release by the vendor. At least three layers of e-mail filtering exist with solutions from multiple vendors. Finally, the compromised systems run a local service that prevents the execution of malicious code, including spyware. With all this, we still ended up with a small percentage of compromised systems that weren’t identified through our standard processes.
The moral of this story is the need to think outside the box when implementing security solutions. All too often we focus on the objectives defined for the current system implementation without stepping back and asking how it might help support business objectives supported by other network defense tools. In this situation, we accidentally stumbled on another weapon to fill an apparent gap in our defenses. Future implementations of security solutions will include a careful analysis of possible secondary benefits.