Re: [SC-L] Silver Bullet 111: Marcus Ranum
Ah, I see...so the dirty trick is that you are finally doing reruns. Syndication can't be far behind. ;-) -kevin Sent from my Droid; please excuse typos. On Jul 7, 2015 12:07 PM, Gary McGraw g...@cigital.com wrote: hi sc-l, Silver Bullet episode 111 is a sneaky one based around a “dirty brilliant trick. The episode features Marcus Ranum, inventor of the proxy firewall and all around security guru. We talk about perimeter security, software security, security progress (or lack of such) and whether hackers are necessary for security. http://bit.ly/sb111-mjr (or for purists http://www.cigital.com/silver-bullet/show-111/) So what was the trick? At the end of the episode I revealed that during episode 3 (recorded exactly 9 years before episode 111), I asked Marcus exactly the same set of questions. Wonder how consistent Marcus is over nine years? Compare and contrast http://www.cigital.com/silver-bullet/show-003/ gem ___ 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 ___ ___ 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: BSIMM versus SAFECode
On Thu, Dec 29, 2011 at 10:32 AM, Gary McGraw g...@cigital.com wrote: hi sc-l, How about a little software security controversy for the tweener holiday week? On the last day of the BSIMM Conference in November, SAFECode unveiled a paper about the SAFECode Practices and their relationship to the BSIMM. Sammy and I don't think the SAFECode guys got everything right in their work. In fact, they misconstrue the BSIMM as a software security methodology (which it is not) focused on compliance (which it definitely is not), so we wrote an article in response: BSIMM versis SAFECode and Other Kaiju Cinema http://www.informit.com/articles/article.aspx?p=1824250 (12/26/11) Gary, Hope you and other SC-L readers had a safe and happy holidays. I had a few comments on your InformIT article referenced here. First, you take exception of SAFECode of calling out BSIMM as a methodology. After quickly skimming their paper which you referenced, I think that perhaps you and Sammy are overreacting a bit. (Maybe you are misconstruing their misconstruing? ;-) Specifically, the SAFECode _Fundamental Practices_ paper which you cite states in their section Prescriptive vs. Descriptive Models of Security: Both the SAFECode _Fundamental Practices_ paper and the BSIMM focus on secure development *methodologies*; however the are important differences in their respective approaches and conclusions. [Emphasis mine.] I do not see anywhere else that they claim that BSIMM is a methodology, so my conclusion would be to simply chalk this up to sloppy writing at that point rather than drawing a conclusion from this single statement that SAFECode fails to understand that BSIMM is not a methodology. Besides, if you make the assumption that SAFECode did draw this conclusion that BSIMM is a type of software security methodology, do you really have anyone other than the BSIMM trainers / interviewers / staff to blame? Why? Well, as I read your InformIT article, you seem to imply that 6 of the 8 SAFECode members have participated in BSIMM. So, if that is true and they didn't grasp this fundamental truth, then my conclusion would be that your BSIMM training was an epic fail. However, I do think that SAFECode understood this. I didn't see anywhere else in their article that you cited where the decreed that BSIMM was some sort of methodology. However, if there are other paragraphs in their paper that you could cite that would support your point that they are miscontruing BSIMM as a methodology, I shall stand corrected. (Like I said, I only skimmed their paper rather quickly.) Secondly, in your InformIT article, you and Sammy wrote: The SAFECode paper implies that some activities identified in the BSIMM may be irrelevant to software security. Our working assumption is that if professional leaders and members of multiple software security groups are carrying out an activity, there is some logical reason for them to do so. Let me say that I think that you are being kind with your working assumption by concluding that there is some *logical* reason to *all* the activities that BSIMM has observed. That is, unless you consider CYA and office politics to be logical reasons. (I guess they could be, depending on your perspective.) Similarly, I would say that a lot of security activities that I have observed are, IMO, based on security myths, overreaction, or simple misunderstanding of security principles and risk models. This too is a matter of perspective as to whether this follows from some logical reasoning, but certainly while all of it may follow some logic, I would contend that not all of it is rationale. (Unless you consider reasoning based on fallacies to be rationale.) Of course, this is all just my opinion from where I sit. I am certainly not speaking from the perspective of my employer. And I'm not just writing that as part of some official company disclaimer. FWIW, many of my colleagues disagree with me. But OTOH, I do know that I am not alone in the security community with my opinions. Best regards, -kevin -- Blog: http://off-the-wall-security.blogspot.com/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents. -- Nathaniel Borenstein ___ 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] BSIMM3 lives
On Tue, Oct 18, 2011 at 10:34 AM, Gary McGraw g...@cigital.com wrote: On 10/15/11 5:45 PM, Steven M. Christey co...@rcf-smtp.mitre.org wrote: 3) The wording about OWASP ESAPI in SFD2.1 is unclear: Generic open source software security architectures including OWASP ESAPI should not be considered secure out of the box. Does Struts, mentioned earlier in the paragraph, also fall under the category of not secure out of the box? Are you saying that developers must be careful in adopting security middleware? Of course struts is not secure out of the box, which is the whole point of the activity. The major difference between struts as insecure and ESAPI as insecure is that ESAPI claims to be a secure solution, though it is often not. One might argue that it is worse to claim to be secure and not to be than to ignore the whole thing, but that's not really worth pursuing. For more regarding Cigital's view on ESAPI, see http://www.cigital.com/justiceleague/2011/09/24/suggestions-for-esapi-2-1-a nd-beyond/ Gary, While I wholeheartedly agree with John Steven's championing that ESAPI be made enterprise ready, I think your characterization of John's blog entry of having anything to do with ESAPI not being secure out of the box is simply unfair. I did not see that listed as one of John's concerns about ESAPI. The closest way that one could make that association is that for most of ESAPI's security components there are no high level user stories / use cases to provide overall guidance on each component. And while that conceivably could cause security issues, I don't really see inadequate documentation as being the same thing as a being insecure by default. While I think one could make the argument that ESAPI 1.4 was insecure by default (at least in the case of its symmetric encryption), I think that is an unfair assessment of the ESAPI 2.0 GA release. In fact, in some cases, we deliberately sacrificed backward compatibility (one of John's enterprise readiness criterion) with the 1.4 release compatibility because the development team's preference to choose security over backward compatibility. (Which is something that I believe is the right decision for security APIs.) This is not to say that the security in ESAPI 2.0 is perfect. In fact, the configuration issus is one of my nits to pick with ESAPI. Not only is it overly complex, but it does not allow an enterprise's operations team to lock down ESAPI properties in accordance with company security policies. But IMNSHO, I think that it does a far better job being secure-by-default than does Struts, which is the other API that you explicitly mention. Best regards, -kevin -- Blog: http://off-the-wall-security.blogspot.com/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents. -- Nathaniel Borenstein ___ 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
On Fri, Sep 2, 2011 at 6:19 PM, Chris Schmidt chrisisb...@gmail.com wrote: On Sep 2, 2011, at 10:44 AM, Goertzel, Karen [USA] goertzel_ka...@bah.com wrote: What we need is to start building software that can fight back. Then we could become part of cyber warfare which is much sexier than software assurance. :) Simple. Owasp esapi + owasp appsensor + honeypot = win I'd still consider that defensive. If you want cyber warfare and are willing to go over to the dark side, you can define your own custom AppSensor response actionsto act offensively. For instance, you could easily try to download malware to the attacker or mount a DoS attack against them. Personally, I don't recommend such escalation though, even if it is a tit-for-tat strategy. Reacting in that manner is likely to make you a criminal as well. -kevin -- Blog: http://off-the-wall-security.blogspot.com/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents. -- Nathaniel Borenstein ___ 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: Modern Malware
On 03/26/2011 01:12 PM, Gunnar Peterson wrote: Advanced = goes through firewall Persistent = tried more than once Threat = people trying to get into valuable stuff Nothing new to sc-l readers, but a Reasonably good marketing term esp by infosec standards (yay we get to scare business people with something other than an auditor's clipboard!); really its all just the collective sound of infrastructure security people coming to grips with the fact that their firewall isn't a wall at all, but rather a series of holes. Uh..., doesn't *most* of malware go through firewalls now days? So how is that advanced? In reality, advanced a used with APT means that malware that was clever enough to evade our normal AV defenses and socially engineer its way past the common sense of those humans who wanted to see the dancing pigs. In short, APT is spin-doctoring for getting caught with ones pants down. -kevin -- Kevin W. Wall The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.-- Nathaniel Borenstein, co-creator of MIME ___ 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] Java DOS
the fpupdater tool. Not all the startup scripts that would need modified are identical so a script to modify the scripts might be difficult. Fortunately, with the fpupdater tool this tact shouldn't be necessary. I have to go through a large amount of security issues every day, trying to decide which ones were relevant in which are irrelevant. Exactly what I am trying to do. This issue is definitely relevant, based on our code, but I'm not going to perform a JVMectomy this close to release; and unfortunately, it's always close to release; just to address the issue. So what will I do? I'll probably replace the parsing code; using a drop-in class replacement. This seems like the most appropriate fix for this issue until the JVM catches up. If you have not already looked at it, check out Oracle's fpupdater tool. http://www.oracle.com/technetwork/java/javase/fpupdater-tool-readme-305936.html And I'll probably have a good night's sleep tonight. What I won't do is ignore it, That was not the point of my message, The ramifications of a successful exploit make it too serious to ignore. You do so at your own peril. But as you point out, over reacting is also not the way to go. I don't ignore things; I deal with them, quickly, and without fuss Generally I find how quickly that these things can be dealt with is a function of size and bureaucracy. And then I get on to important things, like writing software ;) :) -kevin -- Kevin W. Wall The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.-- Nathaniel Borenstein, co-creator of MIME ___ 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] Java DOS
On 02/15/2011 11:38 AM, Jim Manico wrote:
[snip[
Ryan Barnett just spit out a new (impressive) mod security rule so you
can tactically patch without touching code (see below).
[snip]
First step is to inspect the ARGS and REQUEST_HEADERS data using a regex
to match on potential floating point payloads -
SecRule ARGS|REQUEST_HEADERS [0-9\.]{12,}e-[0-9]{3,}
phase:2,t:none,t:lowercase,nolog,pass,exec:/usr/local/apache/conf/modsec_c
urrent/base_rules/FloatingPointDoSAttack.lua
If a payload is found that matches the regex check, ModSecurity will
execute an external Lua script. The lua script then extracts out
payloads, strips out the . and then searches for the MagicDoSNumber. If
this is found, then a TX variable is exported -
Great idea, but the regex still needs work. For instance, one needn't
even use scientific notation at all, unless there is some other
mod_security rule restricting the overall length of an HTTP request
header. E.g.,
Accept-Language: en-us; q=0.0...00022250738585072012
where I've omitted the appropriate # of zeros for the sake of readability.
Similarly, one could also write the quality metric using 'e-90' or
'e-3' or whatever; even 'e+2' if I wanted. But the approach is correct;
only the regex needs work unless there's some other mod_security rule
that would catch these things.
-kevin
--
Kevin W. Wall
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents.-- Nathaniel Borenstein, co-creator of MIME
___
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] Java: the next platform-independent target
On 10/25/2010 04:26 AM, Martin Gilje Jaatun wrote: On 2010-10-22 04:51, Kevin W. Wall wrote: In a large part, I think that people fail to patch Flash or Acrobat Reader for the same reason they forget about Java...out of sight, out of mind.* I think they believe that Windows Update solves (or should solve) *all* their patching needs. I think many of the Linux distros have it right in that respect...one-stop patching pretty much for whatever you have installed from your Linux provider's distribution channel. There are third-party vendors who do offer this as a service to Windows users - I know about the Danish company Secunia and their Corporate Software Inspector (CSI) service; there may be others out there. That's true, I think BigFix is another (no endorsement intended), but 1) these services are not obvious / trivial to locate and evaluate for reliability, and 2) more importantly, why should a general user have to trust yet another party? Look how many folks get mislead into downloading fake AV software to protect their supposedly infected PC. If they are not discerning enough to know that, would they be any better with judging the reputation of these other companies that might offer total patching as a service similar to Secunia's service? I personally think that's doubtful. -kevin -- Kevin W. Wall The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.-- Nathaniel Borenstein, co-creator of MIME ___ 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] What do you like better Web penetration testing or static code analysis?
Brian Chess wrote: I like your point Matt. Everybody who's responded thus-far has wanted to turn this into a discussion about what's most effective or what has the most benefit, sort of like we were comparing which icky medicine to take or which overcooked vegetable to eat. Maybe they don't get any pleasure from the work itself. I take exception to that use of everybody. My response was based solely on my *preference*, which is what my understanding of Matt was originally asking. But SC-L being the mailing list of many tangents, well... And again, for the record, I *enjoy* both pen testing and static code analysis, but I _personally_ prefer doing static code analysis, if no other reason that generally allows me to work closer to the development teams where I can better suggest appropriate mitigation. Of course, my post (at least the original one) wasn't controversial enough to stir up the pot and cause it to go off in some other direction, so it may have flew past you under the radar. Not that that matters. OTOH, I don't want to be lumped into the everybody category especially when that list includes those who can't follow simple directions. ;-) Regards, -kevin -- Kevin W. Wall The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.-- Nathaniel Borenstein, co-creator of MIME ___ 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] What do you like better Web penetration testing or static code analysis?
Matt Parsons wrote: What do you like doing better as application security professionals, web penetration testing or static code analysis? McGovern, James F. (P+C Technology) wrote: Should a security professional have a preference when both have different value propositions? While there is overlap, a static analysis tool can find things that pen testing tools cannot. Likewise, a pen test can report on secure applications deployed insecurely which is not visible to static analysis. So, the best answer is I prefer both... While I realize that both are necessary and each have their own pros and cons, my personal preference is to do static code analysis, especially if it involves old-fashioned manual code inspections. The reason for that I like getting closer to the source code. Maybe that's just because it seems like I'm getting back to my development roots. (I worked as a developer for the first half of my career.) I find the advantages of dealing with source code is that you are able to spot the exact problem as well as offer more specific fixes. And working at the source code level gives me more opportunities to work closely with the development teams where I am able to explain to them in terms of their own code what is going on and how a vulnerability can be fixed. When approaching vulnerabilities from a pen testing level, I find all to often that the developers do not believe that there is anything wrong or if they do, they don't believe that it is serious enough that it needs to be fixed. (For instance, it is not uncommon that when developers are presented with results from a pen test that show that they have non-persistent (reflective) XSS vulnerabilities present, that I get the response Yeah, but that's not going to happen. First you would have to get a authenticated user to click on that link and they would never do that. Apparently they don't believe that those doing phishing ever catch any victims.) However, when I'm dealing with source code, that objection generally does not come up...perhaps because I can show them right then and there how to remediate the issue. -kevin -- Kevin W. Wall The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.-- Nathaniel Borenstein, co-creator of MIME ___ 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] [Esapi-user] Recommending ESAPI?
Dinis Cruz wrote: Following the recent thread on Java 6 security and ESAPI, I just would like to ask the following clarifications: Dinis... all really good questions. I'll comment on the ones I have some some sense of and feel qualified to answer and punt on the others. (I'm also going to delete those I'm not going to attempt to answer to shorten the response.) 1) For an existing web application currently using a MVC framework (like Spring or Struts) are we today (9th Jan 2009) officially recommending that this web application development team adds OWASP's ESAPI.jar to the list of 'external' APIs (i.e. libs) they use, support and maintain? I'm not aware of an *official* recommendation OWASP intends to make, but if they do, I doubt it will be until sometime after ESAPI 2.0 is officially released. 2) When adopting the OWASP ESAPI's J2EE implementation, is ESAPI.jar ALL they need to add? or are there other dependencies (i.e. jars) that also need to be added, supported and maintained? (for example on the '*Dependencies' section of the ESAPI Java EEhttp://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE page (i.e. Tab) it seems to imply that there are other *.jars needed)* To a large degree, what jars are needed depends on what ESAPI security controls are used by your application. (That what the Dependencies section on the URL you referenced tries to clarify.) Almost all the security controls use ESAPI logging which can be configured to use either the Log4j or (Sun) Java logging. Log4j is the default, so if that is used obviously a log4j jar is required. All of the dependency jars are bundled with the ESAPI zip file, but which ones you will actually needs depends on what ESAPI security controls are needed. * 3) Where can I find detailed information about each of the 9 Security Controls that ESAPI.jar currently supports: 1) Authentication, 2) Access control, 3) Input validation, 4) Output encoding/escaping, 5) Cryptography, 6) Error handling and logging, 7) Communication security, 8) HTTP security and 9) Security configuration? (I took this list of controls from the Introduction to ESAPI pdf) http://www.owasp.org/images/8/81/Esapi-datasheet.pdf Most of the detailed information--at least to the degree that we would like it--is not yet completed. (I'm not even sure all the docs that are planned have people to work on them yet. Some are awaiting developers to finish up their stuff to pitch in and contribute. Mike Boberski is in charge of the ESAPI documentation. He can fill you in on its status.) *4) ...snip... No comment. *5) Should we recommend the adoption of ALL 9 Security Controls? or are there some controls that are not ready today (9 Jan 2009) for production environments and should not be recommended? (for example is the 'Authentication' control as mature as the 'Error handling and logging' control?)* My only comment on that is to *NOT* use the symmetric encryption in ESAPI 1.4. It has lots of problems. One would be better off using encryption in the 2.0 release candidates (but even that is is a minor state of flux). *6) ...snip... No comment. 7) What is the version of ESAPI.jar that we should recommend? the version 1.4 (which looks like a stable release) or the version 2.0 rc4 (which looks like it is a Release Candidate) Version 2.0 has some new features (e.g., WAF) that were not available in 1.4. It also attempts to address some things that were broken in 2.0 (e.g., see response to #4). Ultimately this is probably one of those it depends answers. I'll let Jim or Jeff provide a more official answer. 8) - 12) ...snip... No comment. *13) What about the current implementations of ESAPI for the other languages. Are we also recommending their use?* IMO, doubtful. Most of the other languages are far behind the Java implementation. *14) If a development team decides to use (for example) Spring and ESAPI together in their (new or existing) application, what are the recommended 'parts' from each of those APIs (Spring and EASPI) that the developers should be using? (for example: a) use Encoding from ESAPI, b) use Authentication from Spring, c) use Authorization from ESAPI, d) use Error Handling from Spring, e) use Logging from ESAPI, etc...)* IMO, I think the ideal situation would be if we could get the Spring and Struts, etc. development communities to integrate their frameworks so that they could be used with the ESAPI interfaces. (In many of these cases, these implementations would replace the ESAPI reference implementation.) However, that is obviously going to take some time. I don't think that the ESAPI dev team can do it all. [Note: I am replying to both mailing lists. There may be policies against this. If so, my apologies. However just wanted to make people aware of this; if they Reply-All, they will need to be subscribed to both mailing lists from their sending email address.] -kevin -- Kevin W. Wall The most likely
