• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Whitelist methodology on *internal* firewall?

Hurricane Andrew

Golden Member
First some quick background: I work for a multiple entity financial holding company with roughly 30 locations and 5 companies. Single point of external connectivity which is heavily fortified and actively monitored. Additionally, we have dedicated firewalls in addition to the routers at each location.

The issue is, we have some folks who are exploring the possibility/feasibility of employing a whitelist methodology for our internal network. We are already using a whitelist approach for our internet facing side, but what is being explored is using a highly restrictive whitelist approach (port by port) for internal location to location connections as well.

At first blush, I'm opposed to this concept simply from a complexity standpoint vs. the (admittedly preceived) limited additional protection that I feel we would gain. The problem is, I haven't been able to find much information on the subject and was wondering if anyone had any insight into this topic.
 
Sounds kewl.

I remember when I worked at Motorola, and their routers had ACLS that only permitted approved connections between offices. It would take weeks or months to get a needed connection approved (so we could do our job), and then, only after calling many times to see that it happened.

I think it's a great idea.
 
It's not uncommon to put internal firewalls, proxies, intrusion detection, etc in place between sites. Once you identify the applications necessary you start locking down the firewalls. Basically you let them run in a "record conversations only" mode.
 
Hurricane Andrew, if you're serious about security, you have good internal access controls and good internal logging/auditing. Most security damage is due to insiders.

Similarly, if you're serious about security, you do it whitelist, not blacklist. Expect more ongoing operational expenses that way. If you don't put staff on the problem of quickly and easily adding whitelist rules to respond to business needs, management issues will happen.

 
In theory it's a great idea. My issue is that with all of the other projects that we're working on that are much higher priority and have more immediate and more significant benefits, it's not something we're staffed to handle.
 
Hurricane Andrew, then you have to defer. This is an undertaking that will require real manpower to do right, and if you do it wrong, it'll just get ripped out and management will hate the idea for years. But don't let the idea stay on the shelf forever.
 
cmetz,

That's why I'm more concerned about user data access than employing an internal whitelist. Right now, we have users who have access to far more information than they would ever need to do their job. Even worse, for much of that data, there is no monitoring/logging in place. I'm working on getting management buy-in that this is a critical issue that needs to be addressed. The process of identifying where data exists, who needs access to it, and logging that access is far more critical in my mind than whitelisting our internal firewalls. Plus, if we go breaking their applications or disrupting their business, I fear that such pleas will fall on deaf ears. I'm still meeting resistance to a comprehensive e-mail encryption solution over cost!
 
There are multiple levels at which data acces can be restricted. The highest level, application level and file level are the easiest to manage. As you go to lower levels, the management gets more complicated. I'd start at the top and work down, if necessary. Most data attacks are from the inside, and usually don't require getting past firewalls.
 
Originally posted by: RebateMonger
There are multiple levels at which data acces can be restricted. The highest level, application level and file level are the easiest to manage. As you go to lower levels, the management gets more complicated. I'd start at the top and work down, if necessary. Most data attacks are from the inside, and usually don't require getting past firewalls.

Totally agree. Until you limit the data access or at least understand what access that users have, the rest simply makes others in the orgainization feel good. I actually argued as much in this article for Bank Technology News.
 
Back
Top