[Owasp-leaders] SecDevOps Risk Workflow Book (please help with your feedback)

psiinon psiinon at gmail.com
Thu Nov 3 13:53:52 UTC 2016


Hi Mario,

Thats a very good point.
We have a link on the ~ZAP 'Online' menu for 'Report an issue' but that
just links to the GitHub issues page - it doesnt allow you to copy any
specific info and its not great for people who dont have a github account.
I'll have a think about that and see what options I can come up with.

Many thanks,

Simon

On Thu, Nov 3, 2016 at 1:28 PM, Mario Robles OWASP <mario.robles at owasp.org>
wrote:

> Hi Simon,
>
> In my case, I’m hesitant to use the FP reporting features some tools have
> because I don’t have full control of what is going to be shared and of
> course there are cases where you don’t want to share information about
> issues in a site you’re testing (including some legal contractual concerns )
>
> I’m sure if ZAP provide a feature for automatically reporting FP where you
> can edit what you’re about to send I’ll be more open to send feedback, I
> know people can submit an issue on Github if they really want to contribute
> but sometimes you just need to get the job done with tight deadlines and
> those things will be excluded when you have to deal with other priorities
>
> Mario
>
>
> On Nov 3, 2016, at 02:44, psiinon <psiinon at gmail.com> wrote:
>
> Yeah, definitely a good idea.
> Special request - if an issue is a false positive generated by a tool can
> one of the actions be to inform the tool developers (open/closed,
> free/commercial) ?
> People always complain about false positives but very few seem to get
> reported (at least to us) :/
>
> Cheers,
>
> Simon
>
> On Thu, Nov 3, 2016 at 12:13 AM, Dinis Cruz <dinis.cruz at owasp.org> wrote:
>
>> HI Sherif, that is great feedback, yes it helps a lot
>>
>> I agree that we need to add those workflows. I have a couple examples for
>> them that I need to (re)create in a public JIRA, so that I share it and use
>> their diagrams (btw, do you have examples you can share?).
>>
>> And you are spot on on the need to create a two way communication channel
>> between devs and AppSec
>>
>> I really like those extra metrics and analysis that you are proposing
>> (need to try them out :)  )
>>
>> (btw I created this issue so that I can track all points made and make
>> sure they are all addressed https://github.com/D
>> inisCruz/Book_SecDevOps_Risk_Workflow/issues/146 )
>>
>> On 2 November 2016 at 23:23, Sherif Mansour <sherif.mansour at owasp.org>
>> wrote:
>>
>>> Hi Dinis,
>>>
>>> There should be a workflow, when it is a false positive, and for either
>>> the security team to challenge that claim or for them to apply a change in
>>> their tooling to improve the quality of the results.
>>> Additionally, you might also want the option for the developer/tech team
>>> to request more details as info is incomplete to re-create or understand
>>> the security issue.
>>>
>>> I think the common theme for those to points is that the developers are
>>> not always at fault and the conversation needs to be a two way street so
>>> security engineers get better and communicating and tuning their tests with
>>> the developers.
>>> Another thing is the resolution state. Jira has a few (User error/will
>>> not fix/fixed/etc..). You might want to use resolution states so you can do
>>> analysis off the back of it. What type of issue resulted in the most false
>>> positives? And which issues did dev teams accept the risk the most? Etc..
>>>
>>> Hope that helps :-)
>>>
>>> -Sherif
>>>
>>>
>>> On Sun, Oct 30, 2016 at 11:43 AM, Dinis Cruz <dinis.cruz at owasp.org>
>>> wrote:
>>>
>>>> Andre see I just updated Describe Risks as Features rather than as
>>>> Wishes
>>>> <https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/Jira-risk-workflow/Describe-risks-as-features.md> which
>>>> expands on this topic (namely how to write those RISK tickets)
>>>>
>>>> Dinis
>>>>
>>>> On 29 October 2016 at 00:57, Andre Gironda <andreg+owasp at gmail.com>
>>>> wrote:
>>>>
>>>>> On Fri, Oct 28, 2016 at 4:35 PM, Dinis Cruz <dinis.cruz at owasp.org>
>>>>> wrote:
>>>>>
>>>>>> Really enjoy the parts on JIRA -- I liked the parts about making Risk
>>>>>>> a separate project but what if appsec requirements/documentation are listed
>>>>>>> in its own Epic instead?
>>>>>>>
>>>>>>
>>>>>> That can work, the prob is that it is easy for those Epics to fall
>>>>>> into the 'backlog pit of despair
>>>>>> <https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/bbb2f5ee5c3e8a0e1f9cca43b47019e8fcfc1d25/content/2.Risk-workflow/For-developers/Backlog%20Pit%20of%20Despair.md>'
>>>>>> and start to be ignored (i.e. unless you have that 'Risk Accepted' button,
>>>>>> it is 'cheap and easy' to just keep prioritising other 'really important'
>>>>>> features required by the business/users). Another issue is that I like to
>>>>>> use the JIRA Risk project to describe 'reality' (i.e. the
>>>>>> Risks/Issues/features that exists or will exist soon) and then let the
>>>>>> dev's use their JIRA project (or whatever bug tracking system they use) to
>>>>>> describe what needs to be done (i.e. how they would address those RISK
>>>>>> issues) For example a RISK issue (in the separate RISK or APPSEC Jira
>>>>>> project) would be *"Xyz app - There is no Authentication on exposed
>>>>>> Web Service's methods" , *who would (when in the 'Allocated for Fix'
>>>>>> stage) be linked into another ticket (or multiple tickets) in the
>>>>>> application's JIRA project that would be called *"Use Spring
>>>>>> Security to authenticate users of service"*
>>>>>>
>>>>>
>>>>> This is great and adds context for me. I'll let you know how this
>>>>> conversation goes with the powers that be.
>>>>>
>>>>>
>>>>>> Btw, do you open JIRA tickets for the issues/risks/threats raised by
>>>>>> Threat Models?
>>>>>>
>>>>>
>>>>> Yes, and I very-much also enjoyed the notion of Chained Threat Models.
>>>>> I think I used those exact same words the same day that you did to describe
>>>>> the very-same thing. Uncanny.
>>>>>
>>>>> Thank you,
>>>>> Andre
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OWASP-Leaders mailing list
>>>> OWASP-Leaders at lists.owasp.org
>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>>
>
>
> --
> OWASP ZAP <https://www.owasp.org/index.php/ZAP> Project leader
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
>


-- 
OWASP ZAP <https://www.owasp.org/index.php/ZAP> Project leader
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20161103/a7361095/attachment-0001.html>


More information about the OWASP-Leaders mailing list