I still believe to avoid the fear of spoofing, that an authenticator such as VeriSign, PGP, and many others, offer keys on both sides. So if I was to spoof my IP, but did not have the correct key to upload my file to you, your system would reject the transaction. I believe although not an expert in SSL, that holes have been found in it. Someone originally posted a link to an article explaining this. As far as integrity control. my opinion is this must come from within the organization. I also agree that most attacks on systems, come from within. So messages, and the authentication should come from encryption key pairs. I setup VeriSign site server and issued keys to my clients. So they can have any IP they want, but if they didn't have the certificate to match, they were shot down.Then there are simple programs such as NeoTrace, to trace the IP that has hit your firewall. If the company sending is supposed to be in CT, and the IP trace goes to England, something is up. Either they are using proxy servers, or you have a fraudulent transmission. Between the two, I have managed to keep many people out of my systems. Let's add another attack, DOS (Denial Of Service). I have seen top notch organizations get pounded by packets to the point of taking down their system. All this was done by was a kid, using a port scanner, and then selecting who he wanted to flood. The system he used for packet flooding was indeed genius, not just someone playing, but it has and will continue to be attempted. Trojans(programs planted on your server to send information out) are another issue to deal with.Many times I find these planted by angry employees of organizations. In conclusion, my entire point is this; we will continue to get false messages, port scans, Trojans, and even in some cases DOS attacks. Properly configure software, and hardware is the best we can do to countermine these efforts. http://grc.com/default.htm XP hole, that allows deletion of files. http://grc.com/dos/drdos.htm A brutal attack for no apperant reason.
This is just a sampling of what is going on out there. That's my nickel. Hope this made some sense :-)) Anthony Mercaldi ----- Original Message ----- From: "Chris Riley" <[EMAIL PROTECTED]> To: "Bill Pankey" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, September 16, 2002 3:37 PM Subject: Re: 'Integrity Conrol' vs 'Message Authentication' > Bill, > I think when we talk about TCP being a reliable transport we are just saying > that the packets are guaranteed to be delivered somewhere. It doesn't > guarantee that each packet in the message came from the same author or even > same machine. SSL takes this a step further and guarantees ( via the > certificate) that the message packets came from an authenticated source and > that the message in total has integrity. Both 2001 and 2002 FBI/CSI > Computer Crime Reports highlight the fact that a much higher percentage of > intrusions/attacks are from the inside the LAN. Given the fact that it is a > fairly unsophisticated operation to set up a "man in the middle" attack on a > LAN carrying un-encrypted data, I think it makes relatively good sense to > transmit PHI over a LAN with integrity and authentication controls. > > I would be interested to hear what others think, > Chris Riley, CISSP > > > Bill Pankey wrote: > > > Tim > > > > I admit to finding this aspect Security NPRM difficult. Message > > 'integrity' is the sine qua non of the HCO enterprise network ... and > > multiple layers of controls are used to ensure as much. To pull off any > > single control (or a limited set) and say 'this is my integrity service' > > seems misleading at best. > > > > So, when asserting that 'the network' (from TCP to detection and audit) > > is the integrity control or that 'integrity' is a property of the > > network, what do you suppose is the 'compliance test'? To implement > > ipsec or ssl merely to simplify demonstration of compliance is obviously > > bad headed and (I hope) a non-starter. > > > > Thanks, > > > > Bill Pankey > > -- > Chris Riley, CISSP > Information Tool Designers Inc. > http://www.info-tools.com/ > > > > > To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list=Security > and enter your email address. > > <P>The WEDI SNIP listserv to which you are subscribed is not moderated. The > discussions on this listserv therefore represent the views of the individual > participants, and do not necessarily represent the views of the WEDI Board of > Directors nor WEDI SNIP. If you wish to receive an official opinion, post > your question to the WEDI SNIP Issues Database at > http://snip.wedi.org/tracking/. > Posting of advertisements or other commercial use of this listserv is > specifically prohibited. > > To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list=Security and enter your email address. <P>The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.