|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
RE: ICSA: Decertification [dry]
Jon McCown (jmccown
icsa.net)
Thu, 8 Oct 1998 19:13:54 -0400
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Justin Clift: "Port 1443"
- Previous message: Steven M. Bellovin: "Re: are firewalls limited to only protecting ehternet connections?"
-----BEGIN PGP SIGNED MESSAGE-----
[JDMC] Reply is at the bottom....
> post it to BUGTRAQ [3]... we ... talk with the vendor about
> decertification
> [4] (muhahaha).
>
>
[Huger, Alfred] That's an interesting assertion which begs the
question: Has anyone, during the entire time you have certified products,
been decertified? And do you, in the case of decertification, have any
process by which you would inform the public of this vendors lapse? More
importantly perhaps, has anyone who has submitted their product for testing
ever been failed and refused certification?
[JDMC] Begging questions are cool, although answering them out of
order will work best. FWIW the "post it to Bugtraq and have a beer" line
will
probably haunt me for a while....
(3) We have a number of vendors on their third and higher distinct release
which have
failed to achieve initial certification. Most get their act together on the
second try,
but for some it has been harder. So the third question: yes, absolutely.
(2) The process is "progressive publicity" where there is an initial five-day
period wherein the vendor is formally given notice and has opportunity to
provide
a workaround, patch, or whatever. If that doesn't occur, the product is
removed
from the certified list on the website. If after a 20 working days there is
no solution,
the product is "actively" listed on the ICSA website as being decertified.
(1) There have been situations where a certified product approached the 20
day
mark, but in these instances the vendors delivered 'deus ex machina' fixes
inside of
the deadline. In other cases vendors withdrew from the program and became
"non-certified" for reasons other than technical failure.
There is a nasty lashup of NDAs and contracts surrounding this, so saying
that
"Shemp-Net 3.2" failed seventeen times before getting to initial
certification
isn't quite possible. But if you happen to check on the web site and happen
see "Digital Moe-Guard's" version number spinning like an odometer
(or the whole thing blinking off and on), it does mean something. If it is
marked
"decertified"..... don't go there, it tanked.
Yes, the process is slower than an immediate post to Bugtraq* (or FW-WIZ),
but
it has a strong card to play in that if the vendor doesn't fix the problem
then the public _does_ get word. (someone else can repost it to Bugtraq*
though..)
I can't say whether the average CERT gets a vendor fix in less than 30 days,
but we do.
- - Jon
( is lack of security actually job security? aaack. )
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQCVAwUBNh1HMqN04bWY62GPAQF5vQP/b0pilYSPxat9rImMA8uoxapzFhHSB7Iw
CWOUWgleduFKYlTIVZ95HN2g+RRrNcYWwP4bHRCvat15E3F2iur09UUVhZzyIN3f
0PNUb2VXhicjZiBnU+EogckW0IRyixDWU0uoM7s/rAuNrgi58Jz5M8w+zH1nM7LP
dsNCim8x5Sk=
=awsL
-----END PGP SIGNATURE-----
- Next message: Justin Clift: "Port 1443"
- Previous message: Steven M. Bellovin: "Re: are firewalls limited to only protecting ehternet connections?"
This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:11:56 CDT