RE: Worms, Air Gaps and Responsibility

[Dana Nowell <DanaNowell () cornerstonesoftware com>]

At 10:01 PM 5/18/2004 -0400, Gwendolynn ferch Elydyr wrote:
> On Tue, 18 May 2004, Dana Nowell wrote:
>
> > Some have been doing it awhile, hasn't worked yet.  We can check the
> > archives but you've done it, Marcus has, and several others (including me a
> > few times).  Glaciers move quicker, we need more people and preferably
> > people with bigger armorments.  If you mean the ENTIRE security community,
> > put me in coach.  Oh, that's just as soon as we get them to agree as well.
>
> Agree on what? There's plenty of information about best practices out
> in the wild - and increasing awareness and implementation.  Things do
> change.

But the community as a whole doesn't agree on a common set of best
practices.  Like you said, there are 
"plenty of information about best practices out in the wild - and
increasing awareness and implementation", the implication being that there
isn't a base set of rules for say small business and that what few 'rules'
people do agree on are not well sorted from the 'but I think' stuff.  If it
was, it would start showing up in places (contracts, discussion on VPN
implementations, business (not security) surveys, ...) and I don't see it.

> > Yup, I'm one.  Total company staff across all divisions and locations ~35,
> > not exactly a huge multinational here.  Now that I'm a charter member of
> > the club, exactly how much does that increase my clout with vendors and
> > customers that have outrageous network requests.
>
> Well - first off I'd suggest communicating risk effectively.  That means
> explaining it as a -business issue-, not as a technical complaint. It's
> certainly been discussed here [and elsewhere] many times - but your
> management and customers will hear "lose money" where they won't hear
> "technical wazzit".

Not the point.  The point is that a guy that buys one router has a hard
time getting clauses into Cisco contracts.  The 35 guy company that does
business has trouble getting contract clauses into deals with large
companies.  In many cases it comes down to an issue of clout, and the
little guy doesn't have it.  Being right is good, being unable to implement
it is bad.  Having everyone say the same thing gets it into the base
contract and the little guy wins.  I do not see it in the base contract
yet.  My company is not required by customers to carry insurance.  If my
company asks for insurance or other indemnification during contract talks,
we get laughed at.  We have stopped asking, stopped looking, and stopped
worrying about it.  I'd be happy to see it.  So when the games starts, put
me in coach.

> Secondly - try to find out what the customer wants to do, and help them
> to do it securely.  Most folks given a reasonable alternative that improves
> their security and bottom line - take it.
>
> > > Premise:  Every network operator we get to do the right thing[tm] means
> > > one less network to produce traffic which attacks us.
> >
> > Unfortunately I feel we are creating a hundred networks a day and
> > converting ten admins a day, the ship is sinking captain.
>
> It sounds, to be honest, like you could do with a vacation ;> I think
> that we've all suffered from this particular form of "nothing I do will
> make any difference, so why bother" at various times - and it does seem
> like an uphill battle some days.  On the other hand, if you consider
> the lake, rather than the water in your boat... it really is shrinking.

Actually my boat is pretty dry, we do OK from a security perspective.  It
is the lake I believe is growing.  Home users with broadband increasing,
small start-ups, every home business has a web presence.  New technology
arrivials with built-in opportunities arriving at a faster pace each year.
But you are right I DO need a vacation ;).

> > Never intended to argue air gaps aren't effective, intended to argue that
> > the definition of air gap changes and that business demands will cause
> > bridging (i.e., not effective long term).  Consequently it is like every
> > other tool in our belt.  Theoretically proxies work just fine, if they
> > greatly restrict what you can do and validate all the input.  They don't
> > always work in practice because people don't do that and they always need
> > another hole through the wall or another appliction running over HTTP.  Air
> > gaps will work well, until devices cross the gap because we didn't notice
> > (or have a choice).  When we notice the device will be ingrained into the
> > business process and we will not be able to stop it at the door.  Then we
> > cobble together something just like always and start searching for the next
> > evolution of the tool.
>
> Hrm. I'm not sure that you're thinking about the same type of environment
> as Paul.  He's talking about coast guard systems, cat scanners and the
> like - where you seem to be talking about corporate systems. Different
> demands and different risk levels.

Like I said several times, air gaps are a good thing.  And yes, air gaps
are more viable in high risk low churn infrastructure environments.  I have
no specific issue with air gaps in that environemnt.  My issue is with the
mindset of add another tool to the belt and call it close enough.  WHY are
we walling those off?  Answer, because we do not tackle the hard problem of
securing the ENTIRE NETWORK.  Yes, it is a hard problem, no we will not
solve it tomorrow, but few wars are won by repeated strategic withdrawals.

> > Not my point, I was claiming the 'strategic thinking' wasn't strategic
> > enough (in fact I'm not sure it is strategic, really).  Strategic thinking
> > that claims people need to understand their critical infrastructure vs.
> > their non critical and they need to understand the concept of air gaps
> > across technology that doesn't exist yet and enforce all that, only works
> > for the best and brightest not the average guy.  It also is not truely long
> > term strategic thinking, IMO, more like medium term.  Why, because it will
> > eventually fail, maintaining a true air gap is difficult and requires
> > complex planning, not good.
>
> I -really- don't see what's problematic with explaining technology that's
> hundreds of years old.  Translate "air gap" into "fire break" if you
> like...  It still comes down to "can't get there from here".  That's
> really not a difficult concept.

EXACTLY.  So after the concept of compartmentalization struck the world in,
what, the middle ages, AND has been ingrained in military process
practically since then, WHY ARE WE STILL DISCUSSING IT.  Why is it not
automatically assumed by anyone remotely related to the security community.
 The damn concept has been a 'best practice' in security since before
Columbus sailed (probably).  The fundamental issue here (to me) is not
'should air gaps be used', but how do we get people to build a base of
knowledge and keep improving it instead of rehashing it.  If we need to
discuss 500 year old security technology to the extent the list has, how do
we make headway.  As you said, we have some 'best practices', air gaps
being one.  The needed discussion (IMO) is how do we get them
accepted/assumed/ingrained in the whole process.  Once this stuff starts to
make headway maybe we can spend less time discussing 500 year of tech and
talk about winning the war for the entire network.

The basic concept of an 'air gap' has pretty much failed in the general
marketplace already (proxies, Marcus' original 'air gap', 5 million
discussions on this and other lists).  Sure we can move it to a more
specialized market.  We can take the tool and make a strategic withdrawal
from the general marketplace.  In fact we can eventually take all the tools
and make strategic withdrawals as appropiate, but when do we fight the war?
 When do we create new tools?  Where is the overview instead of the
hundreds/thousands of niche tool/method discussions?  If we spent the
energy to somehow educate the world (instead of just the latest crop of
security people) on best practices (air gaps), can we avoid this discussion
later because it is assumed?  Can we start getting this stuff accepted in
the general marketplace because it is expected by even the bosses and
vendors?  THAT'S the discussion I want.  Paul and I had this discussion
like 10 years ago, and 8 and 5 and ...  It has gotten to the point where I
let Paul tilt at the windmill alone now.  That is until I get to a
discussion at a time when I need a vacation :-).  So my complaint is that
this discussion didn't solve anything 10 years ago, or 8 or 5 and is
therefore unlikely to solve anything now (unless something changed I
missed).  Sure it will make a segment of the network community a bit
better, at least for awhile until people start breaking down the barriers
again for reason X (remember proxies that gave way to inspection and
firewalls that became swiss cheese, not because they were bad ideas but
because they were overruled, yeah OK I DO need a vacation).

> > I want to expand the pool to a broader base, not just critical 'national'
> > or 'large company' infrastructure but critical small company
> > infrastructure.  Why, because those guys become government contractors and
> > contractors to large companies.  A knowledge based economy can mean a
> > critical VPN to a one guy shop to debug a showstopper production problem.
> > This is especially true in the financial sector when an overnight delay can
> > cost millions.  I can assure you that if it is 'bridge the air gap' or be
> > out several tens of millions each day, some one WILL walk into your office
> > (been there, seen that).
>
> Uhhh... Okay. We've definitely wandered off here ;> This started out as
> "let's remember that systems such as air traffic control and stop lights
> don't need to be on the Internet", and has now veered off into trying
> to apply the idea of an air gap to everything.

Not air gaps, security in general.  I said I wanted to broaden the
discussion.  I'll stop now, it obviously doesn't want to be broadened.
Besides I think I broke my lance.


-- 
Dana Nowell     Cornerstone Software Inc.
Voice: 603-595-7480 Fax: 603-882-7313
email: DanaNowell_at_CornerstoneSoftware.com
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards