Re: Is NAT in OpenBSD PF UPnP enabled or Non UPnP?

["Paul D. Robertson" <paul () compuwar net>]

On Sun, 5 Jun 2005, Darren Reed wrote:

> > Security is about staid and static- that's part of the issue of why it's
> > difficult to inject it into companies that don't have a real driver for
> > it.
>
> I disagree.  Security is about being conservative, which doesn't
> necessarily imply being static/staid.  I think being static/staid can

Oh, but it does- the essence of security is about the tried and true.
Basic principles haven't changed in thousands of years, even when applied
to new technologies.  Security evolves very slowly, which is why the
marketing weasels have so much trouble with it.

> lead you down a path that can increase your security risk rather than
> maintain it.  I think being conservative, when it comes to IT, is just
> plain HARD and this is why companies find it difficult.

Google define: conservative:

resistant to change
opposed to liberal reforms
cautious: avoiding excess;
button-down: unimaginatively conventional;

Anything poorly implemented can increase your security risk, however it's
very rare that disallowing new content is one of them.

> > Those very dynamics are WHY we have the problems we have today-
> > active content without a security model, protocols without any length
> > limits, closed systems being "Webified," loaders that run anything
> > dynamically.  All these are the technological bits of the problem we face
> > daily.  Security needs to be a governor on the dynamic.
>
> I disagree.
>
> Security should be reactive to those dynamics, so it can evolve to
> meet new needs.  Well even reactive is bad (see below.)

In order of effectiveness, proactive security wins the day, reactive
security can't ever win, it can only limit the damage.

> We don't have the strength of x-bit length RSA keys controlling what
> speed CPUs get made, rather the increasing speed in CPUs drives up
> the requirements for encryption algorithms.

Ah, but the need for encryption comes from allowing sensitive information
to travel over untrustworthy channels.  That new dynamic requires a deeper
understanding of the downstream effects before its risks, like the time to
attack are properly understood.  Fortunately most cryptographers
understand this, which is why new algorithms take years to become accepted
for general use.

> To illustrate this point, what if AES was never brought to life because
> the standard is DES and damnit, we're not going to budge, it will be DES
> forever.

Look at the time it took though- some of the AES candidates had flaws
and many potential algorithms didn't meet the submission criteria; had
we allowed a dynamic customer-driven environment to suceede we
would have seen fielded.  It was DES until we had a suitable replacement,
not "bring what you want and we'll worry about fixing it later."

> I also think you're wrong about security needing to be a governor,
> because security types are too conservative and being a governor is
> to try and manage a situation you have no real control over.  THey

You're assuming security people don't have control.  This, I think is
Marcus's main point about giving in too soon.  If I have the passwords to
the firewall, I have control over what traverses it.  Real security
controls are totally about governing access- anything else is reacting
after a breach has occurred.

> are too easily removed and once gone, any benefit they provided also
> goes with them.  This doesn't seem beneficial to anyone, to me.

So don't let them be gone!  That's the whole point.  Remove the firewall,
you remove its benefits.  People are espousing that even now- but the key
to the security industry dealing with it is to put in new governors to
replace them (I'll let you take the network firewall if you allow me to
implement real host security...)

> Rather, security needs to be integrated and designed in.  Risks need

Of course security needs to be integrated and designed in, but that
governs the dynamic nature of development...

> to be investigated, understood and documented from the outset and
> mitigated where necessary.  However, this doens't address the problem
> of "software bugs" so we need to find ways to manage that.  Isolating
> the execution environment (this includes disk as well as memory) of
> something considered risky - e.g. any web browers - is something to
> think about and can be achieved, in part, on all unixes today, albeit
> the browser may lose some usefullness.  So we need to do a better job
> of achieving that.  As with the web, so too with any popular technology,
> if the designers aren't security savvy then we will have problems by
> design, later.  If security misses out at this step then it is very hard
> to shove it into the box later.

Which is why we prefer to slow them down and make them get it right than
to react to their dynamic ideas.

> We should think about ways in which we can achieve better security and
> functionality, at the same time, without tradeoffs and look at how we
> can develop solutions to achieve this.
>
> > > More chest beating.  These things are "old hat".
> >
> > Come on, "old hat" or "growing stale?"  We don't get to have it both ways.
>
> Hmmm, I forget what I said was growing stale.  But it was just a reference
> to security practices being mentioned as if they were somehow of special
> significance.

Ah, but that's the point- tried and true still mostly works, it's
generally only implementation details that sour over time.  Unfortunately,
these days of "let the users do anything and try to stem the flood
afterward" it is getting to be special again.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul () compuwar net       which may have no basis whatsoever in fact."
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards