Re: Vulnerability Response (was: BGP TCP RST Attacks)

[George Capehart <capegeo () opengroup org>]

On Tuesday 01 June 2004 08:29 am, Paul D. Robertson wrote:
> On Thu, 27 May 2004, George Capehart wrote:
> > *crawls out from under rock, drags out soap box*
> >
> > Seems to me this is less a case of security being the tail trying
> > to wag the dog as it is a case of users being the tail that
> > actually wags the dog.  One must wonder who is running the company.
> >  These are policy issues, for crying out loud!  Sounds like it's
> > time to introduce a certification and accreditation process into
> > those organizations. Doesn't have to be as rigorous as DITSCAP or
> > SP 800-37 . . . just something that forces the people in the
> > company who are supposed to be managing the risk to do so . . . or
> > formally, in writing, accept the risk that they're *not* managing.
>
> The main issue I've seen is that traditionally, the person ordered to
> make rule changes is not often empowered to reject changes, or even
> require written justification.

Yep.  That's the problem.  :>  A C&A process would go a long way to 
solving it . . .  But, as you point out below, *having* and *enforcing* 
a C&A process is, in itself, a matter of policy . . .  ;}

> This is the reason that a security policy is important.  If your
> security policy enumerates who can authorize changes, what the
> default stance is, and how risk is to be investigated- then you're
> way ahead of the users dictate policy game.
>
> When you do it right, it works.  At my last employer, I had a
> division vice president who thought that my insistence that they
> waddle out from behind their desks to a second computer in their
> office to use a new application they were evaluating was too
> inconvenient for them.  They tried to override me, and when they
> scheduled a meeting with the corporate CIO to go over my head, the
> CIO invited me to explain the policy.
>
> Because I'd done all the policy stuff up-front, and because I'd
> regularly haul the CIO into a conference room and make him understand
> the risks by doing a half-hour to hour of whiteboarding, where we
> discussed the network and business risks of various things, as well
> as detection and protection strategies, I had really good solid
> backing.

This is an example of a well-functioning risk management process at 
work.  The absence of policy and/or policy enforcement is a symptom of 
a poor or non-existent risk management process.  I submit that an 
organization that allows users to "set policy" either has no risk 
management process or, if it does, it is so weak that it might as well 
not exist.  And, anticipating the point made in the next paragraph, 
this organization has no idea of the cost of the exposure it has.

> The cost of risk is very important.

Hear, hear!

> If people in the business expect
> that "open a port on the firewall" sorts of things are all that's
> needed to accept new risk, then you'll get lots of requests, and
> they'll be very difficult to stop, since almost anything can be
> justified in a forward looking basis (the trick is to get the finance
> people to account for the benefits and history of the projections.)-
> but if people have to pay for risk mitigation, and it's a part of the
> process, then you tend to get only the requests that really have some
> business merit.  "We need to reduce this connectivity by buying this
> network infrastructure, these licenses and 1/2 of a FTE" tends to
> have a pretty good self-moderating impact on things that aren't
> strategically important to the organization.

And on the flip side, requiring the business owner of a system to 
formally acknowledge and accept the residual risk *in writing*, is a 
powerful tool in helping to manage^Wminimize residual risk . . .  :-)

In the end, I guess, the real challenge is to sell those naive 
organizations on the value of actively managing their IT risks and the 
costs of not doing so.  

George

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards