The goal here is to leverage Jira flexibility to augment the representation not only of software "bugs" but to put in place a coherent and consistent representation of vulnerability and risk management.
This big goal can be divided into a more detailed description:
Jira is for many companies the tool of choice for development, whether they use "agile" methodologies or a "waterfall" approach. It is always more used in bigger organization for higher management functions and also business intelligence tooling and reporting are built on top of it.
Jira happens not only to be a de-facto standard tool for many development teams, but also to have a tremendous degree of flexibility and customizations capabilities. Put in practice this means custom issue types (other than task/story/bug etc.) with also the possibility to customize internal issue fields, custom relations types (or links) among issues, and great workflows. Of course, with great flexibility comes also the threat of misalignment from corporate standards and to have an over-complicated "schema" that costs too much time to maintain aligned.
Vulnerability and risk management doesn't come for free. It is not only a "tool" issue. This becomes a tool that facilitates the implementation of a strategy of managing security and risk that, at a higher level, requires training, long term vision and organization (top-down) commitment. This is also a transformation program that starts with the agreement among people on a set of ideas and by using a common language. Without that, a tool (at least this tool) will be a sterile one.
The first idea to "incept" is that the concept of "bug" (or defect) should be divided into more parts with a "divide and conquer" approach ... or at least "divide to see" what happens to the system!
This deeply relates to the definition of Terms (or semantics without even a term...we'll see why) and their relations, sometimes called thesaurus.
Many questions remain: How to represent those concepts in Jira? where to start? How to gain acceptance by teams? and others... Based on my experience too much too soon could be counter productive. Ambition is good, also in risk management, but pretending too much from teams before they see the value of those activities for their development could produce an adversarial reaction: "do this for me!". They need to see the value for their role too, then they will push it forward for you!
Here is represented one such approach base on the maturity level of implementation:
Jira Vulnerability-Risk-Controls "schemas" examples:
This big goal can be divided into a more detailed description:
- Defined top down and used bottom-up: single vulnerability and threats contribute con the organization's risk quantification, also directly from the technical source of truth, the engineers developing and maintaining the software system itself.
- Integrated with Threat Modeling, Penetration testing, development cycle(s), incident management... in a native/common manner.
- Non disrupting the common use of Jira by dev teams (standard schema). This would produce a push-back by most teams to the change proposal...
Jira is for many companies the tool of choice for development, whether they use "agile" methodologies or a "waterfall" approach. It is always more used in bigger organization for higher management functions and also business intelligence tooling and reporting are built on top of it.
Jira happens not only to be a de-facto standard tool for many development teams, but also to have a tremendous degree of flexibility and customizations capabilities. Put in practice this means custom issue types (other than task/story/bug etc.) with also the possibility to customize internal issue fields, custom relations types (or links) among issues, and great workflows. Of course, with great flexibility comes also the threat of misalignment from corporate standards and to have an over-complicated "schema" that costs too much time to maintain aligned.
Vulnerability and risk management doesn't come for free. It is not only a "tool" issue. This becomes a tool that facilitates the implementation of a strategy of managing security and risk that, at a higher level, requires training, long term vision and organization (top-down) commitment. This is also a transformation program that starts with the agreement among people on a set of ideas and by using a common language. Without that, a tool (at least this tool) will be a sterile one.
The first idea to "incept" is that the concept of "bug" (or defect) should be divided into more parts with a "divide and conquer" approach ... or at least "divide to see" what happens to the system!
This deeply relates to the definition of Terms (or semantics without even a term...we'll see why) and their relations, sometimes called thesaurus.
Many questions remain: How to represent those concepts in Jira? where to start? How to gain acceptance by teams? and others... Based on my experience too much too soon could be counter productive. Ambition is good, also in risk management, but pretending too much from teams before they see the value of those activities for their development could produce an adversarial reaction: "do this for me!". They need to see the value for their role too, then they will push it forward for you!
Here is represented one such approach base on the maturity level of implementation:
 |
from: https://2018.open-security-summit.org/
|
Comments
Post a Comment