[Owasp-board] 2016 ideas

Matt Konda matt.konda at owasp.org
Mon Nov 23 23:15:21 UTC 2015


Jim,

I have read the doc.  It wasn't at all clear to me what the full scope of
the bounties would be, I thought those were just a few examples.

I'll stew on it some more ...

Matt


On Mon, Nov 23, 2015 at 4:42 PM, Jim Manico <jim.manico at owasp.org> wrote:

> > Otherwise, you end up paying bounties for things that are really easy
> to find and look bad along the way.
>
> Fair comments, Matt.
>
> Please read Johannas doc. The various bounties I'm suggesting are very
> narrowly focused and scoped.
>
> I agree with your comments if we were to conduct an "open bounty" but that
> is not what is being scoped.
>
> For example, I suggest for CSRF Guard we bounty:
> 1) Is the token generation weak crypto (predictable, etc)
> 2) Is the server side token verifier not properly verifying an active and
> propely configured endpoint.
>
> etc.
>
> By working together with project owners and security leaders, we should be
> able to define very clear rules of play so our financial expenditures on
> these issues are clear and useful.
>
> --
> Jim Manico
> Global Board Member
> OWASP Foundation
> https://www.owasp.org
> Join me in Rome for AppSecEU 2016!
>
> On Nov 23, 2015, at 5:44 PM, 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/c58a50c1/attachment-0001.html>


More information about the Owasp-board mailing list