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

psiinon psiinon at gmail.com
Thu Nov 3 08:44:07 UTC 2016


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/
> DinisCruz/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20161103/e2871932/attachment-0001.html>


More information about the OWASP-Leaders mailing list