News Database Security
Segmentation Can Increase Risks If Firewalls Aren't Managed Well
The multiplication of internal firewalls to comply with regulations and minimize risk to critical databases and applications has created a rat's nest of firewall configuration issues
SAN FRANCISCO -- RSA CONFERENCE 2013 -- As enterprises increasingly turn to network segmentation to limit exposure to sensitive applications and databases, the IT law of unintended consequences is rearing its ugly head. According to IT administrators, the very tools that allow them to create safe network zones -- namely, the firewalls -- are actually introducing a new crop of security and operation problems to the overall IT risk equation.
All of that slicing and dicing of the network has piled on more internal network firewalls than ever; with the constant flux in application and network configuration, it's not unheard of for enterprises to manage a snarled mass of hundreds of thousands to even millions of firewall rules settings on a daily basis. It's a task so overwhelming for a single firewall manager or even a team, who simply can't keep up.
More Security Insights
- Remote Data Replication: Combat Disasters And Optimize Business Operations
- Taneja Group: Overview of Virtualization and Cloud Market Vendor Landscape for SMBs
- Desktop and Application Virtualization Best Practices
- Banking on Results: Turn an Avalanche of Data into Actionable Insight
|Click here for more articles.|
"No human can look at that and know what the firewall is doing. Nobody can get a good feel for what traffic it's actually controlling," says Jody Brazil, president and CTO of Firemon, a firewall management firm. "All of a sudden, you started with a technology to limit risk, but you no longer know what risk that it's controlling."
Consequently, the act of segmentation that some enterprises have turned to for hardened security is actually introducing misconfiguration risks -- and even raising the potential for breaking revenue-generating applications critical to the business.
"The challenges faced by the firewall management team are so difficult, they simply don't have time to do everything they're supposed to do, and the only way they meet deadlines is to start cutting corners," says Ruvi Kitov, CEO of firewall management vendor Tufin Technologies. "They've got such tight deadlines that sometimes they make mistakes. And on a firewall, a mistake can be tragic."
Yesterday at RSA, Tufin released the results of a survey that showed how those shortcuts in manual firewall management processes are taking their toll on IT operations. In a poll of 200 administrators, approximately 62 percent reported that their firewall-rule change management processes put them at risk to be breached. According to firewall management experts, today's highly segmented networks, the addition of next-generation firewalls, and the necessary coupling of firewalls with specific application-centric network zones have pushed these tools well beyond their initial perimeter defense objectives.
"Back in the good, old days when there was just one firewall and the perimeter, if you needed to make a change or to enable something, you went to that firewall and put it in a rule or edited a rule, and that was it," says Nimmy Reichenberg, vice president of marketing and business development for AlgoSec, a firewall management automation firm. "Now if you want to enable some sort of connectivity from A to B on the network, just understanding what firewalls are in the path that you want to enable can be pretty complex."
As a result, many firewalls are often misconfigured with rules broader than necessary, says Brazil, who believes that part of the problem is at the feet of firewall vendors that have not offered administrators tools to create effective policies.
"They have provided fantastic tools to create rules. It's really simple to create a rule in one place and distribute [that rule\ across a huge firewall infrastructure," Brazil says. "But making sure that it is a correct rule, they've done a very poor job of."
This deficiency has particularly wreaked havoc in the highly dynamic applications world. According to Tufin's survey, a third of organizations make 100 or more application-related firewall changes a month. Approximately 55 percent of all organizations say that their application connectivity management processes might create unnecessary IT risk. And 47 percent say that application-related rule changes did or may have resulted in a breach. This tracks with a statement from Gartner last fall that through 2018, more than 95 percent of firewall breaches will be caused by firewall misconfigurations.
But not only are these firewall management woes greatly increasing the chances of data breaches and exposures, they're also gumming up the operational works in the application delivery life cycle.
"Ramping up a new business application takes a lot of time. That's on the business agility or operations side. The flip side is when that application is decommissioned, the access it needs is not going to go away," says Reichenberg, adding that before one of his financial customers started using firewall management automation, it had to make its applications teams wait a full 30 days before any new applications went live in order to check on firewall rules and interdependencies. "Because of this complexity, everybody is afraid to remove the firewall rules because god knows what you're going to break. If I move the extra application A, application B might stop working as well. I have no idea how this interrelates and interconnects."
According to the Tufin survey, about 42 percent of respondents track application connectivity changes through the comments section of the firewall rule base, and approximately one in six organizations don't even track these changes at all. This is causing downtime and disruption in many critical applications throughout the enterprise. Approximately 70 percent of survey respondents experience application service disruptions up to 20 times per year due to firewall configuration changes.
"For example, we've seen cases where somebody made a configuration mistake, a bank's ATM system went down, and several thousand ATMs were down for a day until they found the configuration error," Kitov says. "You can imagine how painful that was for the IT department and how much revenue they lost as a result."
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.