Message-ID: <3F7796EF.20408@brvenik.com>
From: security at brvenik.com (security@...enik.com)
Subject: Pudent default security - Was: CyberInsecurity: The cost of Monopoly

I would add yet another take on this.

Michal Zalewski wrote:
> On Sun, 28 Sep 2003, Paul Schmehl wrote:
> 
> 
>>Oh, you might have a firewall that cordons off accounting from the rest
>>of the enterprise, but *inside* accounting, you still have the "soft,
>>chewy"  problem. I haven't really seen anything that addresses this
>>problem, and I'm not aware of anyone who is working on solving it.
> 
> 
> I'd argue... many vendors (Okena aka Cisco, BlackICE aka ISS, etc)
> provide integrated corporation-wide mechanisms for enforcing group
> firewalling, access and logging/IDS policies on workstations or groups of
> workstations (and, why not, also servers).
> 

The technology is already in the OS for the most part to implement many 
of these controls. Especially when you consider what a system needs to 
do. The products like Okena, Entercept, BlackICE... all add another 
layer of protection that is essentially unnecessary when compared to 
function. I am not saying these products have no place but rather they 
are not the solution to this problem.

Let me explain my perspective a little. Typically, only one system in 
accounting needs to have services open on the network, a print server. 
The rest of the systems do not need any services open. W2K and XP both 
have firewalls capable of blocking ports. Every system on the network 
should have a deny all policy where appropriate. There might be a file 
server thrown in there and depending on the apps in use possibly a 
middle tier but in all there a very manageable number of systems that 
actually offer services in even the largest of organizations. ( unless 
of course they made the mistake of using Exchange :)

The usual objection is that blocking all ports in this manner prohibits 
administration. This is simply untrue, there are many scalable, 
manageable, affordable alternative methods. It might be true that it 
forces the administrator to do things differently but change is almost 
always good.

One alternative method might be terminal services running in high 
security mode. While not perfect you still have full control of the 
remote host for point administration and have only one service to 
protect over one port (3389) instead of a myriad of services being 
offered by the never ending portmapper. Yes, things like tsgrinder exist 
to help brute a connection however the level of risk there is the same 
as regular smb. Other alternatives might be domains and policies... The 
sum is that there is no shortage of administrative options.

By the time you do a baseline configuration with local filtering, 
services disabled and remote administration you do not need the host 
based products on a large scale. It has also been my experience that 
these host based products are as much of a beast to administer on a 
large scale as the OS is. I would rather invest that money in a robust 
patch management solution and deployment of that solution than 
continuing to mask the problems with an existing deployment. Most of 
these changes can be made in place and with the same level of effort 
required to deploy the commercial personal firewalls but without the 
product cost.

All of this excludes Paul and the ISP market. They might actually 
benefit from offering the Personal Firewall products for free or at a 
discount as part of the service. Regardless, that is a different ball of 
wax that Paul will be happy to enlighten anyone on.

But then people say that the personal firewall can prevent local 
intrusions too since it runs on the host. I simply counter that this is 
a rat race and you have to trust the person at the keyboard. If you do 
not trust the person at the keyboard a change in people is in order. The 
untrusted person will ultimately circumvent your controls. Then it 
becomes a hide and seek game.

Addressing the application protocol layer can help a little too but when 
you break down what actually needs to be running where and how the 
problem becomes so little that you can safely manage them and mitigate 
the risk.

I think that the problem is not the protocol or the application. It is a 
fundamental lack of understanding of the security model and the network 
as a whole.

Powered by blists - more mailing lists