Re: [SC-L] Sad state of affairs
Well, one of the objectives of employing secure coding practices is just that - to raise the cost and complexity of exploiting bugs. Cheers, Prasad > On Sep 20, 2013, at 7:47 PM, "Bobby G. Miller" wrote: > > I was just listening to a podcast interviewing a security executive from a > prominent vendor. The response to vulnerabilities was to raise the > cost/complexity of exploiting bugs rather than actually employing secure > coding practices. What saddened me most was that the approach was apparently > effective enough. > > ___ > 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: attack categories
Gary,
Great article and since you used attacks and categories in the same :)
sentence I am tempted to ask if you looked at WASC Threat
Classification project?
On Tuesday, August 25, 2009, Steven M. Christey wrote:
>
> Gary,
>
> You said in the article:
>
>>The next category of attacks to expect are attacks that target defects in
>>design and architecture - which I call flaws.
>
> I think it's already happening. I fully expect to see this reflected in
> the updated CVE vulnerability trends for 2007/2008, which (fingers
> crossed) will be released in the next month or so (OK, most of the flaws
> will be in web apps, but still...)
>
>>we lack a taxonomy of flaws such as the ones we have for bugs (see the
>>Seven pernicious kingdoms and the CWE).
>
> CWE is not just a bug parade, it's also a flaw parade ;-) Although the
> parts related to flaws don't
> have the depth or specificity that exists for bugs/faults. The
> "weaknesses introduced during design" view CWE-701 actually lists 353
> entries.
>
> http://cwe.mitre.org/data/lists/701.html
>
> ... although there are a lot of weaknesses that you could argue are bugs.
> For example, is path traversal a bug or a flaw? It probably depends on
> how file handling is performed within a specific application. Actually, I
> think the lines between flaws and bugs/faults can get pretty fuzzy.
>
> We do want to address CWE's relative lack of depth for flaws, however.
> The hierarchy in the research view (CWE-1000) may be the best way to
> peruse where CWE stands. I'd love to hear from others who are working in
> classification at the flaw level.
>
> Current areas of promise under CWE are CWE-227 ("API Abuse" which has been
> borrowed from Seven Pernicious Kingdoms and given a little more
> structure), resource lifecycle issues and control spheres (CWE-664),
> external control of critical data/variables/systems/clients (CWE-642),
> protection mechanism failures (CWE-693), and even many of the classic
> Saltzer-and-Schroeder design principles (CWE-657). It is not coincidental
> that these areas still need some work, and any/all input is welcome. Use
> the "graph" tab on the individual CWE pages to see the sub-hierarchies.
>
> Interestingly (or perhaps not), implementation bugs and
> design/architecture flaws may share some of the same underlying
> fundamental properties. For example, a bug-level action of setting a
> variable declaration to "public" instead of "private" has some of the same
> properties as a flaw-level action of creating an open socket that anybody
> can connect to - you're unintentionally exposing a resource to somebody
> who shouldn't have any access to that resource at all. Or, as an example
> of a resource lifecycle problem, a use-after-free implementation bug isn't
> so different than the flaw in which you continue to use a certificate
> after it has expired.
>
> I suspect that design/architecture level taxonomies will be very
> challenging to build. For one part, there's a lot less research in the
> area than implementation bugs (at least the research that I'm aware of),
> and certainly a lot less public vuln data to draw from (e.g. CVE). There's
> a lot of stuff on design but not in any easily-packaged form to build a
> taxonomy, and it's often tied to specific technologies. For another, you
> have a lot more different perspectives at play. We can look at an
> unbounded strcpy and say "well that's clearly a bug" but at the design
> level, is the problem "use of a language that supports arbitrary indexing
> of arbitrary pointers" or "use of a risky API function that doesn't
> perform its own bounds-checking" or "use of a data structure [string] that
> does not have expliticly-stated length as a separate field from the
> buffer" or "failure to validate input"? (The answer may be "all of the
> above" or "it depends on your perspective," but that's where taxonomy
> construction gets really hard.)
>
> I, for one, can't wait.
>
> - Steve
> ___
> 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.
> ___
>
--
Thanks & Regards,
Prasad N. Shenoy
___
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] IBM Acquires Ounce Labs, Inc.
Wow indeed. Does that makes IBM the only vendor to offer both Static and Dynamic software security testing/analysis capabilities? Thanks & Regards, Prasad N. Shenoy On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wyk wrote: > Wow, big acquisition news in the static code analysis space announced today: > > http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104&STORY=/www/story/07-28-2009/0005067166&EDATE= > > > Cheers, > > Ken > > - > Kenneth R. van Wyk > KRvW Associates, LLC > http://www.KRvW.com > > (This email is digitally signed with a free x.509 certificate from CAcert. > If you're unable to verify the signature, try getting their root CA > certificate at http://www.cacert.org -- for free.) > > > > > > > ___ > 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] Security Architecture Cheat Sheet - Lenny Zeltser
Good idea :-) On Fri, Jun 19, 2009 at 11:15 PM, Jim Manico wrote: > Very nice work. > > Since this is written under the creative common 3 license, I put a copy > (with attribution to Lenny) on OWASP.org at > http://www.owasp.org/index.php/Security_Architecture_Cheat_Sheet in case > anyone wishes to collaborate on this guide. > > - Jim > > > ----- Original Message - From: "Prasad Shenoy" > To: > Sent: Friday, June 19, 2009 10:18 AM > Subject: [SC-L] Security Architecture Cheat Sheet - Lenny Zeltser > > >> Lenny Zeltser has published a Security Architecture Cheat Sheet. Out >> of his many cheat sheets, this one in particular might be of interest >> (in order of relevance :-)) to coders and architects on the group. >> >> >> http://www.zeltser.com/security-management/security-architecture-cheat-sheet.pdf >> >> Regards, >> Prasad Shenoy >> ___ >> 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. >> ___ >> > > -- Thought for the day - "Emails can hurt feelings. If this one did, please ignore your feelings." ___ 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] Security Architecture Cheat Sheet - Lenny Zeltser
Lenny Zeltser has published a Security Architecture Cheat Sheet. Out of his many cheat sheets, this one in particular might be of interest (in order of relevance :-)) to coders and architects on the group. http://www.zeltser.com/security-management/security-architecture-cheat-sheet.pdf Regards, Prasad Shenoy ___ 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] Announcing LAMN: Legion Against Meaningless certificatioNs
Great idea but why would you say CISSP is meaningless or MCSE is meaningless? Certifications are like technology. They have a place where they fit. CISSP became so popular and prolific because of the vast field of coverage (10 domains) that a certified practitioner had to study, understand, relate to and practice if given a situation. I am strongly against any certification that touts that you would be able to change the world for good. As silly as it might sound, there are quite a handful of these. On the other hand, companies like CISCO and Microsoft offer certification that allow "professional" to get certified and demonstrate their ability to understand and take over the responsibility of the said position that the certificate applies to. Now, if you make a case against certifications just because it has become so easy to cram overnight and get certified in the morning, then that's not justice. There are 2 extremes to the spectrum and you see only 1. It's like giving the entire security industry (professionals with certifications mostly) becuase of a few (thousand) individuals who don't prove to be laible candidates to have obtained that certification. You can compare it to how the world panned out the meaning of the holy word "Hacker" to what it is today. Prasad On Wed, Mar 18, 2009 at 5:29 PM, Jeremy Epstein wrote: > Colleagues, > > I'm pleased to announce the creation of LAMN, the Legion Against > Meaningless certificatioNs. If you don't have a CISSP, CISM, MCSE, or EIEIO > - and you're proud of it - this group is for you. > > You can join LAMN on LinkedIn by searching in the "groups" area. Unlike so > many other certifications, LAMN doesn't charge fees, require outrageously > overpriced exams, or demand check-the-box continuing education. > > Hope to see many people joining this group - and feel free to pass this > along! > --Jeremy > > P.S. After you join the group, you can proudly write your name , > LAMN - which conveniently also stands for Letters After My Name. I can't > recall who suggested the term to me, but would be happy to give credit if > someone wants to step forward and claim credit. > ___ > 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. > ___ > > -- Thought for the day - "Emails can hurt feelings. If this one did, please ignore your feelings." ___ 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. ___
