Re: Worms, Air Gaps and Responsibility

[George Capehart <capegeo () opengroup org>]

On Thursday 06 May 2004 02:54 pm, Devdas Bhagat wrote:
> On 06/05/04 10:34 -0400, Paul D. Robertson wrote:
> > On Wed, 5 May 2004, Carson Gaspar wrote:
> > > I agree. My response was to you're "what excuse do they have"
> > > question. In my specific industry, they have a bunch. Most other
> > > industries don't make every single dollar based on timely,
> > > accurate, electronic information. When your entire business is
> > > manipulating flows of information, based on other flows of
> > > information, limiting who can see what is a very tough job. Not
> > > impossible, but extremely difficult, and very expensive.
> >
> > But by the same token, that makes a massive network/node failure
> > all that more expensive- at some stage, we have to start taking
> > infrastructure seriously, and I'd argue that it's businesses that
> > rely on infrastructure so heavily that need to be in front of it.
>
> How many businesses see good infrastructure as an asset, rather than
> a cost? I would say that most businesses that I have had to deal with
> have seen infrastructure as a cost to be minimised, rather than as a
> necessary asset with associated costs. And even for those who do
> think of it as infrastructure, the idea is to have one time capital
> expenditure and low operating expenses, as with all other types of
> captial investments.

Seems to me that this is where a functional risk management process 
comes into play.  I don't mean risk management like the credit card or 
insurance types talk about, I mean IT risk management . . . the kind 
described in documents like GAO/AIMD-98-68, NIST SP 800-12, SP 800-30 
and SP 800-64, CobiT, etc.  Theoretically, the reason for doing 
security kinds of things is to protect the availability, integrity and 
confidentiality of systems and data.  Now, I have a little experience 
with on-line securities trading systems, a *lot* of experience with 
institutional securities and bond trading systems and a *lot* of 
experience with fx systems.  In my limited personal experience, system 
uptime and availability was critical.  *Very* serious risk assessments 
were done and a lot of hard work went into determining the trade-offs 
between availability (which included connectivity) and the cost 
(including convenience, etc.) of maintaining it.  In the end, no one 
got exactly what they wanted, but the organization got an 
infrastructure, a set of *policies*, a set of business and technical 
processes and DR and Business Continuity strategy that it could live 
with.  In my limited experience, infrastructure was seen as a critical 
component of "The System."

> > I understand where you're coming from, I'd just like to see us all
> > make more coordinated and extensive efforts to revisit the
> > "connectivity trumps all" mantra.
>
> Let me ask a harder question: How do you get the horse to drink?
> Connectivity shows profits in the balance sheet. Security shows up as
> expenses. Lack of downtime does not show up.

That depends.  Check the availability requirements in SLAs with 
operations groups, telecom providers, etc.  Uptime requirements in some 
cases range to 99.99%.  It certainly can be made to show up.  If it 
doesn't, it's only because it's not important that it does . . .

> > Maybe I'm too optimistic, but I always used incidents like this
> > last worm to get policy changes, validate the usefulness of
> > controls when we didn't get hit, and generally give the senior
> > execs ammo to crow about how well done their practical support of
> > security programs was.
>
> What is needed is a way to convert security benefits into balance
> sheet numbers. Once we work out a useful formula for that, then we
> can actually hope for some beneficial changes in the mindset of
> business management.

A good risk management process does that.  These things happen because 
of the absence of a functioning risk management process and a lack of 
accountability.  And I don't mean firing a Windows admin for not 
applying a patch.

My $0.02.

George Capehart
-- 
George Capehart

capegeo at opengroup dot org

PGP Key ID: 0x63F0F642 available on most public key servers

"It is always possible to agglutenate multiple separate problems into a
 single complex interdependent solution.  In most cases this is a bad
 idea."  -- RFC 1925


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