Re: Best Practices

[Dana Nowell <DanaNowell () cornerstonesoftware com>]

At 01:33 PM 5/21/2004 -0400, Gwendolynn ferch Elydyr wrote:
> On Wed, 19 May 2004, Dana Nowell wrote:
>
> Starting from the bottom ;> Yes, it's clearer *grin*
>
> I've snipped much of what you've written, and ended up addressing this as
> "you/your". It's intended as a convenience, not an irritation ;>
>
> To summarize, you'd like to:
>
>   (1) Create a list of minimum best practices for computer security
>   (2) Create more targeted lists for specfic markets/audiences
>   (3) Spread this throughout the security community, and beyond
>
> Next you ask if it's possible to come up with a list that everybody
> can agree on, looking specifically at the business space, rather than
> the home user [which is another discussion in some, but not all ways].
>
> Your lists starts with:
>
> Least priviledge - I'd tend to bundle segmentation/compartmentalization,
>       as well as reduced connections here, since those are really about
>       providing the least priviledge.  I'll certainly grant that they
>       should be broken out for the sake of clarity within the least
>       priviledge bundle ;>

That's part of the problem I'm attempting to solve :-).  I used to bundle
it into segmentation but in several discussions, others have not.  Some
people separate network level (firewall, proxy, router acls, etc.) from
user authorization compartmentalization.  Got to build that common
dictionary!  Frequently discussions on the list (and elsewhere) take a long
time because people need to 'refine' a common context.

> Passwords/Accounts - Hrm. This isn't actually what I'd want to use as
>       a meta-concept.
>
>       What you're trying to establish is that a given action was taken
>       by a given, identifiable entity. I think that I'd be inclined to
>       use something more like "Proveable identity".  Take a look at AAA,
>       which nicely describes the same general concepts.  Authentication
>       [who is it?], Authorization [what can they do?], Accounting [what
>       did they do?]

Actually I just see a smaller end of the world then you:-).  I've actually
had to have discussions with people about HAVING passwords.

> You skim, but don't really catch on to some of the ones that I consider
> to be absolutely major - Risk Analysis and Policy.

Yup, wide spread examples, not a plan or intended to be even remotely 'real'.

> In order to build any form of successful security infrastructure, you
> need to know what you're protecting - and against what dangers you're
> protecting it.  Risk analysis gives you that basic data.
>
> Policy then describes how much you care, and what the basic constraints
> for your infrastructure will be.

Oh gee, so a security policy might be a base best practice ;>  Only part
joke, how many companies under say 100 employees do you think really have a
written security policy?  Scary ain't it.

> > 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.
>
> IMHO, best practices aren't as much about giving people specific lists
> about what to do - one of my ongoing issues with many of the books that
> are published in the security field is the 'recipe' approach - as they
> are about helping people to understand basic concepts that lead to good
> security.

Yes, my point is to list the basic concepts, not the 'add ingredients,
stir, get secure soup'.  The specific list for secure soup is too specific
as threats change.  The overall concept of auditability, authentication,
and authorization is frequently alittle too abstract so many.  The concept
that every user should have a different distinct account id and that all
accounts should have some type of 'verification mechanism' (e.g. password,
one time token, ...)  MAY be a happy medium (so again where do we draw the
line between here is an 'esoteric' security concept and here is the receipe
for secure soup, just stir).

However, I also believe that concepts have 'degrees of reasonability' and
in many cases that is where people have trouble.  Take 'air gaps' as a
general concept they are great, to some extent I think most if not everyone
attempts to use them in some form (firewall, proxies, armed guards and
vaults, ...).  Stating that 'do a risk assessment and implement the level
and type of air gap needed for your environment' is a valid but virtually
worthless (in a practical world) concept (OK, IMO).  So how do we bridge
the gap between the proper generic statement of the concept and a
description that AVERAGE people can use to actually implement something
useful (a best practice of air gaps, so to speak).

> Following a list blindly doesn't indicate understanding of 'why', as
> much as being able to type in 'how' - and we've all seen what happens
> when [to go back to a different thread] people believe that there's a
/>technical panacea for non-technical issues. [0]
>

Agreed, but a concept that people either don't get or only partly get
doesn't fly in the real world, people screw it up.  We need to find a way
to: build a list of UNDERSTANDABLE common concepts, structure that in an
EXTENSIBLE manner, and allow it to be extended in some manner of a
distributed fashion (no, Gwen or Paul or Dana will NOT sign off on all best
practices, I know I have other things to do and I assume you and Paul do
too).  Now obviously UNDERSTANDABLE and EXTENSIBLE are words that we might
need some agreement on definition before we start.  Oh yeah, and while we
extend it in a distributed fashion, we need an overall process that
instills confidence in the community that things will not get missed and
that some form of due diligence was done.  Piece of cake (remember that
'hard problem' comment?)

> > 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)
>
> Er. The RFC concept is interesting, but in general tends to be very good
> for issues that are readily quantifiable such as protocols, and not nearly
> as good for policy issues [which are subject to debate at the best of
> times *grin*].

Yup, straw man, you killed him.  Now please find a replacement ;>.

> I think what we're talking about here is more of a highly accessible
> 'plain english' description of best practices than the labrynthine and
> precise world of ANSI and IETF specifications ;>  Correct me if I'm
> mistaken about your intent, though ;>

Correct.  The first thing to get right (IMO) is the process: how do we
accomplish due diligence, how do we define the level of detail, how is it
extensible (or not), how do we set the level of this mess so it applies to
a broadbase yet allow specfic stuff when needed.  RFCs and ANSI specs work
because people have some belief that it received some sort of peer review,
that some due diligence was done.  Any idiot can (and many do) write a book
on security.  Any idiot can claim that their site has a repository of
security 'best practices'.  So assuming this thread takes off and a best
practices repository is built, how do people know it was not built by some
new idiot.  Or put another way, as a fellow idiot in this thread, how do we
get them to believe us ;>.

> > 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?
>
> IMHO it's about teaching people why it's an important problem, and how
> they can think about the problem, with general guidelines in their
> particular environment.

I was kinda hoping this audience would already be converts :-).  Given
that, I'm trying to steal/borrow enough IQ points and experience to widen
it out to the rest of the heathens.

> > 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).
>
> Well - in theory this list started out as a complement to the more basic
> firewalls list, which consisted largely of "how do I do this" questions.
>
> ... but the firewalls list isn't active any longer, and people will find
> places to ask their questions ;>

That's my attitude, that was firewalls, this is firewall-wizards, someone
put the apprentices on call
;-).  

Seriously, we can continue to answer 'how do I do this' type questions, but
with new technologies rolling out quicker and new threat vectors growing,
the matrix gets too big too fast (IMO).  We need short cuts.  If people can
refer to a document or even several documents and shorten the discussion to
some references and some specific examples we MAY keep up.


-- 
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