On Mon, 21 Oct 2002, Duncan wrote: > Having worked in the Firewall support role at several companies, I need to > vent^H^H^H^H share two experiences that are at difference with the > above. I'm just going to add my commentary and perspective on the sorts of issues you've faced. Hopefully some of it will help someone somewhere, otherwise it's just a good time to rant... > > At a software development firm (Dot Com) related the policy was > written to protect property (both physical and intangible). Abuse of > resources was prohibited. > > But if a developer had a need (or made a request) to open FW ports, or gain > IM access, "no" was not acceptable, but rather how fast the request > was completed. As most developers realize, tying a deadline to any > request is the best way around restrictions or "policies". > You may just find yourself on the receiving end of a written reprimand > from your CIO directed at you from the CEO of the company. I had my CIO approve my security policy. This meant spending *lots* of time educating him about Internet risk. When he understood the policy from his perspective, he also understood the fact that enough exceptions to policy were going to kill _having_ the policy. I had folks attempting to tie requests to advertising deadlines for newspapers. They often declined the "get out of your chair, and walk over to the machine in the corner that's isolated on the DMZ" option though- amazing how an uncomfortable option changes the priority and necessity of a request sometimes. Trying to tie requests to deadlines, revenue or things like that tend to require thought-out responses, as well as rounding execs into rooms and explaining things to them -for instance, I'd have spent some time with the head of development explaining that I'd be happy to build the correct infrastructure to keep the company secure and permit business-critical things to happen, but that I wasn't going to swiss-cheese my security policy because of a lack of foresight on the part of his developers. I'd explain to him the costs of handling last-minute requests versus proper planning and also find out his threshold for taking responsibility for the actions of his developers and their requests as it impacted the whole business. My bet is that after the right conversation, you'd find that the requests would all go through that person and be fairly limited to real requests, or you'd be drawing up a "development network" plan that could quantify the costs of risky behaviour and isolating the company from it. There's also a very good "at what point is the firewall now useless" discussion that needs to be had with the CIO in regards to having multiple exceptions. There have been a few times when I've offered to "remove that pesky firewall and make things really easy to do." Nobody's ever taken me up on it. Once they understand that firewalls work by blocking and that means the more they block the better they work, it's not usually a difficult thing to get them to coral their users down. Also, there are last-minute requests that can have a limited lifetime, policy changes don't have to be permanent. A fall-back position of "Ok, we'll take that risk for the next two weeks from 9-12am" may be better than no fall-back at all. Just keep in mind that in some environments, the precedent of giving ground at all will eventually consume you. > Supporting FW's in the corporate offices of a large ISP (now gone), > the policies required business justification for opening additional > ports, and or relocating segments in front of the firewalls. Note that > as a ISP, we were the daily target of hacking attempts. > > The firewall was set to transparently proxy connections for http > (80,443,8080) to unlimited destinations. This seemed to work for all > 300+ employees. But IT had a problem, they could not download drivers > from HP support. This was a critical problem for them. Their suggestion > (request) was to open the FireWall to allow all (TCP ports >1024) > outbound from their class C. to any IP as they could not provide me > with a list of IPs for HP support. > > The suggested workaround appeared simple: > a: Configure your browser to proxy via the FW ip. > b: Use dialup, we are a ISP and its free. > > Management was informed of the risks. The director of IT support informed > my director that it didn't sound too risky to him to just open up the ports. > Besides the IT desktop support people would have to remember to turn on > proxy support when they needed. That's one of the reasons I refused to go to transparent proxy support. If people have to remember to configure a machine to even get Internet access, it was a good thing. In this specific case though, I'd either have (a) had them always use a non-transparent proxy [done this in a few places], (b) offered to mirror the driver site [done this twice before], (c) offered to open the ports for the duration of a request [never had to do this], or (d) offered an "on the DMZ" PC they could use for downloading drivers and whatever other things they wanted [done this a few times.] The idea that the business has to take a full-time risk for an event that's probably rare isn't good. Finally, there's no way in hell the director of IT support would be a risk decision maker in any policy I wrote. The risk for the entire company just isn't down at his level. > Management felt the added risks were justified versus slowing down desktop > support, since we had not had anyone actually ever breakin. One of my constant quests was to get executive management to understand that the reason we'd had no break-ins was because of our security policy and its enforcement. Fortunately, there have always been plenty of counter-examples, so passing e-mails about high-profile break-ins and an explaination of why our security policy stopped a particular vector to the CIO every couple of months was really good. I spent a good portion of my "$important person/department/partner/advertiser/customer" wants $silly_thing time on long written responses to such requests that clearly labled and landed the decision point at executive managment and clearly pointed out that making such a decision would be clearly against my advice. Understand that a part of that was a risk assessment on my part career-wise. I'd purposefully skip my boss at the time and go right to the CIO because he was an officer of the company. In a large company, you don't have to explain the personal risks such a person takes in making such decisions against professional advice (but this ploy generally only works if you're in a publicly traded company.) Only once did my boss go ballistic over the corner I'd backed the CIO into on a given decision, and that was something I believed strongly enough in to offer to go find another job over. My security policy clearly enumerated the decision tree, process for exceptions and rules, as well as the implementation details (added as a last minute flash of brilliance that allowed me to restrict the distribution of the document the way that having two seperate documents wouldn't have.) > At least in these two companies the policy only went so far as to > interfere with some claimed business need, and we had a exception. > > Working for smaller companies (<500 employees) policies are usually > a after thought, and may have been written by some manager in IT dealing > only with abuse of the desktop itself. I have been at 3 Tech. companies > where each has the following section in their policies: First of all, policy *has* to have support from the highest levels, or it's going to be useless. Secondly, you must be able to articulate risk well to get a good policy and to get backing for enforcement. > "XX. Internet usage is only for approved business purposes. Personal use > (access) is prohibited." In a lot of places, having a policy that's not enforced (and I've yet to be anywhere that had a prohibition rather than a few restrictions on personal usage) is worse than no policy at all. I'd have spent some time detailing the legal risks, then presented them in writing. > This was in (2) Software (Internet) development and one ISP company > policies. > > On the other hand having worked in a AeroSpace biggie where there are > more work rules than one can read in a month, policies tended to be > better enforced. Or atleast it was much harder for a requester to get > enough management support to force a FireWall change. Smaller companies are a much more difficult nut to crack because often the environment is more "friendly" and they mostly haven't gone through the trials that large companies have (because any one of them would wipe a smaller company out of business.) Small companies in a rapid growth phase tend to have to make risk choices that aren't always the best from a risk perspective too. I'd probably have real trouble being the firewall admin at some places because my personal risk profile wouldn't match the company's. There's a point at which either the admin or the company has to give. I've been in the position that I've always been able to make the company give. I doubt there was more than a 30 day period at one point for about a year where I didn't offer to resign, turn the firewalls over to someone else, ask someone who wanted an exception to design a way to secure their exception if they were so much smarter about the security policy than I was, etc. There's also a distinct advantage to going in to a job knowning you'll do firewalls. When I started doing firewalls, I got the extra responsibility added to my "day job" because some manager had made the firewall decision and I was the only one in the building who knew Unix, so the guys who he "trusted" more than me gave me the root password rather than having to try to work in an environment that didn't interest them (they were datacom folks.) Since I didn't have the luxury of going in negotiating my position, each part of the executive support for my policies, as well as the overall handling of that stuff had to be eked out over time. Some people were mad at me for *years* when I wouldn't approve an exception, they got another "Internet" division in a meeting, and the admin there agreed with me, then they drug their CIO into the room and asked again, and I still said "No." They didn't want to budget to "do it right," and "right" in my book didn't included doing it from their desktops. That started a multi-year project to decouple the largest business unit we had and about 1700 users from the corporate network. It also sparked some seperate firewall purchases. I still remember the meetings with them once they realized that their culture of politics and acomodation uber alles would land them responsible for their own network security policy and its enforcement. None of them was willing to be "The one who says No." and they could finally realize the downstream effects of that. At that point, it was too late for them to backpedal though, and the most vocal of their seperatist movement had already moved on to another company. Whoops! Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions probertsat_private which may have no basis whatsoever in fact." probertsonat_private Director of Risk Assessment TruSecure Corporation _______________________________________________ firewall-wizards mailing list firewall-wizardsat_private http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
This archive was generated by hypermail 2b30 : Tue Oct 22 2002 - 04:25:54 PDT