> But the vast majority of clients I work with don't have the time or need or ability to take advantage of BSIMM
Mike's Top 5 Web Application Security Countermeasures: 1. Add a security guy or gal who has a software development background to your application's software development team. 2. Turn SSL/TLS on for all connections (including both external and backend connections) that are authenticated or that involve sensitive data or functions. 3. Build an Enterprise Security API (a.k.a. an ESAPI, e.g. OWASP's several different ESAPI toolkits) that is specific to your solution stack and minimally provides input validation controls that use whitelists, output encoding/escaping controls (optionally use parameterized interfaces for SQL), and authentication controls. Build your ESAPI to target a specific level of overall security when all of your security controls are viewed as a whole (e.g. an OWASP Application Security Verification Standard (ASVS) level). 4. Write a programming manual (i.e. a secure coding standard that is specific to your solution stack that is organized by vulnerability type or security requirement with before and after code snippets, e.g. a cookbook that provides before and after code snippets and links to API documentation) that contains step-by-step instructions for using your ESAPI to both proactively guard against vulnerabilities, and to act as a quick reference when the time comes to make fixes. 5. Gate releases of your ESAPI library (e.g. if it is being packaged in a wrapper for subsequent use by other developers throughout the application) with security functional tests that include sufficient negative test cases to demonstrate the security controls are working using data that is specific to your application. Gate releases of your application (ideally gate source control checkins) with security-focused code reviews of all new or updated application code produced during the release (looking out for where new or updated security controls/security control configuration updates are needed). Mike On Tue, Feb 2, 2010 at 7:23 PM, Steven M. Christey <co...@linus.mitre.org>wrote: > > On Tue, 2 Feb 2010, Arian J. Evans wrote: > > BSIMM is probably useful for government agencies, or some large >> organizations. But the vast majority of clients I work with don't have >> the time or need or ability to take advantage of BSIMM. Nor should >> they. They don't need a software security group. >> > > I'm looking forward to what BSIMM Basic discovers when talking to small and > mid-size developers. Many of the questions in the survey PDF assume that > the respondent has at least thought of addressing software security, but not > all questions assume the presence of an SSG, and there are even questions > about the use of general top-n lists vs. customized top-n lists that may be > informative. > > - Steve > > _______________________________________________ > 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. > _______________________________________________ >
_______________________________________________ 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. _______________________________________________
