Follow-up code comments and changes after #10

content/2.Using-jira-workflow/Concepts/Ten-minute-hack-vs-one-day-work.md

@@ -12,13 +12,3 @@
 
 **In new code legacy**
 - if it also hard to refactor and change, then yes
-- sometimes external solutions (like a WAF) can be a more effective solution
-
-**Use frameworks**
-Many frameworks work as a wrapper around a 'raw' language and have built in mechanisms to prevent vulnerabilities.
-Examples are:
-- rails for ruby
-- django for python
-- angular for javascript
-
-Using these frameworks can help less experienced developers and act as a 'secure by default' mechanism. 

content/2.Using-jira-workflow/Concepts/Triage-issues-before-devs-see-them.md

@@ -0,0 +1,17 @@
+### Triage Issues before developers see them
+To prevent overloading developers with duplicate issues or false positives, issues identified in vulnerability scans, code analysers, and penetration tests, have to be triaged by the AppSec team, before pushing them to issue trackers (and exposing the developers to them).
+
+Unfortunately this is still an under developed part of the AppSec pipeline, and even commercial vendors UI don't really support the customisation and routing of the issues they 'discover'.
+
+Some tools exist that are attempting to do just that.
+
+* Bag of Holding https://github.com/aparsons/bag-of-holding
+* Defect Dojo https://github.com/OWASP/django-DefectDojo
+* ThreadFix
+
+With these triage tools AppSec specialists can already identify false positives, accepted risks, or theoretical vulnerabilities that are not relevant in the context of the system. This makes sure that developers only have to deal with the things that need actual fixing.
+
+#### Create JIRA workflow to triage raw issues
+
+* create a security jira workflow for the raw issues to act as a triage tool and push them to team boards after reviewing?
+* this would be another good example of the power of JIRA for workflows

content/2.Using-jira-workflow/Concepts/Using-appsec-to-measure-quality.md

@@ -1,6 +1,6 @@
 ### Using AppSec to measure quality
 
-* add content from presentation
+* add content from presentation [AppSec and Software Quality]( http://blog.diniscruz.com/2016/05/appsec-and-software-quality.html)
 
-Some academic research:
-https://insights.sei.cmu.edu/sei_blog/2016/06/using-quality-metrics-and-security-methods-to-predict-software-assurance.html
+* academic research   
+  * [https://insights.sei.cmu.edu/sei_blog/2016/06/using-quality-metrics-and-security-methods-to-predict-software-assurance.html](Using Quality Metrics and Security Methods to Predict Software Assurance)

content/2.Using-jira-workflow/For-developers/Make-managers-accountable.md

@@ -8,4 +8,4 @@
     * where the new manager is usually not happy when seeing the Risks that are currently accepted and will now be his responsibility
     * the new manager only has a couple months where he can 'blame' this predecessor, after that he really 'owns' that Risk and has Accepted it
 * this workflow creates historical records of decisions
-* In agile envrionments the Product Owner is responsible for making the right decisions.
+* In agile environments the Product Owner is responsible for making the right decisions.

content/2.Using-jira-workflow/For-developers/Risk-profile-of-frameworks.md

@@ -0,0 +1,25 @@
+### Risk profile of Frameworks
+
+Many frameworks work as a wrapper around a 'raw' language and have built in mechanisms to prevent vulnerabilities.
+
+Examples are:
+
+- Rails for Ruby
+- Django for Python
+- AngularJS, Ember, ReactJS for javascript
+- Razor for .Net
+
+Using these frameworks can help less experienced developers and act as a 'secure by default' mechanism.
+
+This means that when using the 'secure defaults' of these frameworks, there will be less Risk tickets created. Ideally Frameworks will make it really easy to write secure code, and really hard (and visible) to write dangerous/insecure code (for example how AngularJS handles raw HTML injection from controllers to views).
+
+This can backfire when Frameworks perform complex and dangerous operations 'automagically'. In those cases it is common for the developers to not really understand what is going on under the hood, and high risk vulnerabilities will be created (sometimes even using the code based on the Framework's own code samples)
+
+  * Add case-studies on issues created by 'normal' framework usage:
+    * SpringMVC Auto-Binding (also called over-posting)
+    * Razor controls vulnerable to XSS on un-expected locations (like label)
+    * Ember SafeHtml
+    * OpenAM SQL Query Injection on code sample (and see in live app)
+    * Android query SQL Injection (on some parameters)
+
+ * add reference (and some content from) _[Secure coding (and Application Security) must be invisible to developers](blog.diniscruz.com/2012/04/secure-coding-and-application-security.html)_

content/2.Using-jira-workflow/For-management/Annual-reports-should-contain-infosec-[art.md

@@ -4,9 +4,11 @@ Annual reports should have an info sec and app sec section, they should list to
 
 So, most companies have Intel dashboards of vulnerabilities, basically awareness of what is going on. That data should be published because only then, you can actually make the market work and reward companies. And make them understand that they need to invest and understand the pollution that happens when you have rented projects with crazy deadlines and don't really have the right resources but somehow manage to deliver.
 
-Which in a way is due to some heroic effort from some developers, who sometimes work their ass off to deliver something spectacular, and the management get rewarded by pushing them really hard. And then what you end up having is this highly spectacular vulnerabilities being created and highly spectacular risks that are now being bought by the company. And they don't even realize until it blows up one day.
+Which in a way is due to some heroic effort from some developers, who sometimes work their ass off to deliver something spectacular, and the management get rewarded by pushing them really hard. And then what you end up having is this highly spectacular vulnerabilities being created and highly spectacular risks that are now being bought by the company. And they don't even realise until it blows up one day.
 
 In Agile environments it's important to also provide relative numbers like:
-- issues vs velocity
-- issues vs storypoint
+
+* Risk issues vs velocity
+* Risk issues vs story points
+
 By analysing these numbers over time, the tipping point (where quality/security is no longer in focus) can become painfully clear.

content/2.Using-jira-workflow/For-management/Feedback-loops-are-key.md

@@ -0,0 +1,7 @@
+### Feedback loops are key
+
+An error often made is not spending enough energy and focus in finding the root cause of issues discovered/exploited.
+
+Incidents get identified by operational monitoring or incident response teams, are send to a security department, and after some analysing are directed to development teams as tickets. The development teams have no knowing of the original incident and cannot put the request in the right perspective. This can lead to sub optimal fixes with undesired side-effects.
+
+It is beneficial to include development teams in the root cause analysis from the start to make sure the best solution can be identified.

content/2.Using-jira-workflow/For-management/I-dont-know-the-security-status-of-a-website.md

@@ -18,5 +18,6 @@ This approach could scale.If I found problems, or if data was open, I could publ
 
 This reflects my first point:  if I can’t understand a company's level of security because they don't have to publish it, this should change. And if it does, it will change the market.
 
-Having a responsible disclosure program or participating in a bug bounty program can also act as a quality indicatior.
-(Remark: I created an additional section for this topic)
+Having a responsible disclosure program or public bug bounty program is also as strong quality and security indicator.
+
+In fact, a company that doesn't have an public bug bounty program is basically advertising to the world the fact that they don't have an AppSec team.

content/2.Using-jira-workflow/For-management/Lack-of-action-is-a-risk.md

@@ -1,8 +1,3 @@
 ### Lack of action is a risk
 
 * lack of time to perform 'root cause analysis' or lack of understanding of what cause the problem is a valid risk in itself
-
-### Feedback loops are key
-An error often made is not using the full potential in a company to find the root cause. Incidents get identified by operational monitoring or incident response teams, are send to a security department, and after some analysing are directed to development teams as tickets. The development teams have no knowing of the original incident and cannot put the request in the right perspective. This can lead to sub optimal fixes with undesired side-effects. 
-
-It is beneficial to include development teams in the root cause analysis from the start to make sure the best solution can be identified.

content/2.Using-jira-workflow/For-management/OWASP-top-10-risk-methodology.md

@@ -1,7 +1,6 @@
 ### OWASP Top 10 Risk methodology
 
-- add details about Risk methodology that in included with the OWASP Top 10
-- mention other Risks methodologies
-
-- applying OWASP ASVS allows for a more risk based approach
-- OpenSAMM and BSI-MM can measure the maturity level of an organisation
+* add details about Risk methodology that in included with the OWASP Top 10
+* mention other Risks methodologies
+  * applying OWASP ASVS allows for a more risk based approach
+  * OpenSAMM and BSIMM can measure the maturity level of an organisation

content/2.Using-jira-workflow/For-management/Regular-hackathons.md

@@ -1,8 +1,13 @@
 ### Regular Hackathons
 
-* used to find issues and look at new featutes
+* used to find issues and look at new features
 * every Friday or Monday afternoon (ideally with some beers and pizza)
   * ideally this would happen every week, if not every 2,3 or 4 weeks
   * what is important is to have movement
-* fits well into 10% of research time that devs should have
-* inviting external persons (like e.g. pentesters that regulary test the applications) have the benefit of providing new insights
+* fits well into 10% of research time that developers should have
+* inviting external persons (like e.g. pen-testers that regularly test the applications) have the benefit of providing new insights
+  * this is also one of the best ways to learn    
+    * try to do something and then see a more experienced and knowledgeable person being able to do it
+    * see that is the workflow and strategies used by them (to discover and exploit the issue)
+* organising red and blue teams (attacker and defenders) can also be very effective
+  * these are much are harder to organise, with a lot more preparation needed

content/2.Using-jira-workflow/For-management/Relationship-with-existing-standards.md

@@ -1,10 +1,10 @@
 ### Relationship with existing standards
 
 * Mention how this maps to PCI DSS , HIPAA and other standards
-  * basically a lot of this will break them
+  * most of companies will fail these standards when their existing 'real' RISKs are correctly identified and mapped (which is why there is a big difference between being 'compliant' and being 'secure')
 
-What is 'this' and 'them' in this context?
+More and more external regulatory bodies and laws require some level of proof about the implemented security controls.
 
-Fact is that more and more external regulatory bodies and laws require some level of proof about the implemented security controls. To prevent unnecessary delays or fines, these requirements should be embedded in the process in the form of regular scans, embedded controls (e.g. in the default infrastrucure), or in user stories.
+To prevent unnecessary delays or fines, these requirements need to be embedded in the process in the form of regular scans, embedded controls (e.g. in the default infrastructure), or in user stories.
 
 For example in DevOps environments all requirements related to OS hardening should be present in the default container and not be something that development teams need to think about.

content/2.Using-jira-workflow/For-management/Responsible-disclosure.md

@@ -0,0 +1,13 @@
+### Responsible disclosure
+
+Having a responsible disclosure process and/or participating in programs like HackerOne or Bugcrowd have several advantages:
+
+* it shows a level of confidence to the customers
+* it provides additional testing cycles
+* it sends a message that they have an AppSec program
+
+
+#### JIRA workflow for bug bounty's submissions
+
+* add diagram (from XYZ)
+  * real world example of using an JIRA workflow to manage submissions received 

content/2.Using-jira-workflow/For-management/Third-party-components-and-outsourcing.md

@@ -10,6 +10,12 @@
   * see OWASP Legal project for an idea of AppSec clauses to include in outsourcing contracts.
 * copyright infringes will become more of a problem in the future; this can be hard to identify in 3rd party components
 
-Notable tools:
-- OWASP Dependency checker can identify vulnerable components in use
-- several commercial tools exist that can identify copyright infringements in components
+#### Tools to help manage dependencies
+
+* OWASP Dependency checker can identify vulnerable components in use
+* several commercial tools exist that can identify copyright infringements in components
+  * Veracode has it
+  * Sourceclear
+  * Sonar (check which version)  
+  * nsp node security
+  * ... add more (see [13 tools for checking the security risk of open-source dependencies](http://techbeacon.com/13-tools-checking-security-risk-open-source-dependencies-0))

content/2.Using-jira-workflow/For-management/Using-logs-to-detect-risks-exploitation.md

@@ -7,5 +7,9 @@
   * this one of the reasons why a suite of Tests needs to be created that run against live servers
   * not only those Tests will confirm the current status of those issues (across the multiple environment), they will provide the NOC (Network Operations Centre) case studies of that they should be detecting
 
-### beware of the security myth
-* often no special software or expertise is needed to identify basic potential bad behaviour. For example if someone is accessing 20 non-existing pages per second for several minutes, it is most likely someone bruteforcing the application. This can easily be identified by monitoring for 404 and 403 errors per IP adress over time.
+#### beware of the security myth
+
+* often no special software or expertise is needed to identify basic potential bad behaviour.
+* usually companies already have all the tools and technology needed in house (prob is making them work in the company's reality)
+* for example if someone is accessing 20 non-existing pages per second for several minutes, it is most likely someone brute-forcing the application.
+  * This can easily be identified by monitoring for 404 and 403 errors per IP address over time.