Saturday, October 23, 2004

So called firewalls

Because of this, today I'm venting about "firewalls" and "security".

"Firewall" is a term which has been hijacked by companies selling everything from NAT boxes to add-on software to content filtering appliances for e-mail. (Yes, it's the old layer 3/4 vs. Layer 7 argument vent again!) A proper firewall involves a bastion host (the hardware, software and services stripped to the bare minimum to function and then configured to running in a specific manner) running very specific services which provide the maximum possible control on protocols and services that your users (via management) cannot live without.

As a general rule of thumb for deciding how to handle a request for a protocol:

  • disallow the protocol
  • if you can't disallow it, proxy it (Layer 7) with a dedicated proxy to control the protocol's options and heavily log the protocol's use (who, what, where, when, how long)
  • if you can't do that, proxy it (Layer 7) with a generic proxy to limit the source/destination IP's and the directions that the requests can be made and log as much as possible
  • if you can't do that, reconsider disallowing the protocol
  • if you can't do that, consider using a many-to-one NAT box (yeah, a LinkSys box) and log as much as possible
  • if you can't do that, reconsider disallowing the protocol
  • if you can't do that, (as a last resort) use a packet filter (Layer 3/4) to limit source/destination IPs/ports and log as much as possible

That last method is the most dangerous. It's a horrible (but widely used) practice. If you used it for your web traffic, all an attacker would have to do to map your network would be to source his scans from port 80 and scan for ports greater than 1023 (hint: MS boxes listen on a LOT of ports above 1023). Yes, it's an oversimplification and there are many mitigating factors. There are also factors that worsen the situation (such as OS's or firewall programs that "leak").

You should seriously consider NOT using any Layer 3/4 filtering product that uses "packet inspection" and "state inspection" and claims the product will "provide the same capabilities as Layer 7 proxying". If it were the same, it wouldn't need all of the hype.

This practice (or the lack of it) is part of what's behind the new laws that are coming out. Businesses perverted the risk model (risk = threat x vulnerability) by adding in a financial vector (risk = threat x vulnerability x asset cost) and applied it to information security, failing to recognize the difference between a business risk and a security risk. This is why laws such as GLB, Sarbox, FISMA, California's SB 1386 and the like come into being. It is government stepping in and reinforcing the difference between the two types of risk.

Some say that the function of the federal government is to provide those functions that local or state government cannot or will not. In this case, it's probably going to prove true. Because a company is willing to treat a security risk as a business risk, just to maintain a profit, it puts everyone even remotely associated with that company in danger. Thus, the need for federal legislatures to "step in".

Currently the laws are very generic, requiring that a program or role exist within a company. Insurance companies are helping somewhat, giving discounts to subscribers who "meet or beat" the insurer's standards. However, if the majority of corporate practices do not change (the laws are currently gentle encouragement), we will see dictated standards, practices, and inspections.

Food poisoning is serious enough to require periodic inspections and licensing. The federal, state, and local laws make it very difficult (and expensive) to open a restaurant and run it at a profit. However, the risk is that a few dozen people get sick for a few days. Consider that exposure of medical, financial, or legal data sources have the capability of instantly screwing up hundreds of thousands of people's lives for years at a time. Then think about how surprised you're going to be when laws are enacted which allow (and require) independent or government inspection of your books, your policies and your practices. (Hint: take a look at what's coming in April. Some of those laws already exist.)

The good news and bad news (for everyone) is that this will create yet another industry, one that will be rife with charlatan's at the start but will eventually evolve to require it's own explicit standards and practices. We are most likely to see the infosec equivalent of a CPA (and you think the SANS and CISSP certs are difficult?). There are already various functions within government which provide various administrative and investigative functions relating to information security. It's not that far of a jump for government to provide equivalent compliance testing and licensing functions.

No comments:

Post a Comment