>> And answering that ["secure against what?"] correctly requires input >> from the customer. Which we (TINW) won't have until customers >> recognize a need for security and get enough clue to know what they >> want to be secure against. > If you are asserting that the customer must tell you how many > security features to implement based on their requirements. I'll > agree 100%. Stuff like, "I don't need 3 types of military grade > encryption added, I'm just doing recipe sorting." That kind of > stuff.
Well, I was thinking more like, "needs to withstand potentially hostile user input on this input channel, but not on that one". As a simple example, a webserver usually needs to withstand potentially hostile input from the network, but not from its config file. (If it *can* handle a hostile config file without crashing, great. But if there's a choice to be made, I'd put the brain cycles into hardening the network interface before the config-file interface.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
