Re: [SC-L] informIT: Building versus Breaking
Hi Ivan (and Sergio), Maybe I should have clarified my position. I have no problem with security researchers and whitehats that investigate and reverse engineer malware to make the world a better place. I have problems with those that create malware - under the guise of security research - which then gets used by the bad guys. I'm not saying that one can never stop breaking into things. I just don't like the glorification of creating malware by the so-called good guys. If all of that energy instead was placed into prevention, then we would be better off. Let's say this... I have a badness-ometer scale. On the left side of the scale is ignorance and darkness. The bad guys are operating on their own wits. There are no security researchers that publish their results. On the right side, we have today's world of infosec, where everybody is crawling all over themselves to make a name for themselves and get recognized - by tooting their horn and to see how cool that they can be hacking into stuff. It is what it is and I'm not under any illusion; I'm just not gonna accept this glorification of bad guys pretending to be good. Stephen P.S. One might argue that a whitehat or security researcher can't change sides and go into prevention, or in other words, be a Builder instead of a Breaker. They can't because they don't have the skills to do it. Which is precisely my point. On Fri, Sep 2, 2011 at 11:05 AM, iarce ia...@corest.com wrote: On 9/1/11 2:29 AM, Stephen Craig Evans wrote: Sergio, Blackhat IS about breaking stuff, the vendors area offers defense products and services to improve your security. For building stuff (as in development) there are other conferences out there. People go to Blackhat to be aware of what things might go wrong in order to protect better themselves. I really take offense to your comment. I am seeing malware out in the field that is based on work by so-called noble security researchers. My litmus test is: If there were no whitehats and security researchers, would we be better off at fighting the bad guys? My answer is emphatically yes. That is the kind of reply and opinion that very rapidly leads these debates to very divisive arguments. First you are taking offense then your are pejoratively dismissing other peoples work (by generically putting the quality or motivation of their work in question) and finally saying that you'd be better off if a whole community of people did not exist. Replace security researchers with any other collective and your statement would read very very nasty What I hate is that security researchers and the white hats try to present themselves as noble and as the good guys. It's f*cking bullsh*t and a total scam. Ten years later for me and the state of infosec is much worse. Hmm I wonder if I should take offense of that statement? You question the motivations and honesty of an entire group of people and imply they're responsible for an alleged degradation in the state of infosec. There is also a nasty faction of infosec that will never want to solve problems which will put themselves out of work. Yep, I am throwing down that gauntlet FWIW. Stephen, it is way past the time - it was 10 years go too- for people in the infosec community that claim to have an interest in improving the state of infosec to move away from confrontational stances and bigotry and to engage with the offensive security community in a constructive manner, putting prejudices aside and without invoking a moral high ground that they've not been given by divine intervention. Personally, I would be glad to put you out of work. Unfortunately I can't do it alone. sincerely, -ivan -- Ivan Arce CTO - Core Security Technologies ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___ -- http://www.linkedin.com/in/stephencraigevans ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] informIT: Building versus Breaking
Sergio, Blackhat IS about breaking stuff, the vendors area offers defense products and services to improve your security. For building stuff (as in development) there are other conferences out there. People go to Blackhat to be aware of what things might go wrong in order to protect better themselves. I really take offense to your comment. I am seeing malware out in the field that is based on work by so-called noble security researchers. My litmus test is: If there were no whitehats and security researchers, would we be better off at fighting the bad guys? My answer is emphatically yes. I agree with Gary and from knowing Gary from all of his posts and podcasts, this is not a new stance from him. I am in complete agreement with him and always have been. And while I am here, the Builders vs. Breakers term should be attributed to Mark Curphey. You can probably still find his original post. The next question is: Can we ever prevent people from being security researchers or white hats or black hats or bad guys? No. But I think we have to start to take the lipstick off of the pigs and recognize what it is. It's called Blackhat, isn't it? Very unfortunately, there is more glamour - and probably more reward - in breaking stuff. What I hate is that security researchers and the white hats try to present themselves as noble and as the good guys. It's f*cking bullsh*t and a total scam. Ten years later for me and the state of infosec is much worse. There is also a nasty faction of infosec that will never want to solve problems which will put themselves out of work. Yep, I am throwing down that gauntlet FWIW. Stephen On Wed, Aug 31, 2011 at 1:01 PM, Sergio 'shadown' Alvarez shad...@gmail.com wrote: Hi gem, I've read your article to see what direction you were willing to take, before jumping into the conversation. Your post was exactly what I thought you were heading to. I disagree with your thought for many reasons. But first I would like to use proper terms so that we don't misuse some vocabulary: You said: Software security should be a balanced approach of offense and defense (white hat and black hat, if you will) Whitehat: reports what he/she has found. Network vulenerabilities, software security flaws, flawed crypto, design flaws, or whatever it is that the individual found it was broken or wrong. Blackhat: doesn't report what he/she found, because she/he want to keep it that way. Of course there are a lot of grays out there too. Defense is…well... defense. To design and build proper software and hardware there are a lot of conferences out there, as well as trainings and a huge amount of literature. There are very good books when it comes to secure software development. Every year what is presented, in the best security conferences, are new techniques that developers need to be aware of in order to build secure products. Most of the presentations talk about things that were wrongly designed and/or corner-cases which were not considered. There are also a lot of tools and libraries which help development teams to do things right, specially libraries and templates like Microsoft Safeint as well as the safe APIs, which prevent developers from shooting themselves. They just need to use them. There are also managed languages, APIs to handle SQL securely, etc. It is just that a lot of developers don't use what is available to them. Blackhat is great as it is now, there are talks about new defense technologies from time to time too. Having more talks about defense would be use, in my opinion, to sale products than anything else. I don't believe it would do any good to Blackhat. I am not opposed to breaking stuff (see Exploiting Software from 2004), but I am worried about an overemphasis on breaking stuff. Blackhat IS about breaking stuff, the vendors area offers defense products and services to improve your security. For building stuff (as in development) there are other conferences out there. People go to Blackhat to be aware of what things might go wrong in order to protect better themselves. And even then many good talks overlap unfortunately. Regards, Sergio On Aug 31, 2011, at 4:16 PM, Gary McGraw wrote: hi sc-l, I went to Blackhat for the first time ever this year (even though I am basically allergic to Las Vegas), and it got me started thinking about building things properly versus breaking things in our field. Blackhat was mostly about breaking stuff of course. I am not opposed to breaking stuff (see Exploiting Software from 2004), but I am worried about an overemphasis on breaking stuff. After a quick and dirty blog entry on the subject http://www.cigital.com/justiceleague/2011/08/09/building-versus-breaking-a-white-hat-goes-to-blackhat/, I sat down and wrote a better article about it: Software [In]security: Balancing All the Breaking with some Building
Re: [SC-L] OWASP Podcast #16
Hi Jim, I check the web site daily before you even announce the podcasts. Tremendous stuff as you don't lob softball questions plus you get quickly to the point. Thanks for your effort; I've learned a lot from them already. Keep up the great work, Stephen On Fri, Apr 10, 2009 at 1:16 AM, Jim Manico j...@manico.net wrote: Hello SC-l, OWASP Podcast #16, an interview with Dave Aitel, is now live. Dave == cool. I hope you enjoy. Direct Link: http://www.owasp.org/download/jmanico/owasp_podcast_16.mp3 RSS: http://www.owasp.org/download/jmanico/podcast.xml iTunes: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 Regards, - Jim Manico OWASP Podcast Host ___ 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. ___ -- http://www.linkedin.com/in/stephencraigevans ___ 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] SANS/CWE Top 25: The New Standard for Webappsec
Hi Arian, SANS has spoken and I think that is a pretty clear indication what is going on) Have you been watching Wizard of Oz re-reruns again? This sentence sounds too much like The Mighty Oz has spoken :-) Cheers, Stephen On Sat, Jan 17, 2009 at 11:39 AM, Arian J. Evans arian.ev...@anachronic.com wrote: Hello all. Xposting to SCL and WASC: Following-up to my commentary on the WASC list about the SANS/CWE Top 25 I have repeatedly confirmed that the SANS/CWE Top 25 is being actively used, and growing in use, as a Standard. I understand the spirit of intent and that the makers are not accountable for how it is used, but we need to be realistic about how it is being implemented in the real world *now*. It is beginning to be used as a standard for: * what security defects to test software for * how to measure the security quality of software * how to build secure software * what to teach developers about coding securely I have confirmed this with: * peers * corporations * state governments * software security solutions vendors * customers We are already seeing RFPs for products and services, management and auditor created internal standards, and requests for training and reporting using the SANS/ CWE Top 25 as a standard. There are three goals of this post: 1) to make very clear to all involved that what is being built with the Top 25 list is a minimum standard of due care. 2) To suggest that this is (most likely) how it is primarily going to be used. (You brought the SANS/CIS club to the dance here...) 3) Suggest that future versions be re-focused on building actual minimum standards of due care for the demonstrated needs. The great thing that is coming out of this Top 25 experiment is to identify that awareness and hunger-level for material like this is very high. This is also showing us what people really want right now: People want a minimum standard of due care. It is obvious people want bite-sized digestible snippets to use as guidelines for making and measuring the security quality of our software. That is evidenced by how rapidly people have latched onto this new list. (one week + !) The SANS and Mitre brand have huge stock in the mainstream, non-appsec security community, much larger than OWASP and WASC, as is evidenced again by the attention this is getting throughout the infosec and audit communities. And summing up, directly from Alan Paller: http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1344962,00.html Conclusions: We need a minimum standard of due care Top N list. We really need THREE minimum standards of due care: 1) Top N issues/defects to test your software for 2) Top N principles to build secure software 3) Top N strategies to improve software security in your enterprise Webappsec folks should make webappsec versions, or else we will all wind up using the same ones for *everything*. We might want to divide/share efforts between organizations and cross-reference each other for maximum (positive) effect. We could likely leverage each others' work and try to unify our language across appsec communities. (Ideologies and pet naming systems are where these efforts always break down in our group.) I am avoiding the debate over the inherent problems with Top N and bug parade approaches in general. People are letting us know what they want and I think we should solve that need. ...or they will take whatever we give them for other purposes and use it to solve that need, partially, improperly, ineffectively. I will quite my bitching about the Top 25 and focus on productively moving forward, now that it's clear my concerns are too late and it's already moving full-steam ahead as a standard. People do not know what to do. They have a serious problem that is starting to cause them to lose real sleep and real money, and they are looking to us for suggestions and guidance as to what to do. I concede that the Top 25 in this regard is better than nothing, but it's not really what people want or need right now (IMHO). (Note: I have not asked parties involved if I can quote them or quote facts of this being used as a standard. The volume of emails I am receiving providing examples of this make me think this is either a fad, or self-evident and you will all see plenty of examples of this very soon if you have not already. SANS has spoken and I think that is a pretty clear indication what is going on) $0.02 USD, -- -- Arian Evans Anti-Gun/UN people: you should weep for Mumbai. Your actions leave defenseless dead. Among the many misdeeds of the British rule in India, history will look upon the Act depriving a whole nation of arms, as the blackest. -- Mahatma Gandhi ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc -
Re: [SC-L] How Can You Tell It Is Written Securely?
Hi Mark, What I have seen is that the organization develops security standards/guidelines and secure coding guidelines tailored to the org. If the org is big enough to have its own security team, then they do it; if not, then they hire consultants to do it. It's not too difficult to find out amongst the consultants who has the experience and who doesn't. Those standards and guidelines are updated either every year or two, or before the next big project. External consultant(s) - not the internal security team within the organization (if it exists) - then does audits at milestones of the project implemented by the outsourcing organization and reports on the conformance to the guidelines and standards, and anything else that might have been left out (which then results in updated standards and guidelines). For non-conformant issues, the 3 groups get together and decide what to do about it. If a direct solution is not possible, often other security controls can be tweaked or enhanced to make that particular risk acceptable or eliminated. This type of system has clear separation of duties. Stephen On Thu, Nov 27, 2008 at 10:03 AM, Mark Rockman [EMAIL PROTECTED] wrote: OK. So you decide to outsource your programming assignment to Asia and demand that they deliver code that is so locked down that it cannot misbehave. How can you tell that what they deliver is truly locked down? Will you wait until it gets hacked? What simple yet thorough inspection process is there that'll do the job? Doesn't exist, does it? MARK ROCKMAN MDRSESCO LLC ___ 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] Silver Bullet and informIT: Jeremiah Grossman
Hi Gary, I think you were on the right path describing software security and illustrating the difference between software security and web app security (even though I don't think it was intentional) when you talked about Pervasive Computing in a BankInfoSecurity podcast (starting at 5 min 10 sec). It should have been obvious to me before, but from that I also picked up on the distinction between applications that need to connect vs. web apps that connect between the client and the application itself. For those interested, the podcast is here: http://www.bankinfosecurity.com/podcasts.php?podcastID=6 (registration required) Stephen On Sat, Nov 15, 2008 at 12:24 AM, Gary McGraw [EMAIL PROTECTED] wrote: hi sc-l, Episode 32 of the Silver Bullet Security Podcast went live last night. This episode features a chat with Web security guru Jeremiah Grossman. Among other things, we talk about the relationship between Web app security and software security: http://www.cigital.com/silverbullet/ Jeremiah and I cross paths out there on the evangelism circuit pretty often and it was nice to catch up with him. Near the end of our conversation, we raised the idea of whether all Web security problems have analogs in the software security space and what that might mean. After thinking more about that issue, I made it the subject of this month's informIT column: http://www.informit.com/articles/article.aspx?p=1309290 Please let me know what you think about the role that Web application security plays in software security today (and whether you think we focus the right amount of attention, too much, or too little). gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.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. ___ ___ 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] Introducing my OWASP Summer of Code project, Securing WebGoat using ModSecurity
Hi, I did an OWASP Summer of Code 2008 project, Securing WebGoat using ModSecurity (actually, it expanded into a Fall of Code project too :-) First, the project should have been named Protecting WebGoat using ModSecurity but by the time I figured it out, it was too late to change the title. The goal of the project was to fix as many of the WebGoat vulnerabilities as possible using ModSecurity without changing any of the source code, and I ended up either with solutions or suggestions of solutions - prevention or detection - for 46 of the possible 47 WebGoat sub-lessons. IMO, some interesting parts of it: - The combination of using Lua script on the WAF (back end) and Javascript injection (into the response body) on the front end allows for a complete programming environment (keep in mind that ModSecurity cannot alter the content of HTTP requests or responses, but can prepend and append Javascript to the response) - Using Lua and Javascript injection to mitigate business logic flaws - Using Javascript injection to mitigate 3rd-party attacker kinds of attacks, and enhance the end user experience when ModSecurity has to block a request or response - The documentation is sorta of a primer for ModSecurity (quite a bit of interest in this project has been from infosec people who want to learn more about ModSecurity and WAFs in general) - Included are insightful, invaluable reviewer comments from the project reviewers (Ivan Ristic, Ryan Barnett, and Christian Folini) that you won't find any place else I've put the finishing touches on the project wiki (as far as new content goes) so I thought I would introduce the project here. The project main page: https://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project The project wiki: https://www.owasp.org/index.php/OWASP_Securing_WebGoat_using_ModSecurity_Project Appendix D contains a Word file - 134 pages - of the wiki (as of Nov 25); it might be easier to refer to it rather than navigating around inside the wiki. Plus, I put up a ppt prezo from the recent OWASP EU Summit in Portugal, and all future fixes and enhancements to the current ModSecurity solution rulesets will be placed there also. I have been getting some private emails of people actually starting to use the project stuff, so it's time to redirect that to the mailing list. To subscribe: https://lists.owasp.org/mailman/listinfo/owasp-webgoat-using-modsecurity Archives: https://lists.owasp.org/pipermail/owasp-webgoat-using-modsecurity/ I call WAFs, code review, and penetration testing the 3 pillars of the application security portion of PCI-DSS, and I believe that adding a WAF to the toolbox - and being able to write custom rule sets - not only can benefit the client but also can be a career-enhancer (I've already used it on one project). Of course, the percentage of the project that is theoretical/research vs. the percentage that is practical and has real-world value is subject to debate. Anybody wanting to throw some flames are very welcome - I have some pretty thick skin (which started to thicken as a casualty of the classic OS/2-Windows flame wars of the early '90's). I touch on this in the project documentation so I only ask that one reads it first before flaming away :-) Thanks for your attention, Stephen Cheers, Stephen ___ 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] Unclassified NSA document on .NET 2.0 Framework Security
Whenever I speak with a customer or any software decision makers, I implore them, before buying another vendor's software, or hiring/contracting a 3rd party development firm, to ask a couple of simple questions: What do you do for software security?, and Can you send me some documents about your software security practices?. From my experience, that will stop at least 95% of them in their tracks. There are lots of country-specific 5 to 30 person software shops located in the major Asian business centers. But even if, say, IBM is the main contractor to a client of mine, those questions can still be asked of IBM, and it's their responsibility to get the answers from the small software shop (and my client will have the documentation as a trust but verify check for later use). Stephen On 11/27/08, Jerry Leichter [EMAIL PROTECTED] wrote: On Nov 26, 2008, at 3:05 AM, Stephen Craig Evans wrote: Hi Gunnar, I apologize to everybody if I have come across as being harsh. From my 8 years of experience of living in Asia and being actively involved as a developer and working with developers (at Microsoft as its first .NET Regional Developer Evangelist in 2001 to recently at Symantec as the first Secure Application Services consultant for APAC), IMO there's a big gap between the maturity of software security here vs. Europe vs. West Coast USA vs. East Coast USA. The culture is different and even in the situation that a software developer cared and wanted to implement software security, in many countries they could get in a lot of trouble for upstaging their boss and making him or her lose face. The responsibility of secure software is not at the developer level in most casesThis has really important implications, and is worthy of thought and discussion. On the one hand, *right now*, it justifies the complaints about outsourcing: That you really can't trust software produced in Asia. On the other hand, the (relative) command-and-control nature of development in Asia means that, should management there decide that security is an important issue - and since given the nature of their business, they are very sensitive to customer demand, that would mean that their customers tell them unambiguously that it's what they'll be judged on *and actually act that way* - Asian outsourcers are likely to be much more effective at getting their organizations to focus on secure practices than we are here in the more free-wheeling West. -- Jerry ___ 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] Regional differences in software security
I'll preface what I'm going to say with:
- I don't work in the financial vertical or government defense, but
from conversations with colleagues, I think that they get it (they
have to)
- My sphere of experience excludes Australia, India, and Japan:
- Oz has on average a high skill set of s/w engineers, so I don't
see why that would be different for s/w security.
- From discussions with friends/ex-employees who are from India,
because of such a high turnover in the s/w factories, a coder is given
a day's to a week's worth of code to produce at one time, so if they
leave then they can be replaced without much loss. This was a few
years ago and I don't know the level of s/w security introduced since
then, but for sure I highly doubt that developers have any say in what
they can write.
- Colleagues and friends who live in Japan say that the level of s/w
security is just as bad as the rest of Asia, which was surprising to
me. I think, though, that in Japan, there is a strong culture of not
upstaging the boss so maybe that explains it.
So, my sphere of experience extends from Beijing to Jakarta and all
points in between... (to paraphrase ZZ Top :-)
I would say the level is barely the beginning of the beginning.
There are no compliance laws except for PCI-DSS. There are no breach
disclosure laws.
There are often huge silos between the security guys and the
development team, both organizationally and politically. Quite a few
times I've seen the responsibility of software security dumped on the
network team with the orders of make everything secure. And often:
(a) the web site was outsourced years ago and the company is no longer
in business; (b) the 3rd party software vendor is not going to fix its
software or attempt to make it secure in the near future (and there's
nothing in the SLA that says they have to; (c) the development team
does exist but either change processes take 3 to 6 months to get
anything done, or (d) the network manager has to go to political war
to get something done.
From all of the above, a magic elixir for a network security team can
be a web application firewall. They can drop a box in and they don't
need anybody else's permission. This is what happened on a very recent
project (I was helping the client prepare for a PCI audit), and
because of my Summer of Code OWASP project, Securing WebGoat using
ModSecurity, I was able to help their team write custom ModSec
rulesets; and from that they learned something about security (of
course it should have been the s/w people who learned something about
it).
And, you don't know how many times I've been approached to do pentests
for large corporations' web sites that handle sensitive customer data
- and their budget is $6500 to $10,000 USD. Sorry, I'm greedy, but I
can't risk my reputation by doing a less than half-assed job.
On the bright side, I've had a couple of application pentest projects
- the head of the development team was responsible for it (maybe
that's the key) - and they went great. The developers architects
didn't know anything about software security, but each manager
assembled the entire dev team and network/sys admins for a half day
for me to present my findings and educate them on what they needed to
do; to explain the origin, the prevention/solution, etc. Those are
real fun and it's so cool seeing the looks on people's faces when it
clicks and they get it.
Stephen
On Wed, Nov 26, 2008 at 10:45 PM, Kenneth Van Wyk [EMAIL PROTECTED] wrote:
On Nov 26, 2008, at 9:19 AM, Gary McGraw wrote:
I think this idea of regional differences is worth exploring a bit. In my
work at cigital I have come to believe that there is a difference in
approach between the east coast of the US and the west coast.
I completely agree here. Stephen raises a fascinating point.
I don't know what I did {right|wrong}, but the vast majority of my clients
are in Europe or Southeast Asia right now. (I'm a dual EU/US citizen, which
perhaps helps.) Apart from all the air miles, I've seen vast differences
that seem--at least on the surface via casual observation--to have a
regional component. Contrasting US East, West, EU, and Asia, there are big
differences in such areas as:
- Software process. I see more process-heavy dev in US East and Europe,
with far less of it in US West and Asia, for instance.
- Security teams. I see a pretty solid line between IT security and
software dev teams in US East and Asia, with lines being more blurred in US
West and EU. This seems to be central to Stephen's point, if I understand
correctly. And it's a good point to consider.
- Security testing. ...
The list goes on. Unfortunately, all I have are casual observations, but
the climate differences seem palpable to me.
Cheers,
Ken
-
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information,
Re: [SC-L] How Can You Tell It Is Written Securely?
... and demand that they deliver code that is so locked down that it cannot misbehave. Your premise is so incorrect that I advise that if you are truly interested in answering your questions (as opposed to a purely academic or other exercise), then you should hire a security specialist to help you out, or use google search :-) Cheers, Stephen On Thu, Nov 27, 2008 at 10:03 AM, Mark Rockman [EMAIL PROTECTED] wrote: OK. So you decide to outsource your programming assignment to Asia and demand that they deliver code that is so locked down that it cannot misbehave. How can you tell that what they deliver is truly locked down? Will you wait until it gets hacked? What simple yet thorough inspection process is there that'll do the job? Doesn't exist, does it? MARK ROCKMAN MDRSESCO LLC ___ 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] Unclassified NSA document on .NET 2.0 Framework Security
Hi Gunnar, I apologize to everybody if I have come across as being harsh. From my 8 years of experience of living in Asia and being actively involved as a developer and working with developers (at Microsoft as its first .NET Regional Developer Evangelist in 2001 to recently at Symantec as the first Secure Application Services consultant for APAC), IMO there's a big gap between the maturity of software security here vs. Europe vs. West Coast USA vs. East Coast USA. The culture is different and even in the situation that a software developer cared and wanted to implement software security, in many countries they could get in a lot of trouble for upstaging their boss and making him or her lose face. The responsibility of secure software is not at the developer level in most cases, which is why I've spoken at regional IASA events (www.iasahome.org), with overwhelming positive responses, and will continue to try to reach the decision makers (as an OWASP representative) because trying to engage developers directly at this point in time at the maturity level of software security in APAC is not the most effective way to go about it. I'm sure, though, that at financial institutions they get it, but almost all of my clients are government and media/communications companies. Also, sorry to everybody for taking this thread off-topic. Stephen On Wed, Nov 26, 2008 at 2:24 AM, Gunnar Peterson [EMAIL PROTECTED] wrote: stephen i spend at least half my time working directly with developers. for some reason i have not communicated as well as i should to you, what i am saying is that the job is too hard for developers *because* the security industry has let them down by sending them on a fool's errand of least privilege. the problem or target in your words IS with security people NOT developers. they have other problems just not an endless quixotic quest for least privilege. i am not repeat not throwing developers under the bus in this argument. i am ready, willing and possibly able to be proven wrong on this point and maybe there is a cost effective way to deploy least privilege in the real world just want to make sure that i communicate my argument. -gunnar (who is now letting go) On Nov 25, 2008, at 12:07 PM, Stephen Craig Evans wrote: I can't let this go. Gary, you are self-professed working with financial institutions and high-end customers. Gunnar, you are the same, at least what I gather from your Silver Bullet podcast when talking about the difference between SOA (top down) and Web 2.0 (bottom up). No flame war intended, but a healthy discussion should be in order. So please don't talk about developers as targets. They/we are the lowest on the totem pole. Direct your arrows at the people that you deal with. Plain and simple. Cheers, Stephen On Wed, Nov 26, 2008 at 1:48 AM, Gunnar Peterson [EMAIL PROTECTED] wrote: look, i am a consultant. i work in lots of different companies. lots of different projects. i don't see these distinctions in black and white. sometimes the cto and managers are best positioned to help companies develop more secure software, sometimes architects, sometimes auditors, and many many times in my experience developers are best positioned. but i really, truly do not care who does it. my only goal is more effective security mechanisms and some pragmatic roadmap to get there. we are in the infancy of this industry (think automotive safety circa 1942, all seat belts and brakes), we are in no position to turn away help from anyone who can help. every company and every project is different, if your organization is set up so that developers are not empowered, but managers and CTOs are then by all means work with them. but actually the main point of my post and the one i would like to hear people's thoughts on - is to say that attempting to apply principle of least privilege in the real world often leads to drilling dry wells. i am not blaming any group in particular i am saying i think it is in the too hard pile for now and we as software security people should not be advocating for it until or unless we can find cost effective ways to implement it. -gunnar On Nov 25, 2008, at 11:28 AM, Stephen Craig Evans wrote: It's a real cop-out for you guys, as titans in the industry, to go after developers. I'm disappointed in both of you. And Gary, you said One of the main challenges is that developers have a hard time thinking about the principle of least privilege . Developers are NEVER asked to think about the principle of least privilege. Or your world of software security must be very very very different from mine (and I think my world at least equals yours but by about 2 billion people more, which might be irrelevant now but a little more relevant in the future :-) With the greatest, deepest respect to both of you, Stephen On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans [EMAIL PROTECTED] wrote
Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security
HI, maybe the problem with least privilege is that it requires that developers:... IMHO, your US/UK ivory towers don't exist in other parts of the world. Developers have no say in what they do. Nor, do they care about software security and why should they care? So, at least, change your nomenclature and not say developers. It offends me because you are putting the onus of knowing about software security on the wrong people. Cheers, Stephen On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson [EMAIL PROTECTED] wrote: maybe the problem with least privilege is that it requires that developers: 1. define the entire universe of subjects and objects 2. define all possible access rights 3. define all possible relationships 4. apply all settings 5. figure out how to keep 1-4 in synch all the time do all of this before you start writing code and oh and there are basically no tools that smooth the adoption of the above. i don't think us software security people are helping anybody out in 2008 by doing ritual incantations of a paper from the mid 70s that may or may not apply to modern computing and anyhow is riddled with ideas that have never been implemented in any large scale systems compare these two statements Statement 1. Saltzer and Schroeder: f) Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized. Put another way, if a mechanism can provide firewalls, the principle of least privilege provides a rationale for where to install the firewalls. The military security rule of need-to-know is an example of this principle. Statement 2. David Gelernter's Manifesto: 28. Metaphors have a profound effect on computing: the file-cabinet metaphor traps us in a passive instead of active view of information management that is fundamentally wrong for computers. 29. The rigid file and directory system you are stuck with on your Mac or PC was designed by programmers for programmers — and is still a good system for programmers. It is no good for non-programmers. It never was, and was never intended to be. 30. If you have three pet dogs, give them names. If you have 10,000 head of cattle, don't bother. Nowadays the idea of giving a name to every file on your computer is ridiculous. Conclusion(gp): Least Privilege is the point where the practical matter of applying Saltzer and Schroeder's principles breaks down in modern systems. Its a deployment issue, and a matter of insufficient models and modes. http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html Remember the 1990s when there were all these search engines that required you tag up all the content and put it in hierarchical directories and so on? Well what happened? Google came along and ate their lunch. When the problem is information overload, telling everyone to go out and label everything is not gonna work. -gunnar On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: Sadly this non-adoption of privileged/managed code (filled with blank stares) has been the case ever since the Java security days a decade ago. One of the main challenges is that developers have a hard time thinking about the principle of least privilege and its implications regarding the capabilities they should request. Dinis is brave to set such thinking as a target. I've settled (after ten years) with getting developers just to utter the word security. All together now...security. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 11/24/08 12:31 PM, Mike Lyman [EMAIL PROTECTED] wrote: Dinis Cruz wrote: Don't get me wrong, this is a great document if one is interested in writing applications that use CAS (Code Access Security), I would love for this to be widely used. When we recommended recommending CAS during a review of the U.S. Defense Information System Agency's new Application Security and Development Security Technical Implementation Guide earlier this year we were met with what amounted to blank stares. (At least it seemed like that since it was a phone conference.) Some on the call understood it and agreed with the recommendation but those hosting the call and doing the writing didn't seem to grasp it. It may be a while before we see too many adopting this or requiring it for a while. -- Mike Lyman [EMAIL PROTECTED] ___ Secure Coding mailing list (SC-L)
Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security
Gunnar, Developers have no power. You should be talking to the decision makers. As an example, to instill the importance of software security, I talk to decision makers: project managers, architects, CTOs (admittedly, this is a blurred line - lots of folks call themselves architects). If I go to talk about software security to developers, I know from experience that I am probably wasting my time. Even if they do care, they have no effect overall. Your target and blame is wrong; that's all that I am saying. Stephen On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson [EMAIL PROTECTED] wrote: Sorry I didn't realize developers is an offensive ivory tower in other parts of the world, in my world its a compliment. -gunnar On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: HI, maybe the problem with least privilege is that it requires that developers:... IMHO, your US/UK ivory towers don't exist in other parts of the world. Developers have no say in what they do. Nor, do they care about software security and why should they care? So, at least, change your nomenclature and not say developers. It offends me because you are putting the onus of knowing about software security on the wrong people. Cheers, Stephen On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson [EMAIL PROTECTED] wrote: maybe the problem with least privilege is that it requires that developers: 1. define the entire universe of subjects and objects 2. define all possible access rights 3. define all possible relationships 4. apply all settings 5. figure out how to keep 1-4 in synch all the time do all of this before you start writing code and oh and there are basically no tools that smooth the adoption of the above. i don't think us software security people are helping anybody out in 2008 by doing ritual incantations of a paper from the mid 70s that may or may not apply to modern computing and anyhow is riddled with ideas that have never been implemented in any large scale systems compare these two statements Statement 1. Saltzer and Schroeder: f) Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized. Put another way, if a mechanism can provide firewalls, the principle of least privilege provides a rationale for where to install the firewalls. The military security rule of need-to-know is an example of this principle. Statement 2. David Gelernter's Manifesto: 28. Metaphors have a profound effect on computing: the file-cabinet metaphor traps us in a passive instead of active view of information management that is fundamentally wrong for computers. 29. The rigid file and directory system you are stuck with on your Mac or PC was designed by programmers for programmers — and is still a good system for programmers. It is no good for non-programmers. It never was, and was never intended to be. 30. If you have three pet dogs, give them names. If you have 10,000 head of cattle, don't bother. Nowadays the idea of giving a name to every file on your computer is ridiculous. Conclusion(gp): Least Privilege is the point where the practical matter of applying Saltzer and Schroeder's principles breaks down in modern systems. Its a deployment issue, and a matter of insufficient models and modes. http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html Remember the 1990s when there were all these search engines that required you tag up all the content and put it in hierarchical directories and so on? Well what happened? Google came along and ate their lunch. When the problem is information overload, telling everyone to go out and label everything is not gonna work. -gunnar On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: Sadly this non-adoption of privileged/managed code (filled with blank stares) has been the case ever since the Java security days a decade ago. One of the main challenges is that developers have a hard time thinking about the principle of least privilege and its implications regarding the capabilities they should request. Dinis is brave to set such thinking as a target. I've settled (after ten years) with getting developers just to utter the word security. All together now...security. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 11/24/08 12:31 PM, Mike Lyman [EMAIL PROTECTED] wrote: Dinis Cruz wrote: Don't get me wrong, this is a great document
Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security
It's a real cop-out for you guys, as titans in the industry, to go after developers. I'm disappointed in both of you. And Gary, you said One of the main challenges is that developers have a hard time thinking about the principle of least privilege . Developers are NEVER asked to think about the principle of least privilege. Or your world of software security must be very very very different from mine (and I think my world at least equals yours but by about 2 billion people more, which might be irrelevant now but a little more relevant in the future :-) With the greatest, deepest respect to both of you, Stephen On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans [EMAIL PROTECTED] wrote: Gunnar, Developers have no power. You should be talking to the decision makers. As an example, to instill the importance of software security, I talk to decision makers: project managers, architects, CTOs (admittedly, this is a blurred line - lots of folks call themselves architects). If I go to talk about software security to developers, I know from experience that I am probably wasting my time. Even if they do care, they have no effect overall. Your target and blame is wrong; that's all that I am saying. Stephen On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson [EMAIL PROTECTED] wrote: Sorry I didn't realize developers is an offensive ivory tower in other parts of the world, in my world its a compliment. -gunnar On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote: HI, maybe the problem with least privilege is that it requires that developers:... IMHO, your US/UK ivory towers don't exist in other parts of the world. Developers have no say in what they do. Nor, do they care about software security and why should they care? So, at least, change your nomenclature and not say developers. It offends me because you are putting the onus of knowing about software security on the wrong people. Cheers, Stephen On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson [EMAIL PROTECTED] wrote: maybe the problem with least privilege is that it requires that developers: 1. define the entire universe of subjects and objects 2. define all possible access rights 3. define all possible relationships 4. apply all settings 5. figure out how to keep 1-4 in synch all the time do all of this before you start writing code and oh and there are basically no tools that smooth the adoption of the above. i don't think us software security people are helping anybody out in 2008 by doing ritual incantations of a paper from the mid 70s that may or may not apply to modern computing and anyhow is riddled with ideas that have never been implemented in any large scale systems compare these two statements Statement 1. Saltzer and Schroeder: f) Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized. Put another way, if a mechanism can provide firewalls, the principle of least privilege provides a rationale for where to install the firewalls. The military security rule of need-to-know is an example of this principle. Statement 2. David Gelernter's Manifesto: 28. Metaphors have a profound effect on computing: the file-cabinet metaphor traps us in a passive instead of active view of information management that is fundamentally wrong for computers. 29. The rigid file and directory system you are stuck with on your Mac or PC was designed by programmers for programmers — and is still a good system for programmers. It is no good for non-programmers. It never was, and was never intended to be. 30. If you have three pet dogs, give them names. If you have 10,000 head of cattle, don't bother. Nowadays the idea of giving a name to every file on your computer is ridiculous. Conclusion(gp): Least Privilege is the point where the practical matter of applying Saltzer and Schroeder's principles breaks down in modern systems. Its a deployment issue, and a matter of insufficient models and modes. http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html Remember the 1990s when there were all these search engines that required you tag up all the content and put it in hierarchical directories and so on? Well what happened? Google came along and ate their lunch. When the problem is information overload, telling everyone to go out and label everything is not gonna work. -gunnar On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote: Sadly this non-adoption of privileged/managed
Re: [SC-L] InternetNews Realtime IT News - Merchants Cope With PCI Compliance
Hi Michael, So, unfortunately for the WAF vendors, people can just use a static source code analysis tool or a web application vulnerability scanner instead of purchasing and deploying a WAF. I don't know much about PCI 6.6 (yet), but don't the organizations have to mitigate the vulnerabilities found? (fix, bear or transfer risk, use a different security control..) Surely one just doesn't have to just run the tool... I am guessing that WAFs can mitigate a considerable amount of these vulnerabilities. Automated tools suck at finding business logic flaws which just so happens to be a WAF's supposed weakness, too. So to me it seems to be a perfect marriage: automated tools that can only find bugs and WAFs that can only fix bugs :-) Stephen On Tue, Jul 1, 2008 at 5:40 AM, Michael Gavin [EMAIL PROTECTED] wrote: I too was wondering how much of a boon 6.6 would be to the WAF vendors and/or the companies that do security code reviews. That is, until 4/22, when the PCI SSC issued a press release (https://www.pcisecuritystandards.org/pdfs/04-22-08.pdf) announcing an information supplement clarifying requirement 6.6 (https://www.pcisecuritystandards.org/pdfs/infosupp_6_6_applicationfirewalls_codereviews.pdf). Clearly, completing security code reviews on all of those web applications and/or protecting them with those expensive magic pizza boxes, which, last time that I checked (almost 2 years ago now) were running about $35K to start, wasn't going to happen any time soon. The good news from that information supplement is that the PCI Security Standards Council defined what they mean by an application firewall and specified what it is supposed to do; the less good news is that they specified 4 alternative methods for satisfying the code review option: 1. manual security code review, 2. automated security code review, 3. manual web application vulnerability scan, and 4. automated web application vulnerability scan. While I think automation of code reviews and vulnerability scans is essential, I also believe that none of the automated tools are yet sufficient (completeness-wise) without some additional manual effort. So, unfortunately for the WAF vendors, people can just use a static source code analysis tool or a web application vulnerability scanner instead of purchasing and deploying a WAF. Michael Date: Mon, 30 Jun 2008 09:17:34 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: SC-L@securecoding.org Subject: Re: [SC-L] InternetNews Realtime IT News - Merchants Cope With PCI Compliance for the vast majority of the profession - slamming the magic pizza box in a rack is more preferable than talking to developers. in many cases the biggest barrier to getting better security in companies is the so-called information security group. it has very little to do with technology, its a people problem. -gp Kenneth Van Wyk wrote: Happy PCI-DSS 6.6 day, everyone. (Wow, that's a sentence you don't hear often.) http://www.internetnews.com/ec-news/article.php/3755916 In talking with my customers over the past several months, I always find it interesting that the vast majority would sooner have root canal than submit their source code to anyone for external review. I'm betting PCI 6.6 has been a boon for the web application firewall (WAF) world. Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.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. ___ ___ 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. ___ The i'm Talkathon starts 6/24/08. For now, give amongst yourselves. Learn More ___ 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.
