Firewall Wizards mailing list archives
Re: Vulnerability Response (was: BGP TCP RST Attacks)
From: George Capehart <capegeo () opengroup org>
Date: Thu, 3 Jun 2004 12:36:10 -0400
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
Current thread:
- Re: Vulnerability Response (was: BGP TCP RST Attacks), (continued)
- Re: Vulnerability Response (was: BGP TCP RST Attacks) Marcus J. Ranum (Jun 01)
- Re: Vulnerability Response (was: BGP TCP RST Attacks) Paul D. Robertson (Jun 01)
- Re: Vulnerability Response (was: BGP TCP RST Attacks) R. DuFresne (Jun 01)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) R. DuFresne (Jun 01)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Paul D. Robertson (Jun 01)
- Re:Vulnerability Response (was: BGP TCP RST Attacks) Marcus J. Ranum (Jun 01)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Paul D. Robertson (Jun 03)
- Re: Vulnerability Response (was: BGP TCP RST Attacks) George Capehart (Jun 03)
- Re: Re: Vulnerability Response (was: BGP TCP RST Attacks) Gwendolynn ferch Elydyr (Jun 03)
- Certification (was Re:Vulnerability Response) Gwendolynn ferch Elydyr (Jun 04)
- RE: Certification (was Re:Vulnerability Response) Laura Taylor (Jun 14)
- RE: Certification (was Re:Vulnerability Response) Gwendolynn ferch Elydyr (Jun 14)
- RE: Certification (was Re:Vulnerability Response) Marcus J. Ranum (Jun 14)
- Re: Certification (was Re:Vulnerability Response) Crispin Cowan (Jun 14)
- Re: Certification (was Re:Vulnerability Response) Vladimir Parkhaev (Jun 16)