On Sat, 22 Nov 2008, Lamont Granquist wrote: > On Wed, 19 Nov 2008, [EMAIL PROTECTED] wrote: >> On Wed, 19 Nov 2008, Dave Caplinger wrote: >>> [EMAIL PROTECTED] wrote: >>>> the bulk of these are firewall changes. As such we are not comfortable >>>> with >>>> the self-service approach. >>> >>> Wow, an average of 2 production firewall changes a day (and I'm sure >>> there's >>> quite a bit of +/- variation around that number)? >> >> more like 10 changes a day to production firewalls, with another 10 >> changes a day to less critical systems. > > Firewalls are extremely expensive security. They also tend to fail badly to > be a real security countermeasure when they are overused and the resultant > thousands and thousands of lines of ACLs are unauditable and unmaintainable. > Also, the more fine grained you get, the more you are simply getting in the > way of the strength of having networked systems and service-oriented > architecture, which is the ability of computers to communicate over the > network. > > It is generally better to push security into layer 7 and to simplify your > firewall rules. Give up on the idea that you can "know" everything about the > communication of your network and that the communication is fully expressed > in your firewall rulesets. > > If you've got a million different zones, try to reduce it down as much as > possible. For the average website I'd suggest simply having four zones > (internet, production, corporate and credit-cards/PCI). Even having seperate > zones between databases and app servers isn't scalable, and ultimately > doesn't offer any security (all i have to do is find one explitable hole in a > firewall with hundreds of holes in it as an attacker).
you are assuming a single website. when there are many (potentially thousands) of different websites, and several different product lines there are reasons to not lump them all togeather where a flaw in one exposes all teh data for all the others. > I'd even suggest the heretical idea of allowing all your servers to connect > out to the internet. The practice of blocking all outbound connections which > have not been explicitly allowed is a prevent control which primarily > _prevents_ internal business from occuring. It would be far better to turn > that into a detect control and monitor border traffic for outbound anomalies > and get out of the way of internal software being able to use the Internet. If you can allocate the manpower to properly tune and respond to the monitoring systems, you can allocate the manpower to open the holes explicitly. > I keep getting invited to post-mortems on deployments which fail because > border firewall rulesets weren't updated properly for the deployment and I > keep on feeling like the doctor that tells the patient "well, if it hurts > when you do that, stop doing that". in my experiance there is a strong tendancy to implement monitoring/alerting systems with the justification that you can then open up the firewalls, but then not allocate the manpower to properly respond to the alerts. there's also the problem that the firewall has a chance of preventing the problem while the monitoring only tells you after the problem has occured. David Lang > The amount of crap that you are policing is probably not doing anything to > actually increase your security and if you had someone with talent actually > try to penetrate your systems they would probably render all your firewall > rulesets meaningless. Since you are in the financial system you probably > have mandated external auditing that you need to pass, but you should get > aggressive in arguing with the auditors in order to simplify your life -- and > you should not be trying to exceed external auditing standards because it > "feel virtuous" when its just generating dozens of tickets a day and > producing a large amount of security theater that isn't doing any actual > good. > > at least that is my $0.02... > > _______________________________________________ Discuss mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
