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

Mario Robles OWASP mario.robles at owasp.org
Thu Nov 3 00:51:35 UTC 2016


Hi Dinis, Sherif,

I’m going to jump in here again :)

In my case, I added new Custom fields for providing more technical details to each issue, here’s what I’ve done:
One project for tracking assessments (Pentest, Code Reviews, Risk assessments, Threat modelling, whatever will throw issues that need to be fixed)
Vulnerability Tracking Project with custom fields for:
CVE
CWE
Severity
Attack Vectors
Threat Actors
Request | Response (Using Wiki Style Renderer for adding code boxes and nice looking details)
PoC
CVSS Score or any internal risk score system
Remediation Notes
Use Due date for setting remediation timeframe for internal policy compliance and send notifications when it’s about to expire
Security Level: Used for limiting the issue visibility to the team that need to work on it (Dev Team A, Dev Team B, Infrastructure, Messaging Team, etc), this will make the board to be more clean for other teams as well
In practice, every Pentester will work on assessments attaching reports to the issue added to the assessments tracker (they can log work in there as well so you can measure how much time do your team spend on assessments), also every issue added to the vulnerability tracker will have a link to the assessment so you can later group issues by assessment

Later the developer can grab the issue and link it to a user story in their agile board for working on fixing it using their usual dev workflow, when it’s ready for security testing the dev team just move the issue to the testing status so security get notified and work on validations and provide the sign off for deploying and etc etc

Hopefully this would help a bit as well




Mario

> On Nov 2, 2016, at 18:13, 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 <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
> https://lists.owasp.org/mailman/listinfo/owasp-leaders

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20161102/7e59d4d6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-14.png
Type: image/png
Size: 65692 bytes
Desc: not available
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20161102/7e59d4d6/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-15.png
Type: image/png
Size: 115826 bytes
Desc: not available
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20161102/7e59d4d6/attachment-0003.png>
-------------- 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/20161102/7e59d4d6/attachment-0001.pgp>


More information about the OWASP-Leaders mailing list