How USPS merges compliance, security in its huge enterprise

With more than 35,000 facilities operating across the country, understanding the U.S. Postal Service’s networks — let alone securing them — is a major challenge.

“One of the things that frustrated me was, when we looked at how we implemented firewall rules, I could never tell what I had allowed and I hadn’t allowed,” said Chuck McGann, corporate information security officer for USPS.

Keeping track of firewall policy sounds like a simple task, but rules tend to build up over time and changes are not always properly documented. Rules can contradict and supersede each other, leaving security status unclear.

“When you have 125,000 firewall rules, that’s the difficulty,” McGann said. “The manual labor involved is incredible,” to manage these.

In his quest for visibility, McGann tested the RedSeal 6 network monitoring platform to evaluate firewall rules and liked what he saw. Originally intended to help with compliance audits for Sarbanes-Oxley Act and Payment Card Industry security requirements, the evaluators decided the platform could be used to improve operational security and overall situational awareness. “It’s a security tool, a compliance tool, a management tool and an incident response tool,” McGann said.

RedSeal is a monitoring tool intended to help protect networks from “drift” between audits when systems are periodically assessed for compliance to security regulations. A system that is in compliance at one point can quickly move away before the next audit. RedSeal builds a topology map of the network and uses data from vulnerability scans to assess risks and prioritize fixes. Known vulnerabilities are categorized according to their seriousness, but the actual risk they pose also depends on their location in a network and the network architecture. 

Although the platform is offered through the Homeland Security Department’s Continuous Diagnostic and Mitigation program, like most tools of this kind it is not truly continuous. It generates periodic snapshots of a network’s condition, but does it often enough to provide useful information in maintaining security.

“Most of our large customers do it on a daily basis,” said Kimberly Baker, public sector general manager for RedSeal Networks.

This provides greater assurance of ongoing security while maintaining regulatory compliance, which falls in with the shift in the federal government toward making compliance a byproduct of operational security.

The Postal Service is a hybrid animal in terms of regulatory requirements: Not quite government and not quite private sector. Its networks operate in the .com domain (usps.com) rather than in .gov, but it reports to Congress. In its annual report for 2012, USPS claims more retail locations than McDonalds and Starbucks combined. (That number includes kiosks and third-party retailers that sell postage stamps and other USPS products.)

“We are not required to comply with FISMA,” the Federal Information Security Management Act, McGann said. “However, we have made the decision that we would align our policies with FISMA as closely as financially possible. I always thought that FISMA was a viable measuring stick” for security.

A recent gap analysis found that “we are not far off” from meeting FISMA demands, he said.

As a major retailer that accepts credit cards, the Postal Service is bound by the Sarbanes-Oxley Act for accounting in public companies and PCI security requirements. These were the drivers for implementing RedSeal in 2012. The initial plan was to get a software license for the platform, but McGann said he was leery about committing to a deal that could require a long ramp-up time before returning value. “I’ve seen way too much of that in this environment,” he said.

The solution was to get it as a service from the vendor with the guarantee that USPS would pay only if it performed. One of the first payoffs was the discovery of about 80,000 firewall rules that could be eliminated. “It helped us clean up the environment,” McGann said.

RedSeal works by first gathering configuration files from all Layer 3 (of the OSI network model) devices on the network. This can be pulled from the network itself or imported manually to a server that is not running on the network. This data is used to model the network and build a map that not only shows the devices, but how devices can connect with each other.

“That’s the foundation of complete end-to-end visibility,” Baker said.

Vulnerability data then is imported from scanners already running on the network. This data is analyzed and displayed graphically, showing the potential impact of vulnerabilities depending in part on the connectivity of the devices where they are found. McGann said significant exposures have been found on apparently insignificant devices in the USPS network that, if ignored, could have opened a path to thousands of servers. It also has been incorporated into incident response by letting analysts see the connectivity of devices that might be compromised. This can tell where to look for malicious traffic, and what other devices to check for possible infections.

“This tool gives us a lot more visibility into what is happening on the network,” he said. “It started giving us a knowledge base that we previously hadn’t had.”

Mapping and analysis is done daily, although the entire network is not covered every day. “We parsed it out into multiple subnets,” he said. “Over the course of 30 days we have mapped the entire environment at least once.”

Is that often enough? “For right now, once a month is good,” McGann said. “But my goal would be once a week.” For the time being, that goal remains a desire with no firm deadline. But as the network is cleaned up over time, mapping and analysis can go more quickly and the goal might be achievable.