[unisog] Firewall monitoring policies

Mark Poepping poepping at cmu.edu
Wed Mar 6 16:36:12 GMT 2002


I pretty much agree with Jim Dillon on all the business-based risk and
policy decision issues (actually the SEI Octave stuff looked like a
reasonable approach to helping a business figure that stuff out - but I
digress).  But though that's good, you're not going to do that within
three weeks..

So what in the 'ingress' logs would you want to alarm?  Anything the
firewall catches is 'caught', so I'd claim it's not an emergency (okay,
look at it once a day).  The stuff that's most valuable is the stuff
that's caught on the egress side - when I notice that I'm attacking
somebody else, it's time for an alarm.  That might not be too hard to do
(depending on the firewall and tools), and a "page me" routine may be
enough.  I think you also want to use argus on both sides though (the
inside is probably most valuable in this case) for alarming that the
firewall may not do, and for forensics when something happens.

Finally, in response to the suggestion to contract a 'monitoring'
service, I'd suggest you instead propose hiring another good
engineer/programmer - you'll get twice the return (though many fewer CYA


> -----Original Message-----
> From: Jim Dillon [mailto:Jim.Dillon at cusys.edu]
> Sent: Tuesday, March 05, 2002 1:40 PM
> To: 'Russell Fulton'
> Cc: SANS (E-mail)
> Subject: RE: [unisog] Firewall monitoring policies
> Russell,
> Here are a few snap thoughts...
> Sounds like a no win if you are left deciding the requirements for
> function.  That is a business decision based on risk analysis,
> risk acceptance and materiality limits.  If the "Corporate Side"
hasn't done
> this, then I'd start educating them on how to do so.  It is
unfortunate if
> you are left to technical reasoning for making the decision, as this
has no
> bearing on the materiality of the risks faced by the "business."  I'd
> seeking some definition of intolerable risk and system "priorities" in
> to know how far to extend your monitoring policy.  If your institution
> provide this then you will be left to hang when you design to some
> standard and that proves insufficient on some future date.  A
> list of systems with some desired level of confidentiality, integrity,
> availability seems to be a pre-requisite to any decisions on your
> Assuming the function is to protect the "enterprise" systems and
systems of
> record from the "wild wild west" of academic freedom, I guess I'd look
> some of the following.
> 1. Policies that define ownership, responsibilities, and rights to the
> institution's data assets.  These provide you the guidance and
reasoning for
> protecting information assets.  If these aren't in place, your
> policy will probably be premature.  How can you protect assets that
> declared assets, have no determined value, or have no responsible
> assigned?
> 2. Response and Forensics plans/policies.  What are you going to do
when you
> actually detect something with the firewall?  Can you react quickly?
> things require forensics responses?  Building a policy without a
> response/forensics plan and response priority is likely to be far less
> effective than desired.  Note that without 1 above your forensics plan
> undermined as well, as you give yourself no basis for actions required
> protect your assets.  I would think your firewall monitoring would be
> identify events requiring a response.
> If these two items aren't also on the table, you are missing a bit of
> relevant info on creating your "firewall" procedures.  I'd push for
> then you can make business directed decisions about how far to take
> your firewall, not just technical decisions.
> It seems to me (at least in the interim) your job should be to define
> various levels of "firewall management" will do for the systems behind
> firewall.  This should map to risk assessment/determination results,
> identify a cost.  You get to translate the technical requirements for
> achieving the desired risk mitigation.  Don't be suckered into
> what "desired risk mitigation" is, just be available to help translate
> technical details required to achieve it.  Else you will be on the
> end of the ball rolling downhill when an unexpected boo boo arises and
> responsible parties scramble for cover.
> Push for acceptance of the standard "least privileges" policy at
least.  It
> is a basis to operate under if you can't get any timely action on a
> assessment.
> I haven't attached such policies/risk assessments for your
> Some of these things are in the process of being developed and
> here, so I can't be of much practical help at this point.
> system seemed to have some good basis policies, but I don't recall
> they included references to risk/objective based decisions.
> Quick thoughts - I hope not too hurriedly spoken or too disorganized,
> Jim
> ======================================
> Jim Dillon, CISA
> IT Audit Manager
> jim.dillon at cusys.edu
> Phone: 303-492-9734
> Dept. Phone: 303-492-9730
> Fax: 303-492-9737
> ======================================
> -----Original Message-----
> From: Russell Fulton [mailto:R.FULTON at auckland.ac.nz]
> Sent: Monday, March 04, 2002 9:00 PM
> To: unisog at sans.org
> Subject: [unisog] Firewall monitoring policies
> Greetings All,
> 		I have 3 days to put together a proposal/policy for
> a
> firewall between our academic and 'corporate'  networks.
> The major issue I have to address is what level of monitoring should
> have.  One of the senior managers has proposed that we contract a
> security firm to provide 7x24 hour monitoring of the firewall, at
> considerable expense.  I believe that this is overkill and that daily
> checks of the logs would be adequate.
> I also have serious doubts about how we are going to define an action
> policy for the monitors use. i.e. a list of senarios and actions to be
> taken by the monitoring firm (this is the basis of the monitoring
> contract) particularly in view of the fact that this is an academic
> network with all sorts of unpredictable stuff floating around.
> Unfortunately this has been sprung on me at the very last moment
> the firewall is due to go into service, hence the tight deadline.
> As I see it the critical issues is how important is it to respond to
> quickly 'incidents' that might be detected by the firewall and how
> likely is it that real attacks will actually be detected.
> If anyone has any policies that they can let me have or pearls of
> wisdom, or even wild ideas I would be extremely grateful to have them
> --
> Russell Fulton, Computer and Network Security Officer
> The University of Auckland,  New Zealand

More information about the unisog mailing list