>> 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.

Reply via email to