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

Mario Robles OWASP mario.robles at owasp.org
Thu Nov 3 13:28:25 UTC 2016


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 <mailto: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 <https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/issues/146> )
> 
> On 2 November 2016 at 23:23, Sherif Mansour <sherif.mansour at owasp.org <mailto: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 <mailto: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 <mailto:andreg+owasp at gmail.com>> wrote:
> On Fri, Oct 28, 2016 at 4:35 PM, Dinis Cruz <dinis.cruz at owasp.org <mailto: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 <mailto:OWASP-Leaders at lists.owasp.org>
> https://lists.owasp.org/mailman/listinfo/owasp-leaders <https://lists.owasp.org/mailman/listinfo/owasp-leaders>
> 
> 
> 
> 
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org <mailto:OWASP-Leaders at lists.owasp.org>
> https://lists.owasp.org/mailman/listinfo/owasp-leaders <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20161103/1bb6c627/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20161103/1bb6c627/attachment.pgp>


More information about the OWASP-Leaders mailing list