[Esapi-user] FW: [Esapi-dev] Call for review of crypto code
Boberski, Michael [USA]
boberski_michael at bah.com
Fri Apr 30 12:09:57 EDT 2010
See also: http://code.google.com/p/owasp-esapi-java/wiki/esapi4java_v2_Sample_usage the subsections for PCI and DISA AppSec STIG, as examples of the below, to try to lead/focus reviewers.
From: Boberski, Michael [USA]
Sent: Friday, April 30, 2010 10:46 AM
To: Kevin W. Wall
Subject: RE: [Esapi-dev] [Esapi-user] Call for review of crypto code
>> It's our use of algorithms and key management that we should solicit reviews of.
> I completely agree with this and have been saying this all along.
Kevin, an idea. Let's add some crypto sections here: http://code.google.com/p/owasp-esapi-java/wiki/esapi4java_v2_Sample_usage to specifically focus people on the above "top down" approach.
If we can come up with some domain-specific requirements/use cases for using ESAPI crypto, then we can give someone a link and say for this business purpose is it "right" to you, and they can drill down to the degree they wish, but starting from the top down.
For example, maybe let's add a PCI section:
* Sample usage
o Using ESAPI to meet ASVS requirements
o Using ESAPI to meet PCI requirements <-- I CAN ADD THIS
+ Requirement 3: Protect stored cardholder data <-- YOU/WE CAN WRITE THIS
o Using ESAPI's WAF
E.g., how would you do this using ESAPI: "For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not
needed, and not sending PAN in unencrypted e-mails. "
Is it a best practice to encrypt not just cardholder data but also encrypt truncated cardholder data, or subsets of data in either case, and provide some direction as to which data/datum to encrypt and use code snippets with variable names that imply ESAPI's being used for that purpose. Would you use ESAPI to encrypt emails (I know the answer, but you'd provide guidance in the sample usage that that's not what ESAPI's intended for), another example of how to direct and scope the review.
Note, doesn't have to be PCI, can be any other source that you want. For example, a scenario that compels the use of MACs.
More information about the Esapi-user