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

[George Capehart <capegeo () opengroup org>]

On Thursday 03 June 2004 09:35 am, Paul D. Robertson wrote:
> On Thu, 3 Jun 2004, Phil Burg wrote:
> > This part, IMNSHO, is a key part of your risk management policy /
> > standard / whatever $YOUR_SITE calls it:  you need to clearly
> > define who evaluates security risks and how they do it, the
> > intention being to arrive at a situation wherein any suitably
> > qualified person (for some value of suitably qualified) can pick up
> > your RM documentation and produce a very similar assessment of the
> > risk as any other suitably qualified person would produce.  And of
> > course it needs to be auditable.
>
> *Exactly.*  Someone has to _own_ risk management.  The people who
> don't own it should have input, but not the ability to nitpick.  That
> means the organization must be comfortable with the person who owns
> it being able to assess not just the security risk, but the business
> risk and weigh the two.

At the risk of going *way* OT here, I'm going to indulge in a "Best of 
All Possible Worlds" scenario:

In my ideal world, IT Risk Management would be part of the charter of 
the corporate risk management process.  In this world, Risk Management 
(TM) is "owned" by the Board of Directors' Risk Management Committee 
and is implemented by the Corporate Risk Management Group (CRMG).  The 
CRMG is staffed with people who understand the different kinds of risk 
that the organization faces and is responsible determining the levels 
of risk that the corporation is willing to sustain for setting policy 
(including InfoSec policies) that allows the organization to manage to 
that level.  (This doesn't mean that members of this group must define 
and write detailed policy, only that they are responsible for getting 
it done and balancing the policy statements that come from the 
different areas.  There are many ways to skin a cat, and their job is 
to make the final decision as to which way to do it).  The Executive 
Committee is responsible and accountable for the enforcement of the 
policy.  Inputs into the policy-making process are sought from all 
affected parties who are represented on the working watchdog committees 
that are chartered with understanding the organization's risk profile, 
recommending controls, and monitoring the effectiveness of existing 
controls.

Granted, this picture assumes a not-really-small corporate structure, 
but the basic logic can be applied to organizations of all types and 
sizes.  The idea is that risk management is part of organizational 
governance, and as such, is "owned" by those who are responsible for 
oversight of the organization, whatever its structure.  LOB managers 
(and I lump the CIO in this category) are responsible for managing the 
risk that is generated by their "branch of the tree," and they should 
be given some latitude in how they do so.  If they elect to do things 
in a way that "violates policy," they should be required to sign off on 
the fact that they realize that they're violating policy and accept the 
additional risk, and that their job is on the line for it.

The main idea that I'm trying to promote here is that risk management is 
a governance issue and that "ownership" of the process should be at 
that level.  It is not fair to the folks "at the pointed end of the 
stick" to put them in the position of having to policy decisions.  
Implementation decisions, yes, policy decisions, no.  For example, a 
policy decision might be "No P2P."  An implementation decision would be 
how and where to block it.  Network security shouldn't be the one to 
have to defend set and defend the policy.  They should certainly be 
represented on the policy-making committee(s), but the policy should 
come from the risk management group, not network security.

Now, having said all that, there will always be things that slip between 
the cracks and new threats will evolve for which there is no policy.  
This is where the folks at the pointed end of the stick get involved . 
. .

> Generally, though it seemed like I rejected everything put to me, in
> fact, almost all of my rejections were "no, we won't just open up
> $foo and let you do it on $bar, but if you're willing to buy $baz and
> move things thusly..."  Naturally, I started with "No!" because I'm
> always in default denial ;)

*snicker* *snicker* *guffaw* *guffaw*  Default deny . . . Default denial 
. . .  *snort* *snort*  That was a good one.  :-)

Now, in my ideal world, things like this would happen every now and 
then, but after the "Hell, no" would come:  "Lets present this to this 
month's meeting of the risk management group see what they say."

<snip>

> The understood that I did my job, and my job was to protect the
> company. They knew that the company was going to take on more risk
> within a week or two- because like most large corporations, there was
> a lot of internal politics, and very few people will take the "more
> likely to be career limiting, but right" path.
>
> In the end, the people who I interacted with most for new things had
> gotten to realize that it was easier by far to come and ask me how
> they should do something new than to fight for the right to do it at
> all after sneaking it in.

It's been that way in most places I've been, but there have been some 
refreshing exceptions . . . sometimes in organizations from which I'd 
least expected it.

OK.  I've gotten it off my chest.  Even if this message doesn't make it 
to the list, I feel *much* better . . . ;-)
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards