tag:blogger.com,1999:blog-2511631377600597263.post2324416601989140299..comments2023-10-29T14:05:00.630-05:00Comments on Nick Coblentz: How Often Should I Reassess My Web Applications?Nick Coblentzhttp://www.blogger.com/profile/02039723015167872217noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-2511631377600597263.post-82456129561416371602010-01-20T12:48:50.182-06:002010-01-20T12:48:50.182-06:00There are also several situations where applicatio...There are also several situations where applications assessments are very well suited. Some of those situations include:<br /><br />1. Organization A acquires Organization B along with thousands of web application assets. Organization A has an application security program, but Organization B does not. Organization A needs to determine their risk posture and the level of effort required to remediate these newly acquired applications.<br /><br />2. An organization needs to satisfy regulatory, compliance, or legal requirements (Yes, I know everyone will get bent out of shape about this one... but the current state of these requirements mandate one or a combination of assessments, penetration testing, and code reviews)<br /><br />3. An Organization wants to provide assurance to customers that purchase developed software.<br /><br />4. A Customer wants to ensure the third party software development shop provides an application with an appropriate risk-level. Possibly as part of the contract agreement. (See the OWASP Secure Software Contract Annex project)<br /><br />I'm sure there' more...<br /><br />As you can see, there are many strategic reasons for carrying out assessments in addition to just checking to see if were "secure".Nick Coblentzhttps://www.blogger.com/profile/02039723015167872217noreply@blogger.comtag:blogger.com,1999:blog-2511631377600597263.post-64434856318100786402010-01-20T12:29:26.647-06:002010-01-20T12:29:26.647-06:00Dre,
I agree in some respects with you... The so...Dre,<br /><br />I agree in some respects with you... The so called "Security Whack-A-Mole" approach is a pretty inefficient way to reduce risk in application assets. It also does not have a lasting impact on the way future applications are developed within an organization. This is where security training, secure coding standards, and training and accountability against those coding standards help.<br /><br />This is also why many of my blog posts discuss secure software development processes, application security program management, secure coding techniques (see my struts 2 blog posts), and frameworks like the Software Assurance Maturity Model.<br /><br />Unfortunately, as you hinted, organizations only seem to be interested in penetration tests, vulnerability assessments, code reviews, and etc. I have encountered very few organizations that truly have a secure software development process other than... yeah we do assessments before we deploy to production.<br /><br />This is also evident in how few organizations seek out strategic consulting services centered around developing a long term application security program. I and other members of the AT&T Consulting team offer comprehensive services around defining and implementing secure software development processes and application security programs. I believe this is the future of our industry and that we are slowly but surely moving in this direction. Give it a five more years, and I think you will like how the situation evolves.<br /><br />With that said, assessments do have their place. Assessments are VERY useful for organizations that have a mature process and need to identify gaps in their security policies and secure coding standards. If an organization abides by all their rules and standards and still yields a vulnerable application, a security assessment is a great way to point it out and learn which controls and practices need to be added.<br /><br />Additionally, Security assessments, penetration testing, and code reviews are often the "Gateway Drug" to application security. Most organizations start with this activity and over time they realize more is necessary. They begin reaching out to OWASP, WASC, and consulting organizations, asking questions like "What next?" <br /><br />I believe assessments are still very necessary to organizations; the part that I believe you are trying to point out is that they aren't always leveraged correctly by development groups, nor do these groups take the proper lessons away from these engagements.Nick Coblentzhttps://www.blogger.com/profile/02039723015167872217noreply@blogger.comtag:blogger.com,1999:blog-2511631377600597263.post-30771991025744237182010-01-20T12:00:37.994-06:002010-01-20T12:00:37.994-06:00This seems to presuppose that assessments are what...This seems to presuppose that assessments are what is necessary in the first place.<br /><br />Instead, custom application lifecycle management solutions should include software security practices and tie them directly to a framework-specific OWASP ESAPI (or a platform that resembles "an ESAPI"). The ESAPI should include validation to a certain OWASP ASVS level (1-4) and type (A or B in the case of levels 1-2).<br /><br />I believe strongly in avoiding hamster-wheels-of-pain for information security management, even if it's an unknown, murky water such as application security at stake. Attempting to "re-assess" applications or sets of applications (based on risk posture) at any interval (i.e. it doesn't matter if it's weekly, yearly, or every 5 years!) it a complete waste of time.<br /><br />Penetration-testing activities may still be useful every so often, but this should not be mandated by any regulations or standards. Note that this means that I do indeed dislike how PCI DSS "prescribes" what you refer to as `[requiring] new tests after a fixed period of time ... [and] common for organizations to conduct security assessments of high and medium risk applications every six months to one year'. Most (if not all) organizations should seek alternate or compensating controls to satisfactorily meet Requirements 5, 6, and 11.<br /><br />It would be better if PCI DSS and many other regulations/standards were re-written to denote that penetration-testing and vulnerability testing (whether manual or automated) should be replaced with an ESAPI-equivalent that has been verified to a level/type agreeable to what PCI DSS intends to protect. Perhaps ASVS L2B or L3 would be closest to appropriate?<br /><br />I sincerely dislike how immature our industry has been for several years around these matters. I politely invite you to change what it is that you do, and what your customers do, in order to extend budget, save money, and implore better practices.<br /><br />We (as an industry) no longer need penetration-testing or vulnerability testing in the manners that you describe. I would compare your strategy and tactics to the use of medicine before bacteria was discovered and a paradigm shift occurred where medical "doctors" were actually able to save lives instead of quite the opposite.drehttps://www.blogger.com/profile/17414510788948258195noreply@blogger.com