Bill,
Thankyou for the reply to my posting. I hope that I did not offend
you with my posting. I'm only debating the boot from DOS issue,
not attacking you or your product.
Bill Hancock wrote:
>> mdr wrote :
>> So you believe that OS security has nothing to do with network security?
>
>Never said that. I don't believe it, either. But, in pure network
>pass-through in a standalone kernel which IS the OS (as security kernel
>design requires), that's as secure as it gets - in theory and practice.
Not really, multilple layers of security are better than one layer -- in
theory and practice.
The proxy application represents one layer, the OS another. If the OS
layer can detect/prevent problems that arise in the proxy, then we
gain security (provided that the OS layer itself doesn't present its
own security problems). However, note that while the OS layer may
present a target, that the only way to reach the OS layer over the
network is , um, over the network. So an OS can be configured to run
only minimal services and to carefully monitor the services that it
runs. From a layering perspective, this is a big win over a monolithic
standalone security thingy that does it all.
>>I think KM's remark was meant to be a humorous slurr against the dumb
>>box theory of firewalls. I laughed when I read it, but braced myself
>>for the postings that would follow.
>
>Sorry. Didn't find it humorous and didn't get it, especially when directed
>at what seemed to be a harmless query for information. As I said in my
>e-mail, I was forwarded the mail message I responded to.
I understand. And I feel for you. But on the other hand, I think
that KMG's reaction does represent a perpertual question w.r.t your
product's implementation. The question is: what have you done to
address the problem? Booting off DOS and taking over (if that's what
you do) is certainly a viable approach. But it needs to address host
security to guarantee for example that the binaries that you boot have
not been modified. It also needs some method of monitoring its own
operation. That's not easy. Your application may start looking like
an operating system, and then we're back to OS security again.
>>So lets fix it by removing memory management and supervisory mode right?
>>DOS is a giant step backward in terms of security. "Hardening"
>>generally refers to removing non-essential services.
>
>I come from a military and hard-core cryptoanalytic background. "Hardening"
>there has always meant the effort it takes to prevent any type of breach
>for any type of reason. Your suggestion of removing memory management and
>supervisory mode implies that DOS is incapable of either. I disagree,
>considering we had to build kernel software and purchase memory management
>software (DOS4G) to deal with both since DOS did not have what was required
>to do the job correctly.
Nice background. I too prefer a tougher definition for hardening an
OS. I'd prefer that it mean "evaluated by a third party against a
published criteria that speaks directly to the security aspects of the
problem at hand." My background is mostly orangebook related. The OB
was a vary good start IMO, given the time when it was written. We
need more relevent criteria for today, and especially for network
security.
Your statement: "DOS did not have what was required" seems to back up
the assertion "DOS is incapable of either". Adding on security to
DOS, is of course not impossible. Does the Firewall/Plus launch from
a hardened DOS?
>>The problem is that even stripped down, UNIX is still big and
>>complicated. But DOS is too small to protect itself.
>
>fact. With proper firewall software, rigorously coded, the essential
>components of DOS can be protected in act and deed.
Your showing that DOS can be protected, not that it protects itself.
>[snip] [micro kernels .. ] Can they protect themselves? Can any custom OS that
>runs in a standalone system, such as a bridge, router or custom security
>system, adequately protect itself at all? I don't know. I don't claim that
>DOS can. But, as a launching platform for a standalone kernel, it is no
>different than these variants and methodologies.
Do the micro kernels that you mention offer memory protection and
address seperation of processes from the kernel? Then they have a
much better chance of protecting themselves than DOS which is truely
a seive w.r.t. OS security.
>>Agreed, its not a bad idea. Is it as secure as a proxy on a gateway? No. >Why? I can put the proxy in a can and watch it run. Now I'm not
>>saying that you couldn't make the DOS-launched program as secure.
>>But by the time you added the memory management capabilites etc
>>required for that, you would have another OS and you would be right
>>back to OS security. W/o some independent third party doing analysis,
>>all I have is your word "trust me its secure."
>
>No, you can download it from our web site and test it yourself. It's not a
>demo - its the whole thing.
I'd rather trust a team of independent experts. What if I'm too busy
or not qualified to test it myself?
> I never made any assertion of "trust me, it's
>may make the same assertions for any OS or company who have not subjected
>their OS to TCSEC evaluation
Are you selling this as a security product or not? If you're making
no promises about security, then what are you selling? It is
*EXACTLY* "trust me its secure" that you're selling. You guys
probably have some security papers about your architecture that we
could read. That would be a good place to start.
>>But the basis of the argument, "if theres more there, then theres more
>>to fail" is sound. However the corrolary that you suggest "if theres
>>nothing there, then it must be completely secure" is false.
>
>You are suggesting a statement which I did not make. I did not make the
>corrolary and never suggested that it was completely secure. But I do know,
Sorry about that, I did read that in to your posting. And I
appologise for over reacting.
>from testing and live implementation of our product, that when the firewall
>software FAILS or is shut down, for any reason, the ability to reach either
>side of the network stops, cold. Period. And, this is with the DOS system
Yeah right, it couldn't possibly fail "open, Period". And w/o
independent evaluation we have only your word to back that up. Isn't
this "trust me its secure" in full force now?
>>If there is "absolutely no way to get through the network interfaces"
>>then how does the firewall function.
>
>The statement was "...if the firewall software should FAIL, there is
>absolutely no way to get through the network interfaces...". Obviously, if
>the software is running, you DO get through the interfaces. When the
>software stops or fails, you do not.
How do you know that when the software fails that it halts? Perhaps it
just stops functioning correctly.
>> Now if all you do is shovel packets in one
>>interface and out another, w/o anything like proxies, maybe you have
>>a point about the security of the box itself.
>
>If you read the specifications for the product, which was not the argument
>being presented in the e-mail, you will find it to be a "stately" packet
>and application filter. It is NOT a proxy firewall. It was never intended
>to be and is not marketed as such.
I assumed from your posting that it was probably a stateful packet
filter.
>I did not claim that DOS
>was secure - never did and never will. What I stated was that the use of
>DOS as an OS in a firewall does not make the firewall system a "sieve."
A point well taken. I didn't agree with KMG's remark, I just
laughed at it.
>>How do you know that dumb boxes *always* fail safe? What if the
>>software failure causes it to evaluate every rule as a "pass"? What
>>third party has validated your claims?
>
>I did not blanket-claim such a thing. I said OURS operates in this manner.
>We had it evaluated by several expert outside consultants, some of whom are
>well known and we hired with an NDA to keep the testing scientific and not
>a marketing extravaganza. We needed to know for ourselves that this was the
>case and not an empty claim. Again, download the software for yourself and
>trust your own skills.
Now you're finally talking!! Why not publish those testing results?
But you do admit to falling into my broad statement "How do you know
that dumb boxes *always* fail safe". So tell us. How do you know?
>I hope that this message properly addresses your issues.
Thanks Bill, it does answer a lot of questions. I don't mean to be
hard on you or your product. Launching from DOS is not a horrible
idea. It just presents a different set of security risks that have to
be addressed. I challege the basic assumption that such software
always fails safe.
Mark Riggins
Secure Systems Engineering
AT&T Bell Labs
Follow-Ups:
References:
|
|
