Adam Jack <ajack @
corp .
micrognosis .
com> writes a manifesto:
> Sun aren't complete cretins. They have a tonne of experience of break-
> ins (through their own software on their machines ;-). HotJava can deal
> with the threats that any non-firewall-professionals - can dream up -
> and most that this list has raised.
Perhaps I'm sounding like a broken record, but you've got to plan for
tomorrow's threats, not yesterday's. The "firewall professional's"
threats of today are the bread and butter of tomorrow's attackers.
Or maybe I got that reversed.. :->
For the (broken) record, I think the Java developers did a fine job of
dealing with early '80s style security issues. But they didn't get a
handle on the desktop security issues early enough in the HotJava
design. It's a tough problem and they don't really have many models to
follow, so I'm not surprised they're having trouble. At least the Java
folks could follow the instruction set and pcode security traditions.
>> I'm very worried about Java, but all I hear are reassurances about
>> memory protection and default security levels. I, for one, am not
>> reassured.
>
> This is the statement that has been getting to me more and more
> through this Java thread. (Scott Barman irrated me to silence!)
> Reassurance isn't a right! ...
Competent firewall and security vendors do NOT subscribe to this
mindset. If a customer is concerned enough about security to seek a
quality product, they have every right to (re)assurance that the
protections they expect are in place. They deserve to know what
security measures are effective and deployed. They deserve evidence.
> I really hoped, given the experience on this list, that a better informed
> discussion might occur. Unfortunately there doesn't appear to be anybody,
> with experience, spending any real time analyzing it. ...
As you've probably figured out, this is expensive and time consuming
work. We do it for our own products. I admit it depresses me to have
the same, tired security questions go unanswered, and that I do not
have the time myself to try things out.
On the other hand, it shouldn't be so much to ask other vendors to do
their own job, too. It makes our life easier, and lets us help our
customers better. I had a hard time quantifying risks for customers
intending to use Netscape until the appropriate group of hackers did
the costly research Netscape didn't do. My hat's off to them. I hope
those guys will tackle HotJava now, unless Sun and/or Netscape pumps
in the resources to do it. Somehow I doubt they will -- security
doesn't appear to have much of a priority in their institutional
cultures. But it's nice that they're getting efficient at fixing their
security bugs after they occur. Reactive security, anyway.
> What I find depressing is the apparent - "its unknown - be scared"
> mentality. ...
> Surely - with an internet as diverse and rapidly changing as todays - it is
> one that is outdated. It is too obvious. (Facist 'old' Admin vs Coool $tuff)
> It is an expression of discomfort - not an approach to solve the problems.
It really is sensible to be cautious when handling a live wire of
unknown voltage. Things were much easier back in the Good Old Days
when we just used the 'Net for R&D and transcontinental Adventure
games. Things get a bit squirrely when you use it to run a business,
and your livelihood depends on correct results whose integrity you can
depend on. The raw, theoretical risk of running arbitrary, possibly
hostile code in numerous workstations... well, the mind boggles.
> Applications on the Internet are racing ahead. Despite the common sense
> demand for security - pressure for functionality is higher.
It depends on who you talk to. Our customers want both, but they
recognize there is a tradeoff. How many will put their back office
operations at risk just for "coool stuff" on desktops?? Not many.
> Java is just
> one of many emerging 'technologies' that will strain current firewall
> models. Firewall technology needs to evolve with the technological 'advances'
> (- and so do individuals.)
Evolving attack methodologies also strain current firewall models,
even without throwing HotJava into the picture. Sites concerned about
security want finer grained awareness of what crosses their boundary.
It's not clear how we meet their needs and also pass applets. Magic
doesn't exist, and firewalls can't perform mathematical miracles.
> What I don't hear from this list are criteria for quantifying risk.
If our customers are going to run Java/HotJava, they want it on every
desk, not just those belonging to a couple of R&D propellerheads with
some blue-sky proprietary data on their filesystems. The CEO and the
Director of Mergers and Acquisitions and the Custodian of Insider
Information will all want the spiffy stuff, too. It is not clear that
spiffy stuff will run on a HotJava system configured to run securely.
>.. How are firewalls going to deal with the next 20 Java's?
The same way this one is dealt with: a refusal to throw caution to the
wind simply because it's Kool Stuff.
I hate long postings.
Rick.
smith @
sctc .
com secure computing corporation
Follow-Ups:
|
|
