Re: [SC-L] Security in QA is more than exploits
For starters I believe you misinterpreted my comments on QA. I was in no way slamming their abilities. With this in mind comments below. Before anyone talks about vulnerabilities to test for, we have to figure ou= t what the business cares about and why. What could go wrong? Who cares? Wh= at would the impact be? Answers to those questions drive our testing strate= gy, and ultimately our test plans and test cases. We absolutely agree here. At the same time an externally exploitable sql injection needs to get fixed. The way qa/development is informed to its impact is through education likely via training. Not a single company with average hiring/skill requirements will have everybody (who needs to) know what sql injection is, and why it is bad. Bias #3 is that idea that a bunch of web vulnerabilities are equivalent in = impact to the business. That is, you just toss as many as you can into your= test plan and test for as much as you can. This isn't how testing is prior= itized. I said A better approach in my opinion is to identify the top 10/25/x attacks/weaknesses/vulnerabilities that are likely to affect your own organization These would be associated to customer or business impacts likely to affect you. Perhaps this could have been articulated better. As someone who has been training in risk-based security testing for several= years now, I totally agree with some points, but very much disagree with o= thers. I agree that the bug parade (as we call it) of top X vulnerabiliti= es to find is the wrong way to teach security testing. Risk management, tho= ugh, has been a fundamental part of mainstream QA for a very long time. Lik= ewise, risk management is the same technique that good security people us= e to prioritize their results. Risk management is certainly how the busines= s is going to make decisions about which issues to remediate and when. Risk= management is what ties this all together. We agree. If there's something that QA needs to learn that they're not already learni= ng, it's the weaving of security into the risk management techniques they= already know how to do. If testers fall short in their ability to apply ri= In your experience do you find average QA people doing risk management? In my experiences a Sr QA person/Team lead identifies what is going to be tested for a given release, and usually are the ones writing/tracking the test plans. So, in some ways we agree: speak the lingo of QA. But in other ways we disa= gree. I think the original article fails to give credit to the decades of s= ubstantial research and practice in QA. In other words, it's a lot more tha= n speaking the language. It is standing on the shoulders of giants, not the= ir toes. Actually the main goal of the article is that information security people need to set appropriate expectations as to what QA cares about as their primary business function. They need to factor in that the majority of QA people don't care about security as a primary job function, and that if infosec wants them to care they had better be prepared - to speak their language and understand their needs - to customize and prioritize the security testing they may be doing instead of solely using generic top x lists Paco Have a fantastic day Paco! Regards, - Robert ___ 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. ___
Re: [SC-L] Secure development after release
Hello Andy, Once an application is released or put into production, what are organizations doing to keep the applications secure? As new Some organizations purchase web application security scanners and perform periodic scanning (this could be done by the soc) or use a service such as whitehatsec to perform continuous application level scanning. It usually boils down to company resources, finding qualified people to configure/run a tool, and/or budget. If you're using a service ideally they should be identifying the false positives and removing them from your reporting. If you're using a tool you'll need someone qualified to be able to identify if an issue is real or not and remove it. For the sake of saying it no tool can find all issues and having a human/tool combination is really required. Tools do very poorly at logic flaws which are often the most damaging. For more critical applications (dealing with Personal Identifiable Information) or those dubbed risky one off deep dive pen tests may be needed in addition to continuous scanning/monitoring. This will depend on frequency of application changes, budget, and resources. vulnerabilities and classes of exploits are released, how is that information being fed back to developers so they can update/patch in the software. At the network most organizations have a Network After the scanning is performed typically you'll have an assigned security resource (this could even be a QA/dev person depending on available resources) that files tickets with development (if this process isn't automated) to address each issue and owns the responsibility to follow-up on each discovery. Remediation timelines will vary depending on the flaw and unless their is a policy/management buy-in of some sort, forcing development to fix things in a given timeframe may be difficult. It is important to iron out the process regarding false positive identification otherwise development will take you less seriously when an issue is filed. Is there a formal method other than reacting to incidents? Is there a Yes by proactively monitoring and testing your applications for 'security defects' (pen testing/security assessments). sort of Operations or Intelligence cell that proactively finds and processes new information and feeds that info back to the design and development teams so they can update the software? It is important to note that development people aren't security people and they never will be (no matter how much the security people want them to be). Sure they will get better and stop making certain mistakes over time but most developers aren't monitoring the usual security outlets for the latest threats to see if their code may be affected. It is typically the job of a security team (local, service, or SOC) or auditing team (regarding compliance e.g PCI/SOX) to ensure that a given application is reviewed against the latest threats at the time of the evaluation. Depending on your setup a SOC may handle monitoring/incident response and scanning. Hope this helps. Regards, - Robert http://www.cgisecurity.com/ Application Security news and more http://www.webappsec.org/ The Web Application Security Consortium http://www.qasec.com/ Software Security Testing ___ 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. ___
Re: [SC-L] What's the next tech problem to be solved in software
On Wed, 6 Jun 2007, Wietse Venema wrote: more and more people, with less and less experience, will be programming computer systems. The challenge is to provide environments that allow less experienced people to program computer systems without introducing gaping holes or other unexpected behavior. I completely agree with this. This is a grand challenge for software security, so maybe it's not the NEXT problem. There's a lot of tentative work in this area - safe strings in C, SafeInt, StackGuard/FormatGuard/etc., non-executable data segments, security patterns, and so on. But these are bolt-on methods on top of the same old languages or technologies, and some of these require developer awareness. I know there's been some work in secure languages but I'm not up-to-date on it. You may find this interesting as this is a subject I feel strongly about myself. http://www.qasec.com/cycle/securityframeworks.shtml - Robert http://www.cgisecurity.com/ http://www.qasec.com/ ___ 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. ___
Re: [SC-L] Darkreading: compliance
Gary, may I suggest an alternative response to application firewalls and the notion that it is hair-brained? Of course this is true but this list is missing a major opportunity to finally calculate an ROI model. If you ask yourself, what types of firewalls are pervasively deployed, you would find that application-firewalls aren't. This would then mean that folks would either need to replace their existing firewall (very risky that no one would ever consider), add multiple firewalls which introduce operational complexity, etc. For many shops, having another type of firewall could cost millions whereas putting tools in the hands of developers may actually be cheaper. We as a community may be better served by encouraging application firewalls and letting the financial model for complying work in our favor... I think that appfirewalls have value depending on your expectation and situation. If you have a small website that doesn't change much then there may be value. If you are in a serious need to pass PCI or some compliance requirement quickly, an app firewall may buy you some time to address the problem correctly in development. If you have code pushes every 2 weeks with new content being added on a large website you need to understand that you'll need to hire an appfirewall person to constantly tweak rules plus the cost of the licenses. App firewalls are IDS/IPS's and should be treated as such except that the specifics are slightly different because it sits on the web layer which is considerably more complicated and dynamic. I'm an advocate of fixing the problem in the SDLC however one of the things that people fail to consider is SDLC integration with an existing process and large code base takes months, sometimes years to get right. Until it is properly integrated you're left with the decision of fixing vulns one at a time (as they come up) or/and placing additional filtering in place to reduce risk. Regards, - Robert Auger http://www.cgisecurity.com/ Application security news and more http://www.webappsec.org/ The Web Application Security Consortium http://www.qasec.com/ Software Security Testing ___ 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. ___
Re: [SC-L] Darkreading: compliance
what do you think? have compliance efforts you know about helped to forward software security? Compliance brings accountability. Without accountability or financial impact people have little incentive for putting security on the priority list. I for one welcome our compliance overlords. Regards, - Robert Auger http://www.cgisecurity.com Application Security news and more http://www.webappsec.org/ company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ 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. ___
Re: [SC-L] [WEB SECURITY] Wordpress website hacked, wordpress backdoored
a) the final binaries were the ones infected (very easy to detect (imagine if the infected code was actually from 'real' SVN source code and made from a 'trusted' developer)) b) by the speed this was detected the exploit (and the blog page didn't give a lot of details about it) must have been a very 'HEY I AM A BACKDOOR' kind of code. A real exploit would be one that (using a .NET The original mailing list post by Ivan Fratric is at http://msgs.securepoint.com/cgi-bin/get/bugtraq0703/28.html for those curious of the code differences. Given the brazen addition of multiple functions (instead of modifying an existing one to make it vulnerable) we're probably not looking at the highest caliber of attacker here. And OWASP uses WordPress (although Mike tells me that we were not affected) for our blogs Thanks for sharing about what OWASP runs. Not sure how this ties into the thread though. Again hats off to Ivan Fratric for spotting this before it became a much larger issue. Regards, - Robert http://www.cgisecurity.com/ Application Security news and more http://www.cgisecurity.com/index.rss [RSS Feed] Join us on IRC: irc.freenode.net #webappsec Have a question? Search The Web Security Mailing List Archives: http://www.webappsec.org/lists/websecurity/ Subscribe via RSS: http://www.webappsec.org/rss/websecurity.rss [RSS Feed] ___ 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. ___
Re: [SC-L] Meeting at RSA next week?
I'll be there. - Robert http://www.cgisecurity.com/ http://www.webappsec.org/ How many of the list members are going to RSA? Any plans to get together for some coffee? ___ 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. ___
Re: [SC-L] QASEC Announcement: Writing Software Security Test Cases
This is great, and something I have incorporated into our own cycle previously, as carving out a spot on our team as the security engineer didn't seem to work. But by creating a process for including security testing, abuse cases, etc. I was able to incorporate security without a big hit to the team. This sold management on the fact that it can be a simple and seamless process and soon became adopted. The other half of it is that you have to be the person on the team who always is thinking in terms of the corner cases, the worst case scenarios, the one who aggravates the development team the most. The fact of proving to management that this isn't an expensive decision is something that I think will start to catch on. By making this part of the process if an issue is discovered you have already scoped out that additional time needed to research and address the issue. QA has always aggravated development this isn't new :) Regards, - Robert http://www.cgisecurity.com/ http://www.qasec.com/ ___ 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. ___
[SC-L] Challenges faced by automated web application security assessment tools
I have released a new document 'Challenges faced by automated web application security assessment tools' that a few of you may find interesting. URL: http://www.cgisecurity.com/articles/scannerchallenges.shtml Comments welcome. - Robert http://www.cgisecurity.com/ Website Security news, and more! http://www.cgisecurity.com/index.rss [RSS Feed] ___ 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
