[Owasp-board] 2016 ideas

johanna curiel curiel johanna.curiel at owasp.org
Mon Nov 23 16:15:25 UTC 2015


Hi Matt

My respons to your remarks

>>Otherwise, you end up paying bounties for things that are really easy to
find and look bad along the way.

The thing is, *there is no one testing at security level these libraries*.
If we think the bugs are easy to find, then we limit the amount per bug(my
proposal is just USD500 max). Now, you mentioned 'they are easy to find'
but there is no QA review to support this argument. This is in my opinion a
'cheap' way to test. You only pay the amount you consider worth depending
on the vulnerability found. There is a disclosure agreement between testers
at hackerone, responsible discloser means , they are not suppose to be
advertising these issues in the open unless we decided.

*>>In summary, I think there are alternative approaches that we should take
on before doing a bounty program - including systematically engaging with
volunteers to do security audits, engaging with vendors to get their
feedback, and building security checkpoints into the project maturity
process.*

This so far has not worked.Keep in mind I was a reviewer and part of the
Project review task force team. People do not want to volunteer to do
simple reviews and doing 'security audits' are more complex in nature,
based on my experience , this is not happening at all. Easier said than
done. If you have alternatives that are realistic to implement then I think
Matt you should propose them.

I believe the bigger testers are the users and consumers of these projects,
like happened with PHPSEC, but most of the time this 'afterwards'
verification is quite sour if you see how these users reacted to the
vulnerabilities they found. They trusted OWASP and were quite disappointed.
So a user/company is supposed to find the library is not secure when he
submitted the app to pen testing? That is quite disappointing. And also
probably, he will stop using it and will not report the issue to project
leader as the PHPSEC users did.

I think OWASP should take a pro-active step to verify how secure these
projects are. This has direct implication in OWASP image. This is a pilot
and the idea of the pilot if to 'test' if this program could work, not per
se I'm implying to implement one completely.Why wait a hacker finds out
instead of ourselves and in this way support the project leaders with a QA
review and help fix the bugs?

I think submitting these libraries to this rigorous testing in such a
program will be valuable for the entire community and proactive initiative
at OWASP to verify 'security' libraries. We only pay for very specific
cases, no DoS attacks since these are not part of the protection libraries
like CRSFguard. CRSF is about avoiding CRSF attacks ;-)

*>I believe that if we spent the time (and money) on the project controls
instead of communicating with researchers, we would likely have better
initial results.*

You will need to be more specific on this. Whether initiative takes time
and resources, The purpose of this initiative is to verify how secure are
the libraries submitting them through a heavy testing through that
program.We also support the project leaders , with the fixes through
bountysource program.

 I'm willing to manage the communication with researchers as a volunteer in
this process.
If there are volunteers willing to help on project controls then, that will
be fantastic, but so far, there is no initiative on this and no clear
proposal for this neither.


Regards

Johanna

On Mon, Nov 23, 2015 at 11:44 AM, Matt Konda <matt.konda at owasp.org> wrote:

> I have also run bounty programs and I would take what Michael said and go
> a bit further.
>
> I am skeptical of this approach for OWASP at this time.  Generally, I
> support bounty programs when an organization or project is *mature* and
> basic controls have already been applied.  This implies that tools have
> been run, code has been reviewed and there are things in the SDLC that
> allow you to respond in a controlled manner (eg. regular releases,
> resources available for quick response and a solid bug triage process).
>
> Otherwise, you end up paying bounties for things that are really easy to
> find and look bad along the way.  Also, we'll spend a lot of time dealing
> with communications and researchers who are only sometimes good to work
> with.  I believe that if we spent the time (and money) on the project
> controls instead of communicating with researchers, we would likely have
> better initial results.
>
> I don't have access to edit or comment upon the doc, but I would
> definitely push for:
>
>    - Limits on scanner findings
>    - Limits on DoS category findings
>
> In summary, I think there are alternative approaches that we should take
> on before doing a bounty program - including systematically engaging with
> volunteers to do security audits, engaging with vendors to get their
> feedback, and building security checkpoints into the project maturity
> process.
>
> I applaud the general goal and aspiration of ensuring rigorous security in
> our projects.
>
> Matt
>
>
> On Mon, Nov 23, 2015 at 7:15 AM, johanna curiel curiel <
> johanna.curiel at owasp.org> wrote:
>
>> Hi All,
>>
>> The idea is to finalised working out the items scope for each project.
>> Like mentioned in the proposal, I think is a good idea to take 3 projects
>> (Flagship,Lab,Incubator) and workout through a series of items for each one.
>>
>> From Jim's experience in defenders library, we can help define clear
>> scopes and with the project leaders input also, we need to define the most
>> important issues that will make the libraries weak on protection
>>
>> A set of steps here
>>
>>    - Finalise the items within the scope for each project part of the
>>    pilot
>>    - Touch based with the project leaders regarding their availability
>>    for feedback
>>    - Deploy a couple of websites (simple ones) that have the
>>    libraries configured
>>    - Deploy on a VM server and host a couple of domains for them for the
>>    researchers to test example:
>>       - crsfguard.owasp.org
>>       - xxxx.owasp.org
>>    - Setup  and configure an account in hackerone.com
>>    - Setup and configure an account bountysource.com
>>
>>
>> From there on is a management of the process, as researchers will submit
>> issues and we need to re-test them and validate them for this part
>>
>>    - Researcher submits issue
>>    - retest and verify the severity (Jim, me , Project leader)
>>    - feedback with Jim and Project leaders regarding the severity of the
>>    issue, all reports are available in hacker one as a Hacker/researcher
>>    submits the issue, if possible more people should retest to confirm the bug
>>    - determine together if indeed a bug has been confirmed ( Jim,  the
>>    project leader and me)
>>    - Once confirmed, log the bug in the projects Github
>>    - Make the payment to the researcher with approval of 3 members (
>>    Jim,  the project leader and me)
>>    - Publicise the bug issue through wiki project page, github issues
>>    section and eventually if it is high risk, the leader will have to set a
>>    warning on its Github repository
>>    - Project leader must provide feedback on his availability with the
>>    projects volunteers on fixing the issue
>>    - If this is not fixable or too complex for the leader to fix, we
>>    attempt a bountysource.com fix
>>    - If someone fixes the issue through bountysource.com, it must be
>>    retested and confirmed
>>    - Can run again in hackerone to verify that specific bug fix after
>>    deployment (payment amount to be determined)
>>    - The fix must be merged into the master branch of the repository
>>    and  incorporated into a new release
>>    - It project is updated with fix
>>
>>
>> *Conditions for the participating owasp project:*
>> Must have an active leader we can feedback with regarding the issues
>> found. I think this is essential for the completeness of the project's
>> definition of bugs and later fixes
>>
>> These are just some draft steps part of the proposal and process, if you
>> have any advice regarding this, please let us know
>>
>> regards
>>
>> Johanna
>>
>>
>> On Mon, Nov 23, 2015 at 3:48 AM, Jim Manico <jim.manico at owasp.org> wrote:
>>
>>> Thanks Michael and Josh for your astute feedback. Johanna already has a
>>> decent proposal on the block and I've provided several edits and issues to
>>> consider.
>>>
>>> If you have time, would love to have you both mark up the doc directly
>>> with your comments and thoughts. :)
>>>
>>> Thanks and Aloha,
>>> --
>>> Jim Manico
>>> Global Board Member
>>> OWASP Foundation
>>> https://www.owasp.org
>>> Join me in Rome for AppSecEU 2016!
>>>
>>> On Nov 23, 2015, at 1:42 AM, Michael Coates <michael.coates at owasp.org>
>>> wrote:
>>>
>>> Awesome stuff. I've run teams on the receiving end of bug bounties at
>>> both Mozilla and Twitter. Happy to provide any feedback if helpful. Key
>>> items are good and fast responses to researchers and actually closing valid
>>> issues in a timely manner. If we can't commit to those items we'd want
>>> to reconsider our approach.
>>>
>>> On Sunday, November 22, 2015, Jim Manico <jim.manico at owasp.org> wrote:
>>>
>>>> We're working on a proposal and plan right now. More soon.
>>>>
>>>> --
>>>> Jim Manico
>>>> Global Board Member
>>>> OWASP Foundation
>>>> https://www.owasp.org
>>>> Join me in Rome for AppSecEU 2016!
>>>>
>>>> On Nov 22, 2015, at 12:57 PM, Josh Sokol <josh.sokol at owasp.org> wrote:
>>>>
>>>> I like the concept, but have some questions before the Board were to
>>>> approve something like this:
>>>>
>>>>    1. Is there an actual proposal to fund a Bug Bounty?  If so, what
>>>>    is the dollar amount that the Board would be authorizing here?
>>>>    2. A bug bounty program is more than just a dollar amount, it's a
>>>>    process.  Have we created a process for handling any submissions that come
>>>>    in for bugs?
>>>>    3. Once you have a submission, are we just throwing it in a
>>>>    database somewhere or is there an expectation that someone will fix it?
>>>>    Who is responsible for that?
>>>>    4. If the answer to #3 is the project team, then what happens if
>>>>    they do not fix it in a timely manner?  Is the project demoted?  If the bug
>>>>    is serious enough, do we halt all downloads of the project until it is
>>>>    fixed?  Do we attempt to warn users?
>>>>
>>>> In short, I think it's great to say "We want a bug bounty program like
>>>> Hackerone", but there are way more details that need to be hashed out
>>>> here.  I recommend putting together a team to assess how this would work as
>>>> part of an actual process for OWASP.  I wouldn't be comfortable authorizing
>>>> any funds until I had that information.
>>>>
>>>> ~josh
>>>>
>>>> On Sun, Nov 22, 2015 at 12:12 AM, johanna curiel curiel <
>>>> johanna.curiel at owasp.org> wrote:
>>>>
>>>>> To run a programma like hackerone we will need to verify the bugs found
>>>>> We could start with a pilot For CRSFGuard and Dependency Check projects
>>>>> I volunteer to manage the programma For these projects
>>>>> I can set a plan to determine the scope of the program with The
>>>>> project leaders and make sure we verify the
>>>>> veracity of the reported bugs
>>>>>
>>>>> What does The board need from me in order to approve my proposal?
>>>>>
>>>>>
>>>>> On Saturday, November 21, 2015, Michael Coates <
>>>>> michael.coates at owasp.org> wrote:
>>>>>
>>>>>> "I would say that for the existing Flagship & LABS (libraries or
>>>>>> code) we should run a program through Hackerone or Bugbounty.(off course
>>>>>> insecure applications as WebGoat are out of scope ;-))"
>>>>>>
>>>>>> Yes. This would generate awareness, generate opportunities for new
>>>>>> volunteers and put a better control around our prominent code.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Michael Coates | @_mwc
>>>>>> <https://twitter.com/intent/user?screen_name=_mwc>
>>>>>> OWASP Global Board
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Nov 21, 2015 at 8:34 AM, johanna curiel curiel <
>>>>>> johanna.curiel at owasp.org> wrote:
>>>>>>
>>>>>>> Hi Jim & Board
>>>>>>>
>>>>>>> 'Developers come to us'... is indeed a moderate approach. I just
>>>>>>> finalised a security project reviews developed by very serious companies in
>>>>>>> EU and it amazes me that they were using CRSFGuard and even ESAPI.
>>>>>>>
>>>>>>> There is a dependency and the reason why the PHPSEC users were angry
>>>>>>> at OWASP, they were using the project for some serious development of
>>>>>>> financial applications and counting on OWASP to secure them.
>>>>>>>
>>>>>>> Since OWASP cannot offer a QA process review of its own projects, we
>>>>>>> should be careful here and indeed, the approach to help improve existing
>>>>>>> frameworks is more realistic and has less risks associated with reputation
>>>>>>> issues to OWASP image
>>>>>>>
>>>>>>> I would say that for the existing Flagship & LABS (libraries or
>>>>>>> code) we should run a program through Hackerone or Bugbounty.(off course
>>>>>>> insecure applications as WebGoat are out of scope ;-))
>>>>>>>
>>>>>>> Again, maybe the focus should stop in trying to create libraries as
>>>>>>> Tim said but focus the efforts into working on existing frameworks.
>>>>>>>
>>>>>>> The reality is that creating security libraries is VERY hard and it
>>>>>>> has a lot of consequences for OWASP image if serious issues are found as
>>>>>>> the case of PHPSEC
>>>>>>>
>>>>>>> regards
>>>>>>>
>>>>>>> Johanna
>>>>>>>
>>>>>>> On Sat, Nov 21, 2015 at 11:55 AM, Jim Manico <jim.manico at owasp.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Folks,
>>>>>>>>
>>>>>>>> I'm feeling a bit more clarity on suggesting technical resource
>>>>>>>> hires for 2016. Paul, these are just ideas to trigger strategic planning
>>>>>>>> discussions and ideas. I agree that the final decisions around these hires
>>>>>>>> is "all you".  I hope this email is taken in the spirt of "ideas to
>>>>>>>> consider".
>>>>>>>>
>>>>>>>> 1) Wiki experts (previously discussed)
>>>>>>>> 2) Web design expert (previously discussed)
>>>>>>>> 3) Technical contractor or bounties to help augment the security of
>>>>>>>> common software frameworks (big potential here)
>>>>>>>> 4) Security assurance contractors or bounties to help review OWASP
>>>>>>>> defensive projects
>>>>>>>>
>>>>>>>> The whole "developers, come to us" is only modestly effective.
>>>>>>>> "Developers, we want to help and go to you" is a much more effective
>>>>>>>> movement, IMO.
>>>>>>>>
>>>>>>>> Thinking a bit out of box here... If we spent significant funds in
>>>>>>>> helping improve common software frameworks for security - we could really
>>>>>>>> have a massive impact on the world at large. I'd love to see serious
>>>>>>>> investment in this area....
>>>>>>>>
>>>>>>>> Aloha,
>>>>>>>> --
>>>>>>>> Jim Manico
>>>>>>>> Global Board Member
>>>>>>>> OWASP Foundation
>>>>>>>> https://www.owasp.org
>>>>>>>> Join me in Rome for AppSecEU 2016!
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Owasp-board mailing list
>>>>>>>> Owasp-board at lists.owasp.org
>>>>>>>> https://lists.owasp.org/mailman/listinfo/owasp-board
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Owasp-board mailing list
>>>>>>> Owasp-board at lists.owasp.org
>>>>>>> https://lists.owasp.org/mailman/listinfo/owasp-board
>>>>>>>
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Owasp-board mailing list
>>>>> Owasp-board at lists.owasp.org
>>>>> https://lists.owasp.org/mailman/listinfo/owasp-board
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Owasp-board mailing list
>>>> Owasp-board at lists.owasp.org
>>>> https://lists.owasp.org/mailman/listinfo/owasp-board
>>>>
>>>>
>>>
>>> --
>>>
>>> --
>>> Michael Coates | @_mwc
>>> <https://twitter.com/intent/user?screen_name=_mwc>
>>> OWASP Global Board
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Owasp-board mailing list
>>> Owasp-board at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-board
>>>
>>>
>>
>> _______________________________________________
>> Owasp-board mailing list
>> Owasp-board at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-board
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-board/attachments/20151123/7174e1d3/attachment-0001.html>


More information about the Owasp-board mailing list