> On Sat, 4 Jun 2005, Darren Reed wrote:
> > > No. It's like I have a viewpoint on how to setup, configure, and
> > > manage a network which was formed years before UPnP was invented.

> >
> > Right and now that viewpoint is growing stale. The IT industry is
> > very dynamic, you need to grow and move with the times or get left
> > behind.

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

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

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.

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

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
are too easily removed and once gone, any benefit they provided also
goes with them. This doesn't seem beneficial to anyone, to me.

Rather, security needs to be integrated and designed in. Risks need
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.

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

firewall-wizards mailing list