Re: Re: Best Practices

["R. DuFresne" <dufresne () sysinfo com>]

Dana,

I feel your points have been clear and for the most part, consise.  But, I
also think this set of best prac. lists has been done, repeatedly,
adnauseum<sp?>.  The problem is not in putting together a list, or a set
of them, it is in getting others to link to those lists, read and then
understand and impliment these practises.  Here are some of the problems
I've seen with such lists and getting them out into the general
knowledgebase;;

1> expense;  how many corp computer systems and let's just consiider
desktops here, are shipped with too many devices and services still open
to the public?  How many lack a simple effective and cheap anti-virus
produuct in the base offering install?  Just for corporate level systems
that a supplier, say dell or gateway or what-have-you, the expense of
fixing the too much open and running with privledge is costly, they need
to hire folks with the knowledge and skills to produce an image for these
that is more seucure.  some vendors like dell have taken great leaps in
this, yet, still have not got it all locked down.  The cost of adding
another packaged product into the base offering of an decent yet cheap and
intiitive <does one exist> anti-virus package is again, not cost
effective.  Companies with large orders might actually make headway here
in the systems purchased, but the small company or home user still has an
uphill battle with their own checkbooks to fight here.  The rules of
frugallity have set the common mindset to;  don't foot the bill till the
foot breaks something and the costs of repair outweight the costs of
saving a few bucks prior to fallout.

2> deceminating the knowledgebase lists to those targeted.  the Term
firewall, is still not common enough in the languages of tech-speech for
many to understand, let alone know how to seek out info on the topic.
Varous best practises lists are out here on the net, Paul just helped
guide folks through the first day of the techies with a clue helping the
non-clued secure their new home systems.  And, I'm willing to bet that
after the 5th and 10th anneversaries of this date in January<?> that
security wikll still be an uncommon  bit of knwoeldge to the masses, and
many of those masses are going to be folks in the IT field.

3>  what lists that do exist are too technical in terminology for the
average user to take in, they are too IT jargonised.  Service/daemon?!
port/communications channel?!  firewall/port blocking, these are not
common terms, and so filter into the common person's languagebase
extremely slowly.  Just try and define aht an anti-viruse package is to
Aunt Tilly.  I'm trying to explain simple e-mail terms and netiquette.
Problem is, these are not techie folks, and no matter how slow I talk
while walking them trough the windows on their own system in front of
them, they get confused or forget what they learned five minutes before.
and since I live 1500 miles from family, I can't walk or drive over to
help point where to click and show a specific example from their own
mailboxes.  I've run into the same issues with lusers in the workplace,
daily.  Many in those cases do not see learning or knwoing as part of
their responsibility, the pc is merely one of the tools they use to do
their job, and some of the ones closer to retireing wish they had an old
selectric<sp?  typewriter> back on the desk.

getting the info to the masses, in a format they can relate to in an easy
manner is are the key areas we are stll failing in.  Once someone has been
in the field long enough to know the terminology or with enough of a clue
to seek out the jargon file to find the definition is not the problem,
it;s getting through to the manager that knows little about the technical
expect how to convert a pie chart to a bar chart in excel, and to aunt
tilly and uncle ben are the keys.  And then getting the vendors too comply
when it is not economically tempting for them to do so, creating desktop
links for aunt tilly and uncle ben to learn from.

Thanks,

Ron DuFresne
<who jusat muddled up the clear and consise thread, sorry>

On Wed, 19 May 2004, Dana Nowell wrote:

> OK. From your viewpoint, it seems like I'm not getting it and from my
> viewpoint it seems like you aren't getting it.  Since Gwen is correct, I do
> need a vacation, and my desk is full so I'm fitting this in, I'm probably
> the one not being clear.  So I'll try one more time, hopefully clearer than
> before.
>
> No matter how you slice the Internet connected network space up (financial,
> government, or small business, large business) IF you exclude the home
> space, certain things will still apply even across that broad canvas,
> assuming you want a secure network.  Items like least priviledge, don't
> connect it if you don't have to, existance of passwords and accounts,
> segmentation/compartmentalization of network assets based on security
> needs/policy, and so forth.  What you might consider the basic tenents of
> any security setup or general 'rules of thumb' so to speak.  Can we agree
> on that (that some list could be made, not necessarily that list)?  
>
> If you put ten above average security people in a room and poll the top
> 5/10/50 'rules of thumb' I'd bet there is overlap.  That is, for lack of a
> better term, the floor/minimum 'best practice'/'rule of thumb'/'guideline
> for implementation'/'foo' for all networks connected to the Internet.  Now
> admittedly, it is a small set as we have not determined what type of
> network (small, large, critical) or what we are specifically protecting
> (customer list or launch codes).  But I bet we can make that list.  So now
> we have list 'Foo Base'.
>
> OK now let's segment that network space into some crude areas: small
> business, large business, and govermental (or infrastructure) asset (Paul's
> original thread: coast guard, power plants, etc.).
>
> If we concentrate on just the generic small business segment, I'd bet we
> can create list 'Foo SB'.  As we do the other segments we get lists 'Foo
> LB' and 'Foo Asset'.  Now I picked SB, LB, and asset, I'm not married to
> that specific split, just some agreed segmentation of the space.
>
> Now let's publish and promote those lists (or the process to create the
> list and the repository of information) so that at least that base of
> knowledge becomes common everywhere from the security guy to the mail room
> to the CEO.  As opposed to Gwen's lots of best practices on the Internet
> comment, somehow we get this to be 'the list' on the net. As 'the list' on
> the net, many people jump on the band wagon <serious hand waving if ever I
> saw it;>.  
>
> Hopefully, we spend less time explaining network compartmentalization in
> the context of infrastructure and worm/virus attacks because people are up
> to speed.  Hopefully, this provides a context/standard that gets extended
> to metrics applicable to contracts and insurance.  Hopefully this provides
> a base that can grow ('foo SB financial' anyone), extending the existing
> security knowledge.  Hopefully this can be used to enlighten people by
> reference and avoid rehashing the same constructs repeatedly.  Hopefully
> this can be used by people as a tool to help push back and help get sanity
> in the network space (vendors, ridiculous user requests, etc.).
>
> What I'm suggesting, if extended out to a ridiculous extent, is similar to
> the RFC concept or the ANSI standard concept but for Internet connected
> network security.  I doubt we can get that far, but a similar process might
> be useful. (NOTE: I have no actual process in mind, this is a straw man at
> best)
>
> The obvious issue is: it is a hard problem.  Networks are diverse, can we
> find sufficient commonality?  Information gets quickly dated if specific so
> we need general prinicpals not 'install a firewall here' stuff.  General
> principals may be too general to be useful and the specific information is
> too dated, so can we draw the correct line, is it even possible?  
>
> I have no complete picture of this, I'm not sure it can be done, I'm not
> even sure it would be useful.  I think it may be better than having the
> same discussions (compartmentalization) in different specific contexts over
> and over.  Hopefully someone or several someones can come up with a plan.
> Like I said, there are a lot of IQ points here ...
>
> Whether this is viable or not, we need a plan to broaden the discussion and
> build a public base of knowledge that can be extended.  Specific
> discussions about network X in context Y are useful, but by definition,
> frequently too specific to extend knowledge broadly to other contexts.
> This list has to a large extent become more tactical than strategic (I
> have/posit problem X in Context Y, let's discuss is the general thread,
> IMO).  As wizards I propose we let the apprentices deal with the tactical
> and we deal with the strategic or at a minimum we try for a mix of some
> strategic with the tactical.  Why, because today's tactical is next month's
> garbage as threats mutate but hopefully there are some basic strategic
> principals that have longer lives (which I THINK is where the original
> discussion needed to be broadened).
>
> OK, Paul/Gwen, is it clearer?

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        admin & senior security consultant:  sysinfo.com
                        http://sysinfo.com

"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
                -- Johnny Hart

testing, only testing, and damn good at it too!

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