|
As the script kiddies get more sophisticated, Leif, I think you need both strong network policy procedures and proprietary protocols. I don't pretend to be able to secure a system against a targeted, malicious attack. I'm just trying to keep people from inadvertantly opening their systems to the world. As Jeffrey Silberberg pointed out, the only REALLY secure system is one that isn't running. Other than that, you CANNOT secure a system. That's because there's one route into a supposedly secure network that will always work: compromise a trusted employee. No security system in the world can guard against that. On the other hand, you can guard against script kiddies and other forms of random e-violence (e-vandalism?), and that's what I try to tell people. It's a classic trade-off: protection against random attacks vs. extra programming effort. Sort of like taking out fire insurance on your house. You probably will never need it, but most banks won't give you a mortgage if you don't. I think the same should be true of protection against non-targeted security breaches. Joe > -----Original Message----- > From: midrange-l-admin@midrange.com > [mailto:midrange-l-admin@midrange.com]On Behalf Of Leif Svalgaard > Sent: Wednesday, August 15, 2001 9:09 AM > To: midrange-l@midrange.com > Subject: Re: IIS to as/400 odbc > > > From: Joe Pluta <joepluta@PlutaBrothers.com> > > > I personally prefer to use a message-based design > > where I have designed the protocol and nobody on the > > outside is likely to be able to hack it > > Joe, > I generally agree with you that being in control of the > interface is a good thing, but I would disagree with > your "security by obscurity" argument. True, if you > use a proprietary protocol, that the 'script kiddies' > are left out in the cold, but if your system is worthy > of attack, the bad guys will get you anyway.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.