Security Basics mailing list archives
Re: Secure host newbie - fun - humm
From: Ranjeet Shetye <ranjeet.shetye2 () zultys com>
Date: Tue, 06 Apr 2004 16:00:29 -0700
ok, lets talk facts. I consider kernel.org to be a well-secured site, because it is secured (in various ways - best practices, technological locks, user awareness, IDS etc.) against all known attacks as of today. However, based on the intangible "some form of knowledge" that you've laid claim to, you say that kernel.org is insecure even today. Prove it. Show us that kernel.org is insecure. I'll let the facts speak for themselves. On Tue, 2004-04-06 at 14:11, Barry Fitzgerald wrote:
Ranjeet Shetye wrote:Please dont tell me how much I have or have not worked with security.Please don't make statements that leave only the conclusion that you haven't worked in security for long, if at all.For security to work correctly, the user should have black and white choices. For the user to make a concious choice between secure and insecure mode, the person deploying it should offer black and white choices (e.g. hotmail login). In order that the people deploying the solution can make concious black and white choices, people who design the solutions have to MAKE and OFFER black and white choices.I agree with your point here. It's too bad you didn't say that in the first place.This is where I come in. I do network protocols design, security solutions, and kernel work for a living.Congratulations.Now if people in my position were to not view security as a black or white issue, the deployers would end up with a greyish "solution", and the users would end up with a smudgy hazy grey that would be wrongly passed around as a secure solution.I never once advocated that you give people a "hazy grey" solution. Not once did I ever say that. However, as an implementer, it is your obligation to understand the nature of insecurity. The nature of insecurity *IS NOT* black and white. If you don't understand why that is, then you are doing a disservice to your customers. What you know to be true and what you show your customers are not the same thing. You engineer your solutions for your customers with the knowledge that you have. Looking at security as black or white, you invariably have to box yourself into the belief that all you know about security procedures is all there will ever be, not looking for the unorthodox things along the way. If you are looking for unorthodox methods of compromise, then you're admitting that security is not black and white. Which is it?You are focussed on the fact that the "real world" is not black and white.I'm focused on the fact that security is not black and white.In my job, I HAVE to view security as black and white, and design stuff accordingly, and offer choices accordingly, because the farther up this design chain that someone compromises the concept of "either completely secure or else its insecure", the more compromised the final deployed solution that the users actually use.Yes, in your position. But, again, saying that and turning around and saying "security is black and white" are two entirely different things. If you can't speak outside of your experience, then you simply shouldn't. You had a good point initially, it's too bad you had to take my disagreement and turn it into a "yes/no/yes/no" argument about the nature of security.e.g. I can design the most secure system in the world, but that's meaningless if the users put their password on a sticky on their monitor. On the other hand, if I allow the use of telnet to backup sensitive data like passwords, then the I've just compromised even the most savvy user, and I force them to work outside the system to achieve their security goals. Therefore, should telnet be allowed ? NO - its a simple, black and white decision. You have a vendor who forces telnet onto you ? then you have a vendor who doesn't care about the security of your digital assets and I suggest that you vote with your money.Again, you're boxing yourself into your own experience again. When I said there were valid uses for telnet, I didn't mean for people to get boxed into using telnet. I agree completely and that's why I labelled telnet as insecure. However, if you have assets that are on an enclosed LAN with no internet access or that aren't that valuable to you, then a lightweight protocol like telnet might be a better engineering choice than a heavier protocol like SSH. That's no black and white there - it's gray... again. Encryption doesn't inherently mean security and likewise, not being encrypted doesn't mean inherently insecure. It depends on your context and your resources.As I said before, if you have run systems where there is no known weakness - that's secure. If you run systems where there is a known exploit - that's insecure.No - it's "believed to be secure"... there's a major difference. If you advertise and guarantee security in the fashion you have above, prepare to be sued by your customers.That fact that you "know" that all boxes in the world are insecure is not the "know" that I am talking about.But, it is a form of knowledge that matters. Like I said, you can stick your head in the sand all you want -- that's just being ignorant. You advocated people shutting off production boxes because of the *possibility* of them being attacked. You should be prepared to back that statement up in all cases... or concede that it's not the correct answer.I think we should just agree to disagree.But, then I'd be doing you a disservice. :) -Barry
-- Ranjeet Shetye Senior Software Engineer Zultys Technologies Ranjeet dot Shetye2 at Zultys dot com http://www.zultys.com/ The views, opinions, and judgements expressed in this message are solely those of the author. The message contents have not been reviewed or approved by Zultys. --------------------------------------------------------------------------- Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off any course! All of our class sizes are guaranteed to be 10 students or less to facilitate one-on-one interaction with one of our expert instructors. Attend a course taught by an expert instructor with years of in-the-field pen testing experience in our state of the art hacking lab. Master the skills of an Ethical Hacker to better assess the security of your organization. Visit us at: http://www.infosecinstitute.com/courses/ethical_hacking_training.html ----------------------------------------------------------------------------
Current thread:
- RE: Secure host newbie - fun - humm Charles Highsmith (Apr 02)
- RE: Secure host newbie - fun - humm Ranjeet Shetye (Apr 05)
- Re: Secure host newbie - fun - humm Barry Fitzgerald (Apr 07)
- Re: Secure host newbie - fun - humm Ranjeet Shetye (Apr 07)
- Re: Secure host newbie - fun - humm Barry Fitzgerald (Apr 07)
- Re: Secure host newbie - fun - humm Ranjeet Shetye (Apr 07)
- Re: Secure host newbie - fun - humm Barry Fitzgerald (Apr 07)
- Re: Secure host newbie - fun - humm Ranjeet Shetye (Apr 07)
- Re: Secure host newbie - fun - humm Barry Fitzgerald (Apr 07)
- Re: Secure host newbie - fun - humm Barry Fitzgerald (Apr 07)
- RE: Secure host newbie - fun - humm Ranjeet Shetye (Apr 05)
- Re: Secure host newbie - fun - humm Fredrik Hult (Apr 12)
- <Possible follow-ups>
- RE: Secure host newbie - fun - humm Chinnery, Paul (Apr 07)
- corrected HIPAA facts. Ranjeet Shetye (Apr 07)