Re: [SC-L] Darkreading: compliance
Hi all, Another big momentum machine for software security (and data security) is PCI compliance. There is a challenge, though, and that is figuring out where the credit card data that you want to protect are. We've found in our practice at cigital that the data are literally scattered all over the enterprise. Because of this, hair-brained solutions like application firewalls (something called out in the PCI standards) often don't help. I think PCI compliance is doing for data security and data risk what SOX did for software security and sofware risk. They both help with problem awareness. To answer your question directly, we see lots of large enterprises working hard on PCI these days. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com. -Original Message- From: McGovern, James F (HTSC, IT) [mailto:[EMAIL PROTECTED] Sent: Mon Apr 02 11:15:49 2007 To: SC-L@securecoding.org Subject:[SC-L] Darkreading: compliance SoX has done a wonderful job of getting enterprises to embrace the notion of holistic identity and access management which wasn't occuring prior to it. It would be interesting to hear from folks here what other enterprise initiatives do you think that should be on the radar of large enterprises. * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ 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. ___ 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. ___
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. You are probably aware that Cisco Pix, Checkpoint, etc aren't app-level which says that incumbent vendors aren't the solution. Likewise, you are probably aware that for other than common protocols, you probably will have to pay big bucks to vendors to develop custom plugins to their closed source offerings and the procurement cycle times around this are lengthy at best. 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... -Original Message- From: Gary McGraw [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 10:01 AM To: McGovern, James F (HTSC, IT); SC-L@securecoding.org Subject: RE: [SC-L] Darkreading: compliance Hi all, Another big momentum machine for software security (and data security) is PCI compliance. There is a challenge, though, and that is figuring out where the credit card data that you want to protect are. We've found in our practice at cigital that the data are literally scattered all over the enterprise. Because of this, hair-brained solutions like application firewalls (something called out in the PCI standards) often don't help. I think PCI compliance is doing for data security and data risk what SOX did for software security and sofware risk. They both help with problem awareness. To answer your question directly, we see lots of large enterprises working hard on PCI these days. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com. * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ 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
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 definitely agree, and I strongly disagree with Gary that application firewalls are hair brained solutions. It's always my feeling, and I try to put this into practice in my current role, is that security is a multi-layer approach. From secure coding practice in development, proper QA cycle and regression testing, deployment security touchpoints, and finally adding the extra layer on the top is putting application layer firewalls in place, which if we ever have a 0-day style vulnerability it's very quick to throw in a rule to protect it, and begin working on a patch. Now I know that your consulting business relies on you promoting security from the inside but are you saying that application firewalls are pointless and we should stop using them? Or are you saying that it's rediculous that we ever got to the point where applications are so insecure that we need a transaction-per-transaction inspection mechanism to make sure the bad guys aren't getting us? You may want to clarify this a little bit for us sec-newbs JS ___ 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
On 4/4/07, J. M. Seitz [EMAIL PROTECTED] wrote: From secure coding practice in development, proper QA cycle and regression testing, deployment security touchpoints, and finally adding the extra layer on the top is putting application layer firewalls in place, which if we ever have a 0-day style vulnerability it's very quick to throw in a rule to protect it, and begin working on a patch. Absolutely, for me the best use of WAFs is to use them to fix or mitigate known (to the web application owner) vulnerabilities. This is the place where you get maximum ROI from it. Trying to use WAFs across the board on all pages and fields works ok for simple web applications and for simple things (like detecting SQL error messages going to the user), but give it a complex app, and you will have massive and complex rules. They are also usually quite brutal in their responses since they don't allow dynamic content manipulation, they only allow binary decisions (aka 'when an attack is detect redirect to page xyz') And why don't the WAFs promote this use case more? Every time I have a 5h discussion with them (last couple OWASP conferences :) ) they tell me that their clients don't ask for it (which is not true since one of my clients (major financial institution) uses a WAF do 'mitigate' known vulnerabilities on a COTS). I think the real reason is that the current WAFs (with some uses of ModSecurity being an exception) don't have access to the state of the application (i.e. the business layer and data layer) so there are tons of vulnerabilities that they can't mitigate against. Basically in order to mitigate a vulnerability the current WAFs needs that the application gives them clues of what are valid and non-malicious requests (something that is easy on technical vulnerabilities (aka SQL Injection) but very hard for 'Business Logic Vulnerabilities' (should this user be accessing this data or making this transaction?') This is why I jokingly said ' currently WAFs don't protect against layer 7 attacks, they only protect from Layer 7 1/2 attacks :) Dinis Cruz Chief OWASP Evangelist http://www.owasp.org ___ 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
At 9:29 AM -0400 3/30/07, Benjamin Tomhave wrote: SOX has been a complete waste, imo. First, the majority of it was already covered in existing law. Second, it really has nothing to do with security from a practical standpoint. The only purpose SOX has served is to give auditors another source of revenue. And, worse than that, it initially gave auditors the appearance of more power and responsibility, which I saw carried out in external auditors trying to dictate to businesses how the business should operate (and not in a good way). Talk about a fundamental violation of independence and objectivity. The pendulum has fortunately swung back on that trend. PCI DSS, on the other hand, has been a very good effort with real, meaningful results. Why is this? Well, for one thing, it's specific. As opposed to SOX, which paints with broad strokes and focuses on truth in reporting (gross oversimplification), PCI DSS goes into technical detail on what activities must be implemented, what minimum measures are for adequate security in a system, etc. Perhaps the best example of this thought is section 3.6 in DSS v1.1, where it details the minimum requirements for key management. It makes my job much easier having this level of detail, with much less left to interpretation (again, unlike SOX, where almost everything is open to interpretation and the whim of your auditors). That parenthetical comment is almost verbatim the description of SOX I received from someone who is subject to SOX audits. My own nomination for specificity in security standards is NIST Special Publication 800-53 (currently at Revision 1). http://csrc.nist.gov/publications/nistpubs/index.html#sp800-53-Rev1 Through all the controls there is only one requirement with which I disagree. -- Larry Kilgallen ___ 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
On Tue, 13 Mar 2007, somebody wrote (attribution isn't clear to me): no. my feeling is that it focuses management on unimportant things like meeting checkpoints rather then actually doing useful things. I heartily agree. Compliance almost always becomes (in the worst sense of the word) a mantra to chant down all disagreement. Compliance becomes the *administrative* stick-and-carrot, rather like a driver's license in the US. That is, every US citizen has this set of nominal rights that nobody can take away. On the other hand, a driver's license is a privilege, so you have to jump through some hoops to get it, and it comes with mandatory behaviors, not all of them legal, most of them administrative. Life in the US without a driver's license is marginal. So, administrators use driver's licenses to punish and guide behavior in ways nominally, or legally, forbidden. Wink wink, nudge nudge. I'm most familiar with PCI, and some of the things that people put in it are just downright stupid. If you run your credit card processing on Solaris, why should you put in a virus scanner? Seriously, folks... Since compliance becomes an administrative tool, the weapons against actually paying for compliance become administrative, hence the focus on meeting checklist items. A checklist can't really contain all the capability of a general purpose computing system, as checklists do not have looping or decision making in them. So, they'll always have weird limits, and people will try to overcome those limitations by adding to the checklists. Compliance becomes a rallying point for the professional meeting attenders, parasites and hangers on, hierarchy jockeys. ___ 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
Once again i'll ask. Which vertical is the kind of company where you're seeing this awful behavior in? BTW, sammy migues agrees with you in a thread we're having on the justice league blog www.cigital.com/justiceleague (look under SOX). gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com. -Original Message- From: Bruce Ediger [mailto:[EMAIL PROTECTED] Sent: Tue Mar 13 12:10:42 2007 To: Cc: SC-L@securecoding.org Subject:Re: [SC-L] Darkreading: compliance On Tue, 13 Mar 2007, somebody wrote (attribution isn't clear to me): no. my feeling is that it focuses management on unimportant things like meeting checkpoints rather then actually doing useful things. I heartily agree. Compliance almost always becomes (in the worst sense of the word) a mantra to chant down all disagreement. Compliance becomes the *administrative* stick-and-carrot, rather like a driver's license in the US. That is, every US citizen has this set of nominal rights that nobody can take away. On the other hand, a driver's license is a privilege, so you have to jump through some hoops to get it, and it comes with mandatory behaviors, not all of them legal, most of them administrative. Life in the US without a driver's license is marginal. So, administrators use driver's licenses to punish and guide behavior in ways nominally, or legally, forbidden. Wink wink, nudge nudge. I'm most familiar with PCI, and some of the things that people put in it are just downright stupid. If you run your credit card processing on Solaris, why should you put in a virus scanner? Seriously, folks... Since compliance becomes an administrative tool, the weapons against actually paying for compliance become administrative, hence the focus on meeting checklist items. A checklist can't really contain all the capability of a general purpose computing system, as checklists do not have looping or decision making in them. So, they'll always have weird limits, and people will try to overcome those limitations by adding to the checklists. Compliance becomes a rallying point for the professional meeting attenders, parasites and hangers on, hierarchy jockeys. ___ 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. ___ 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. ___
Re: [SC-L] Darkreading: compliance
On 3/14/07, Gary McGraw [EMAIL PROTECTED] wrote: Once again i'll ask. Which vertical is the kind of company where you're seeing this awful behavior in? well, fwiw, i've noticed it in finance/investment, and the entertainment industries. but i honestly don't think the industry type makes a whole lot of difference. it's a corporate management thing. BTW, sammy migues agrees with you in a thread we're having on the justice league blog www.cigital.com/justiceleague (look under SOX). gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com. -Original Message- From: Bruce Ediger [mailto:[EMAIL PROTECTED] Sent: Tue Mar 13 12:10:42 2007 To: Cc: SC-L@securecoding.org Subject:Re: [SC-L] Darkreading: compliance On Tue, 13 Mar 2007, somebody wrote (attribution isn't clear to me): no. my feeling is that it focuses management on unimportant things like meeting checkpoints rather then actually doing useful things. I heartily agree. Compliance almost always becomes (in the worst sense of the word) a mantra to chant down all disagreement. Compliance becomes the *administrative* stick-and-carrot, rather like a driver's license in the US. That is, every US citizen has this set of nominal rights that nobody can take away. On the other hand, a driver's license is a privilege, so you have to jump through some hoops to get it, and it comes with mandatory behaviors, not all of them legal, most of them administrative. Life in the US without a driver's license is marginal. So, administrators use driver's licenses to punish and guide behavior in ways nominally, or legally, forbidden. Wink wink, nudge nudge. I'm most familiar with PCI, and some of the things that people put in it are just downright stupid. If you run your credit card processing on Solaris, why should you put in a virus scanner? Seriously, folks... Since compliance becomes an administrative tool, the weapons against actually paying for compliance become administrative, hence the focus on meeting checklist items. A checklist can't really contain all the capability of a general purpose computing system, as checklists do not have looping or decision making in them. So, they'll always have weird limits, and people will try to overcome those limitations by adding to the checklists. Compliance becomes a rallying point for the professional meeting attenders, parasites and hangers on, hierarchy jockeys. ___ 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. ___ 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. ___ -- mike 00110001 3 00110111 ___ 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
Maybe it depends on the vertical? What vertical(s) did you find it a distraction in? gem -Original Message- From: Michael Silk [mailto:[EMAIL PROTECTED] Sent: Mon Mar 12 17:34:56 2007 To: Gary McGraw Cc: SC-L@securecoding.org Subject:Re: [SC-L] Darkreading: compliance On 3/13/07, Gary McGraw [EMAIL PROTECTED] wrote: hi sc-l, this month's darkreading column is about compliance. my own belief is that compliance has really helped move software security forward. in particular, sox and pci have been a boon: http://www.darkreading.com/document.asp?doc_id=119163 what do you think? have compliance efforts you know about helped to forward software security? no. my feeling is that it focuses management on unimportant things like meeting checkpoints rather then actually doing useful things. gem 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. ___ -- mike 00110001 3 00110111 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. ___
Re: [SC-L] Darkreading: compliance
On 3/13/07, Gary McGraw [EMAIL PROTECTED] wrote: hi sc-l, this month's darkreading column is about compliance. my own belief is that compliance has really helped move software security forward. in particular, sox and pci have been a boon: http://www.darkreading.com/document.asp?doc_id=119163 what do you think? have compliance efforts you know about helped to forward software security? no. my feeling is that it focuses management on unimportant things like meeting checkpoints rather then actually doing useful things. gem 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. ___ -- mike 00110001 3 00110111 ___ 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. ___
