[unisog] Firewall monitoring policies

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


Russell,

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
points:-).

Mark.

> -----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
this
> function.  That is a business decision based on risk analysis,
determined
> 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
be
> seeking some definition of intolerable risk and system "priorities" in
order
> to know how far to extend your monitoring policy.  If your institution
can't
> provide this then you will be left to hang when you design to some
undefined
> standard and that proves insufficient on some future date.  A
prioritized
> list of systems with some desired level of confidentiality, integrity,
and
> availability seems to be a pre-requisite to any decisions on your
part.
> 
> 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
for
> 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
firewall
> policy will probably be premature.  How can you protect assets that
aren't
> declared assets, have no determined value, or have no responsible
caretakers
> 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?
What
> 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
is
> undermined as well, as you give yourself no basis for actions required
to
> protect your assets.  I would think your firewall monitoring would be
to
> 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
them,
> then you can make business directed decisions about how far to take
managing
> your firewall, not just technical decisions.
> 
> It seems to me (at least in the interim) your job should be to define
what
> various levels of "firewall management" will do for the systems behind
the
> firewall.  This should map to risk assessment/determination results,
and
> identify a cost.  You get to translate the technical requirements for
> achieving the desired risk mitigation.  Don't be suckered into
determining
> what "desired risk mitigation" is, just be available to help translate
the
> technical details required to achieve it.  Else you will be on the
receiving
> end of the ball rolling downhill when an unexpected boo boo arises and
the
> 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
risk
> assessment.
> 
> I haven't attached such policies/risk assessments for your
examination.
> Some of these things are in the process of being developed and
reworked
> here, so I can't be of much practical help at this point.
California's
> system seemed to have some good basis policies, but I don't recall
whether
> 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
managing
> a
> firewall between our academic and 'corporate'  networks.
> The major issue I have to address is what level of monitoring should
we
> 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
before
> 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