[Owasp-leaders] The Only Thing That Is Constant Is Change

johanna curiel curiel johanna.curiel at owasp.org
Sun May 8 16:15:06 UTC 2016


Hi Kevin and All

The Best practices criteria contains 6 sections

   1. Basics
   2. Change Control
   3. Reporting
   4. Quality
   5. Security
   6. Future

Many of our projects do not even fulfil 'basics' of the criteria defined
here.

>>"I think it is well-intentioned, but unlikely to improve either security or
quality of participating projects"

I disagree partially. For many OWASP projects, going through this criteria
can make them aware of all the things missing in their projects such as
'Basics'  Things like 'version number, 'release notes' are not even found
in many LAB projects.

So if a project leader takes the time to improve this, he is definitely
improving his project.

I agree with you that on the section 'Security' that is another caliber.
The example you provided regarding OpenSSL and Heartbleed are a clear
example.
Thats why we have started the Bug Bounty Program for projects @ OWASP for
this purpose.

*On Volunteers...*

I though one of the main tasks
<https://owasp.recruiterbox.com/jobs/fk06qyo?apply=true> of the community
manager <https://owasp.recruiterbox.com/jobs/fk06qyo?apply=true>was to help
build a volunteer program. I even offered my help on this but did not received
an answer.
<http://lists.owasp.org/pipermail/owasp-board/2016-February/016991.html>

We also need to place focus and attention from management point of view on
this, so the next community manager is not only confined to monitoring
chapters activity, create a monthly newsletter and send tweets and Facebook
msgs.

I requested to setup a volunteer portal
<https://github.com/OWASP/VolunteerPortal)>on the github a while ago and
the idea is to create a portal and to look actively for volunteers, and
promote the right information when people look for this by improving the
actual wiki pages, since they are quite outdated and does not reflect the
actual situation (google 'owasp volunteer 'and check what you find). Match
them with activities depending on their interest similar to what Mozilla
portal does. This is essential in a community that is supposed to be driven
by volunteers.We can also do this on the wiki page but instead of
redirecting the user to a 'job listing' this should redirect to a portal
similar to Mozilla does.

Please who ever manages this page which appears on the wiki page when you
click 'Volunteer' link:
http://owasp.force.com/volunteers/GW_Volunteers__VolunteersJobListing ,
take the 'jobs' word out of it. Volunteers do not 'volunteer for a job' nor
should volunteers be treated like employees.

We need to match volunteer interest with the activities we have and we need
to work on recruiting, motivate  and promote volunteer participation. We
are failing and this in areas that require support for Projects and
participation in Global initiatives because we do not have a proper
Volunteer Management Program.

*Kevin*, I can only create a portal for volunteer matching interest for
projects and that is the area that I know and if we have the support from
OWASP to promote the portal as organisation we can reach more. But if we do
not have this support then it wont work.

I will set this in the agenda for the board and I think we need to check
those members/volunteers willing to work on this to see if we can actually
build a better volunteer driven community for projects.

regards

Johanna




On Sun, May 8, 2016 at 1:05 AM, Kevin W. Wall <kevin.w.wall at gmail.com>
wrote:

> I shall try to reply to both of you at once rather than writing two
> separate TL;DR responses. :)
>
> On Sat, May 7, 2016 at 12:07 PM, johanna curiel curiel
> <johanna.curiel at owasp.org> wrote:
> > On Sat, May 7, 2016 at 10:16 AM, Tom Brennan - OWASP <tomb at owasp.org>
> wrote:
> >>
> >> "The stakes have never been higher for open-source software security.
> With
> >> millions of people around the world relying on open source software —
> and
> >> vulnerabilities like Heartbleed putting everyone at risk — it's time to
> >> change the way we support, protect, and fortify open software."
> >>
> >> Interesting article and project(s) now available
> >>
> >> http://www.linuxinsider.com/story/83463.html
> >>
> >> Why should OWASP code based projects not work together on this
> initiative
> >> in raising visibility for Software security, improving our project
> quality
> >> and management.
> >>
> >> Discussion, Debate, Agreement where do you stand on it OWASP Leaders?
> >>
> >> https://www.coreinfrastructure.org/programs
> >>
> >> Tom Brennan
> >
> > Tom,
> >
> > CII Badge criteria is a heavy set of checklist to control that an open
> > source project complies with certain norms in different fields such as
> > proper development and security
>
> And I think the debate part is whether compliance to some "CII Badge
> criteria"
> is going to actually change things. Case in point, OpenSSL; not to pick on
> them for any reason than I already pointed them out to 200+ developers at
> Stir Trek yesterday as a case of where we are failing despite trying to
> do all the right things. OpenSSL is already at 100% compliance with the
> CII badge criteria (see
> https://bestpractices.coreinfrastructure.org/projects/54). This is in
> comparison
> to their 64% compliance *before* Heartbleed (see
> https://bestpractices.coreinfrastructure.org/projects/87). Heartbleed was
> CVE-2014-0160; as per cve.mitre.org, the CVE was created 12/03/2013.
> (The article that Tom referenced says Heartbleed was discovered in April
> 2014,
> but I think that was when it was publicly disclosed, not discovered.)
>
> Okay; now let's look at the CVE data for OpenSSL, pre and post Heartbleed:
> https://www.cvedetails.com/product/383/Openssl-Openssl.html?vendor_id=217
>
>     From 1999-2013 (pre-Heartbleed): 73 CVEs
>     From 2014-current (post-Heartbleed): 76 CVEs
>
> Well, there is a lot of things that we could attribute this to, most likely
> more people hunting for vulnerabilities in OpenSSL since Heartbleed, but I
> certainly fail to see that their process changes have had much of an
> impact.
> (Of course, I suppose one could argue that had they continued processes as
> usual at OpenSSL post-Heartbleed, the # of CVEs since 2014 may have been
> considerably more than 76. Or it could be argued that most of those were
> discovered by the OpenSSL team themselves, although a few weeks ago I had
> read something that showed otherwise.)
>
> Anyhow, my point is that if OpenSSL has 18 CVEs already in on 5 months into
> 2016, what possible meaning does 100% compliance with CII Badging mean?
>
> > Being someone who has looked closely most projects code and development
> > process, I can tell with confidence , most, including those labeled as
> > flagship , won't be able to comply with these norms
>
> That is likely true. I read through some of the questions that ZAP wasn't
> compliant with. (See
> https://bestpractices.coreinfrastructure.org/projects/24
> and then click on "Hide met or N/A criteria".) The only thing that shows up
> is 'What is the Common Platform Enumeration (CPE) name for the project (if
> it
> has one)?" The "(if it has one)" part implies that Simon could have left it
> blank or answered as N/A and ended up with 100%.  I doubt that any of our
> OWASP projects have a CPE. (And if it's as much of a pain in the ass to get
> a CPE as it is for Mitre and NVD to acknowledge a CVE, I doubt there will
> be
> many who will try to get one either, but I digress.)
>
> Also, if you look at some of the other questions that CII Badging asks,
> you can tell this seems very subjective in places. E.g., questions like
> "The project MUST provide basic documentation for the software." is pretty
> open-ended. It certainly concerns me that we would even allow a developer
> to answer this about their own software projects. Is the CII Badging
> criteria
> going to do follow-up on these questions to confirm they were answered
> accurately and without bias? If not, then how can we trust any meaning
> behind
> these badges in the first place. A lot of developers that I've worked with
> have disdained writing documentation and they think that whatever miniscule
> amount they have written is sufficient or that surely someone else will
> follow up with YouTube tutorials, answering Stack Overflow questions, etc.
> and that they don't really need to document stuff beyond the very basics.
>
> There are also questions like "The project MUST acknowledge a majority of
> bug
> reports submitted in the last 2-12 months (inclusive); the response need
> not
> include a fix." What does that really mean unless there is someone
> regularly
> confirming that this is still the case every few months?
>
> There is also this question related to security:
>     "A cryptographic hash (e.g., a sha1sum) MUST NOT be retrieved over
> http and
>     used without checking for a cryptographic signature."
>
> This question is mostly pointless because someone can claim to be mirroring
> your site, but change your software and modify the hashes. A cryptographic
> hash is NOT equivalent to a cryptographic signature. Given all the clueful
> people on their advisory board who know about cryptography, I'm not sure
> how this question even got through.
>
> Also, it would be interesting to know if all questions are scored equally.
> If the main purpose of CII Badging is to prevent another Heartbleed like
> vulnerability from being made public, one would think that questions such
> as
>     "There MUST be no unpatched vulnerabilities of medium or high severity
> that
>     have been publicly known for more than 60 days."
> ought to carry a lot more weight than one about (say) documentation. And
> one really has to question the question
>     "Projects SHOULD fix all critical vulnerabilities rapidly after they
> are
>     reported."
> I SHOULD think that MUST is the more appropriate wording here! :)
>
> There there is this question, under "Future":
>     "(Future criterion) The project SHOULD provide a way to easily install
> and
>     uninstall the software using a commonly-used convention."
>
> It is not clear what is expected here, but one big concern that I have is
> that
> over vendors (some FLOSS projects, some not) have repackaged OWASP ESAPI
> without
> our being aware. E.g., ESAPI was retrieval as an RPM under Fedora 20 (and
> might
> still be) and it is is also delivered as part of Oracle WebLogic Server
> 12.3.
> The BSD license of course allows this, but if when I look at these things
> from
> a security perspective, it raises concerns.  For instance, when there are
> fixes we post them to the 2 ESAPI related mailing lists and for the 2
> vulnerabilities, I was able to convince Mitre and NVD to have CVEs created.
> There are other security-related issues similar to the Java deserialization
> issue that Apache Commons Collections had with InvokerTransformer (see
> COLLECTIONS-580) that Mitre did not grant a CVE for so it was unlikely
> we would have received one for the Java deserialization issue in the method
> Base64.decodeToObject() (see
> https://github.com/ESAPI/esapi-java-legacy/issues/354)
> either. (Not that it seems to matter; Oracle WebLogic Server 12.3 is still
> using ESAPI 2.0GA from May 2011!)
>
> Give that (for example) Red Hat provided ESAPI as an RPM so it could be
> installed via 'yum', is Linux Foundation expecting that we make things
> retrieval via Linux repositories via things like yum and apt-get? What
> exactly are their expectations here? Of course, if no one is looking at
> the answers, I guess it really doesn't matter.
>
> > Right now I think OWASP needs to set focus on developing a better
> platform
> > to attract developers, volunteers and project leaders, motivating them to
> > produce quality projects.
>
> I agree, but I don't think that the problem is primarily the "platform",
> but rather one of motivation. I'll use myself as an example. I used
> open source ever since the early USENET Newsgroups days, but until ESAPI
> all I ever contributed was an occasional bug fix for a bug that irritated
> me so much and no one else would seem to fix that I was motived to fix it
> myself. Unfortunately, I think most of the development community was like
> that. I started contributing because I thought it would be a good way to
> keep my skills sharp (since as a tech lead, ironically, my management no
> longer wanted me to write code).
>
> > A volunteer program and platform that can help match volunteers with
> > initiatives and projects.
>
> Yes; and one thing that I would like to see are people in OWASP who might
> be willing to sign up for short stints as "subject matter experts" on
> subjects like Maven, git, JavaScript, JUnit, cryptography, C#, Java, C++,
> using various frameworks like Spring and Struts, etc. I have mentioned this
> before, but I will mention it again. The last ESAPI release in February
> 2016
> could have been done maybe 6 months earlier had I known how to manually
> resolve merge conflicts on pull requests on GitHub. (This was before we
> had a .gitattributes file so the EOL issues between Windows and Linux
> caused
> literally hundreds of merge conflicts.) I appealed several times to the
> community until I finally found someone who explained it to a git newb like
> me. If there were an SME list at OWASP and someone listed as a git / GitHub
> SME, I could have just contacted her and had this resolved months sooner.
> Such SME volunteers would not have to commit to any specific project on a
> long term basis. I think that concern over long term commitments might be
> one thing that is keeping people from stepping up and volunteering.
>
> > Producing a quality project like ZAP needs dedication and resources
> > including a deep commitment to make it work. ZAP project leader and
> > volunteers work 100% on ZAP, this is by no means a 'hobby' or side
> > project.Even so ZAP is right now 92% compliant with the CII criteria and
> > still needs to work on it.
> >
> > Most project leaders are doing this as side-hobby projects and in this
> way ,
> > we will never be able to pull off projects compliant with CII
> criteria.Most
> > are lonely leaders building their projects when they have time and once
> in a
> > while they have the collaboration of contributors.
>
> +1
>
> > So we need to be realistic and be careful not to impose projects a
> criteria
> > or process they will never be able to fulfill without the right platform
> and
> > incentives.
> >
> > As I mentioned before I strongly recommend to focus on creating and
> building
> > a volunteer program and really think through how to attract and retain
> > volunteers, create initiatives that can help produce quality projects and
> > work with those project leaders looking for help.
>
> I'm open to suggestions of how we can do that.
>
> > Collaboration and support is the key for creating meaningful and lasting
> > open source projects.
> >
> > Regards
> >
> > Johanna
>
> Thanks for taking the time to read my rants. As far as the CII Badges go,
> I think it is well-intentioned, but unlikely to improve either security
> or quality of participating projects, but I'm willing to give it a go.
>
> -kevin
> --
> Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
> NSA: All your crypto bit are belong to us.
>



-- 
Johanna Curiel
OWASP Volunteer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20160508/acb044ff/attachment-0001.html>


More information about the OWASP-Leaders mailing list