tag:blogger.com,1999:blog-13756280.post235278888871796975..comments2015-03-21T20:45:26.370-07:00Comments on Jeremiah Grossman: Real-World website vulnerability disclosure & patch timelineJeremiah Grossmanhttp://www.blogger.com/profile/05017778127841311186noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-13756280.post-42794656080979709992009-05-08T14:59:00.000-07:002009-05-08T14:59:00.000-07:00What's the risk involved?What's the risk involved?Andre Girondahttp://www.blogger.com/profile/17414510788948258195noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-82913093892629438902009-05-08T14:52:00.000-07:002009-05-08T14:52:00.000-07:00To piggyback onto Security Retentive..
"This seem...To piggyback onto Security Retentive..<br /><br />"This seems to undermine any SDL process that the organization may have in place.?"<br /><br />Or perhaps measure its TRUE effectiveness, which from our vulnerability assessment measurements they vary greatly and never achieve 100% perfection.<br /><br />"In my opinion, if your SDL process is of any merit then there should be nothing to find during your assessment."<br /><br />I think this is a bit extreme. Just because you find vulnerabilities in production after an SDL cycle, this doesn't mean the entire process is worthless.<br /><br />Fact of the matter also is strange things happen where going from test to production systems even in "mirrored" environments. Again, thing WE can and HAVE measured.Jeremiah Grossmanhttp://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-1940045224548435482009-05-08T14:41:00.000-07:002009-05-08T14:41:00.000-07:00While in theory this isn't necessarily a bad idea ...While in theory this isn't necessarily a bad idea Matt, when people push code to production do they do post-push testing of their live site? or, since their QA testing processes were "guaranteed" to find all of the problems, and the administrators who pushed it were guaranteed to not make any mistakes, should they just go home and not test the production system to see if things are working?<br /><br />I think most people do a code push, and then they do some limited testing on their production site just to make sure its up and running, their process didn't miss anything, no configurations got broken, etc.<br /><br />Why wouldn't you want to include security testing in there just in case?Security Retentivehttp://www.blogger.com/profile/07177656204885181542noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-22482907166795770812009-05-08T14:06:00.000-07:002009-05-08T14:06:00.000-07:00As an AppSec professional that works for a very la...As an AppSec professional that works for a very large enterprise I have to disagree with your statement "[w]hen new Web code is pushed to production its a really good idea to have a vulnerability assessment scheduled immediately after to ensure security." This seems to undermine any SDL process that the organization may have in place.<br /><br />In my opinion, if your SDL process is of any merit then there should be nothing to find during your assessment. If the application being pushed handles "sensitive data" (using the definition of sensitive that is defined by the organization), then by all means security defects should be fully remediated before the application is loaded into production. In this scenario, an assessment becomes nothing more than busy.<br /><br />Taking a holistic approach to the entire process, I believe that the first best thing an enterprise can do is to define a clear set of information security standards (which include application security standards) and distribute these to all developers. These standards should spell out everything that a developer should consider when developing an application. To take it one step further, it would also be good f the organization developed a set of best practices and examples for developers to refer to when writing code. In this manner, code reviews become increasingly simple and quick, because the code utilized for a given feature has been vetted by security professionals and is known to work securely under numerous scenarios. At this point, all that is really required in the code review is to verify that the example was properly followed/implemented, thereby giving developers more time to focus on scrutinizing their custom business logic for flaws.<br /><br />The next great step to take, in my opinion, is to gather information about the organization's standard SDLC process and modify it in such a way that it includes questions and processes that make both developers and business/marketing divisions think about security during the concept and design process. In this way, when a BRS/SRS comes down to the developer, security has been thought of - at least to some level - and hopefully there are development requirements that directly address the security concerns of the system. This modification provides at least a four-fold benefit. One, the security concerns and controls required to adequately protect the system are now documented somewhere. Secondly, the developer does not have an out of <I>I didn't put that [meaning that security feature] in there because it wasn't in the documentation. </I> Furthermore, if security is thought about during concept and design, many problems can be resolved early, which is always good. As most of the flaws caught during these steps are going to be architectural in nature, the benefit compounds on itself exponentially as more and more stuff gets added to the final product. This is true due to the simple fact that architectural changes almost always touch every aspect of a system, and that once you get to a certain point the only recourse you have to remediate is a complete re-write - which effectively nixes any chance of fixing the bug in the first place. Lastly, since the security controls are documented, auditing for the proper controls becomes A LOT easier.<br /><br />All-in-all, if a large enterprise wants to be secure it has to embed security inside of the software development life cycle. Now I do not necessarily thinks this constitutes forming a "Secure SDLC" but rather necessitates forming an "SDLC that considers Security".Matt Pressonhttp://www.blogger.com/profile/02537815584811632732noreply@blogger.com