Topics

[ONAP Helpdesk #67450] Jira board for Vulnerability Management

Jessica Wagantall via RT <onap-helpdesk@...>
 

Hi Steve

I'm still reviewing this workflow that you are proposing.
I wanted to give my opinion from what I know JIRA can do, but maybe is a good idea
to include Kenny's and any other JIRA user's opinion to see what they think too.

Let me know if my comments help you:

1. Anyone can submit a vulnerability JIRA (with or without a LF ID)
(maybe we need a web front end??)
Currently only people with LFID can create a JIRA ticket in jira.onap.org.
Opening the permissions to anonymous users here can cause a little bit of issues
around other JIRA projects. We can talk more about this if you want.


2. It supports default settings where the Vulnerability management
sub-committee members are the only ones that have the right to view
and access all the included Jiras
With a bit of work, I think we can achieve this via group permissions.


3. The vulnerability management sub-committee receives a notification
that there is a new jira, but without the details
I think only the watchers of a particular JIRA could receive email notifications
in this case. Adding people to the watchers list is still done pretty manually though.
Also, currently there is no way to add groups as a watcher, only individuals.
Not sure how this will affect what you envision.


4. It is possible to extend the security settings in a per JIRA basis
and a per individual basis to include access for selected individuals
that are required to solve the identified vulnerability.
Again, I think this can be done via group permissions, but can be a little bit tricky.

5. Finally, it should be possible to move the access restrictions and
move the JIRA (when completed) to the appropriate project jira.
Not sure I understood this one. Do you mean moving from one JIRA project to another
as part of a workflow?

In general, if we use JIRA for this matter it will probably have to have its own
workflow since the current workflow used by all other projects is very specific.

Thanks!
Jess

On Tue Jan 22 04:29:22 2019, stephen.terrill@... wrote:
Hi Jess, All,


We are looking at the improving the work regarding the handling of
received ONAP vulnerabilities. For that reason we are exploring the
possibility to have a jira board for this. We have tried to capture
the motivation and requirements below and we were wondering whether
this was feasible using the JIRA established for ONAP with a separate
project board? This request is to undersetand the feasibility.



Baseline:

- There is a vulnerability management sub-committee in place (though
membership could do with a refresh, and the update agreed with the
TSC).

- we have vulnerability management procedues, though these are based
on email input.



In order to secure the communication for vulnerabilities, and having a
secure email approach is challenging, the ideas was to explore a
ticketing systems with the following requirements.



A Jira board where:

1. Anyone can submit a vulnerability JIRA (with or without a LF ID)
(maybe we need a web front end??)

2. It supports default settings where the Vulnerability management
sub-committee members are the only ones that have the right to view
and access all the included Jiras

3. The vulnerability management sub-committee receives a notification
that there is a new jira, but without the details

4. It is possible to extend the security settings in a per JIRA basis
and a per individual basis to include access for selected individuals
that are required to solve the identified vulnerability.

5. Finally, it should be possible to move the access restrictions and
move the JIRA (when completed) to the appropriate project jira.


BR,

Steve

Krzysztof Opasiak
 

On 23.01.2019 01:41, Jessica Wagantall via RT wrote:
Hi Steve

I'm still reviewing this workflow that you are proposing.
I wanted to give my opinion from what I know JIRA can do, but maybe is a good idea
to include Kenny's and any other JIRA user's opinion to see what they think too.

Let me know if my comments help you:

1. Anyone can submit a vulnerability JIRA (with or without a LF ID)
(maybe we need a web front end??)
Currently only people with LFID can create a JIRA ticket in jira.onap.org.
Opening the permissions to anonymous users here can cause a little bit of issues
around other JIRA projects. We can talk more about this if you want.
Couldn't we modify permission for only one project? Like
everyone is able to create a ticket in "Vulnerabilities" project
(possibly after filling captcha to avoid spam) but in other projects we
require LFID?



2. It supports default settings where the Vulnerability management
sub-committee members are the only ones that have the right to view
and access all the included Jiras
With a bit of work, I think we can achieve this via group permissions.
Maybe I'll clarify requirement a little bit to make sure that it's possible:
1. All the issues should be visible for Vulnerability management
sub-committee
2. Particular issue should be visible for creator and Vulnerability
management sub-committee
3. People outside of Vulnerability management sub-committee should be
able to create issues in this project.



3. The vulnerability management sub-committee receives a notification
that there is a new jira, but without the details
I think only the watchers of a particular JIRA could receive email notifications
in this case. Adding people to the watchers list is still done pretty manually though.
Also, currently there is no way to add groups as a watcher, only individuals.
Not sure how this will affect what you envision.
Yeah but the problem here is that by default jira sends the content of
issue via email which is considered insecure for vulnerabilities. So we
would like to get notifications but without the content



4. It is possible to extend the security settings in a per JIRA basis
and a per individual basis to include access for selected individuals
that are required to solve the identified vulnerability.
Again, I think this can be done via group permissions, but can be a little bit tricky.
Can we modify permissions for particular issue or only for whole project?


5. Finally, it should be possible to move the access restrictions and
move the JIRA (when completed) to the appropriate project jira.
Not sure I understood this one. Do you mean moving from one JIRA project to another
as part of a workflow?

In general, if we use JIRA for this matter it will probably have to have its own
workflow since the current workflow used by all other projects is very specific.
So what we would like to get is a timeline like this:

1. Someone creates ticket
<now it's visible for vulnerability subcom and author>
2. Vulnerability subcom decides to X Y to access this issue
<now it's visible for vulnerability subcom, author and X Y, but only
this particular issue not others>
3. X Y fix the bug
<no changes in visibility>
4. Coordinated disclosure day comes. Vulnerability subcom publish the issue
<now it's visible for everyone>

Best regards,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Krzysztof Opasiak via RT <onap-helpdesk@...>
 

On 23.01.2019 01:41, Jessica Wagantall via RT wrote:
Hi Steve

I'm still reviewing this workflow that you are proposing.
I wanted to give my opinion from what I know JIRA can do, but maybe is a good idea
to include Kenny's and any other JIRA user's opinion to see what they think too.

Let me know if my comments help you:

1. Anyone can submit a vulnerability JIRA (with or without a LF ID)
(maybe we need a web front end??)
Currently only people with LFID can create a JIRA ticket in jira.onap.org.
Opening the permissions to anonymous users here can cause a little bit of issues
around other JIRA projects. We can talk more about this if you want.
Couldn't we modify permission for only one project? Like
everyone is able to create a ticket in "Vulnerabilities" project
(possibly after filling captcha to avoid spam) but in other projects we
require LFID?



2. It supports default settings where the Vulnerability management
sub-committee members are the only ones that have the right to view
and access all the included Jiras
With a bit of work, I think we can achieve this via group permissions.
Maybe I'll clarify requirement a little bit to make sure that it's possible:
1. All the issues should be visible for Vulnerability management
sub-committee
2. Particular issue should be visible for creator and Vulnerability
management sub-committee
3. People outside of Vulnerability management sub-committee should be
able to create issues in this project.



3. The vulnerability management sub-committee receives a notification
that there is a new jira, but without the details
I think only the watchers of a particular JIRA could receive email notifications
in this case. Adding people to the watchers list is still done pretty manually though.
Also, currently there is no way to add groups as a watcher, only individuals.
Not sure how this will affect what you envision.
Yeah but the problem here is that by default jira sends the content of
issue via email which is considered insecure for vulnerabilities. So we
would like to get notifications but without the content



4. It is possible to extend the security settings in a per JIRA basis
and a per individual basis to include access for selected individuals
that are required to solve the identified vulnerability.
Again, I think this can be done via group permissions, but can be a little bit tricky.
Can we modify permissions for particular issue or only for whole project?


5. Finally, it should be possible to move the access restrictions and
move the JIRA (when completed) to the appropriate project jira.
Not sure I understood this one. Do you mean moving from one JIRA project to another
as part of a workflow?

In general, if we use JIRA for this matter it will probably have to have its own
workflow since the current workflow used by all other projects is very specific.
So what we would like to get is a timeline like this:

1. Someone creates ticket
<now it's visible for vulnerability subcom and author>
2. Vulnerability subcom decides to X Y to access this issue
<now it's visible for vulnerability subcom, author and X Y, but only
this particular issue not others>
3. X Y fix the bug
<no changes in visibility>
4. Coordinated disclosure day comes. Vulnerability subcom publish the issue
<now it's visible for everyone>

Best regards,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Pierre Close
 

Hi Krzysztof,

I think that when granting X Y access to a specific issue, we should be sure that X Y in turn are not able to share with other people that might be unauthorized to access the issue.

Additionally, when

3. X Y fix the bug
<no changes in visibility>

We need to be sure that X Y do not have the rights to change visibility.

Best regards,
Pierre

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On Behalf Of Krzysztof Opasiak via RT
Sent: Wednesday, January 23, 2019 17:53
To: stephen.terrill@...
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for Vulnerability Management



On 23.01.2019 01:41, Jessica Wagantall via RT wrote:
Hi Steve

I'm still reviewing this workflow that you are proposing.
I wanted to give my opinion from what I know JIRA can do, but maybe is
a good idea to include Kenny's and any other JIRA user's opinion to see what they think too.

Let me know if my comments help you:

1. Anyone can submit a vulnerability JIRA (with or without a LF ID)
(maybe we need a web front end??)
Currently only people with LFID can create a JIRA ticket in jira.onap.org.
Opening the permissions to anonymous users here can cause a little bit
of issues around other JIRA projects. We can talk more about this if you want.
Couldn't we modify permission for only one project? Like everyone is able to create a ticket in "Vulnerabilities" project (possibly after filling captcha to avoid spam) but in other projects we require LFID?



2. It supports default settings where the Vulnerability management
sub-committee members are the only ones that have the right to view
and access all the included Jiras
With a bit of work, I think we can achieve this via group permissions.
Maybe I'll clarify requirement a little bit to make sure that it's possible:
1. All the issues should be visible for Vulnerability management sub-committee 2. Particular issue should be visible for creator and Vulnerability management sub-committee 3. People outside of Vulnerability management sub-committee should be able to create issues in this project.



3. The vulnerability management sub-committee receives a notification
that there is a new jira, but without the details
I think only the watchers of a particular JIRA could receive email notifications
in this case. Adding people to the watchers list is still done pretty manually though.
Also, currently there is no way to add groups as a watcher, only individuals.
Not sure how this will affect what you envision.
Yeah but the problem here is that by default jira sends the content of
issue via email which is considered insecure for vulnerabilities. So we
would like to get notifications but without the content



4. It is possible to extend the security settings in a per JIRA basis
and a per individual basis to include access for selected individuals
that are required to solve the identified vulnerability.
Again, I think this can be done via group permissions, but can be a little bit tricky.
Can we modify permissions for particular issue or only for whole project?


5. Finally, it should be possible to move the access restrictions and
move the JIRA (when completed) to the appropriate project jira.
Not sure I understood this one. Do you mean moving from one JIRA project to another
as part of a workflow?

In general, if we use JIRA for this matter it will probably have to have its own
workflow since the current workflow used by all other projects is very specific.
So what we would like to get is a timeline like this:

1. Someone creates ticket
<now it's visible for vulnerability subcom and author>
2. Vulnerability subcom decides to X Y to access this issue
<now it's visible for vulnerability subcom, author and X Y, but only
this particular issue not others>
3. X Y fix the bug
<no changes in visibility>
4. Coordinated disclosure day comes. Vulnerability subcom publish the issue
<now it's visible for everyone>

Best regards,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Krzysztof Opasiak
 

On 23.01.2019 18:32, Pierre Close wrote:
Hi Krzysztof,

I think that when granting X Y access to a specific issue, we should be sure that X Y in turn are not able to share with other people that might be unauthorized to access the issue.
Hmm I'm no so sure about this because what to do if we add a PTL to the
issue and he or she would like to delegate fixing bug to other person?


Additionally, when

3. X Y fix the bug
<no changes in visibility>

We need to be sure that X Y do not have the rights to change visibility.
For this one I totally agree. Only vulnerabilities subcommittee should
have a right to make a disclosure.

Best regards,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Pierre Close
 

Hi Krzysztof,

Thanks for your comments, see mine inline below -- my apologies for bringing many additional questions on this topic

Best regards,
Pierre

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On Behalf Of Krzysztof Opasiak
Sent: Wednesday, January 23, 2019 18:38
To: Close, Pierre <pierre.close@...>
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for Vulnerability Management



On 23.01.2019 18:32, Pierre Close wrote:
Hi Krzysztof,

I think that when granting X Y access to a specific issue, we should be sure that X Y in turn are not able to share with other people that might be unauthorized to access the issue.
Hmm I'm no so sure about this because what to do if we add a PTL to the issue and he or she would like to delegate fixing bug to other person?

P: Indeed you are right. What about: if we give read access only to project devs (and nothing more), and rely on the PTL to update the status (that's more load on PTLs' shoulders, but more secure) -- would this be acceptable?
Now, that can also become tricky especially when several projects are impacted (like a common vulnerable dependency used by several projects) -- but it's a rather general issue (how would the vulnerabilities subcommittee know how many projects are really impacted? -- would this be tied to the scanning tool maybe?)


Additionally, when

3. X Y fix the bug
<no changes in visibility>

We need to be sure that X Y do not have the rights to change visibility.
For this one I totally agree. Only vulnerabilities subcommittee should have a right to make a disclosure.

Best regards,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Krzysztof Opasiak
 

Hi Pierre,

On 23.01.2019 18:51, Close, Pierre wrote:
Hi Krzysztof,

Thanks for your comments, see mine inline below -- my apologies for bringing many additional questions on this topic
No problem, that's the purpose of mailing list to ask and discuss with
people;)

On 23.01.2019 18:32, Pierre Close wrote:
Hi Krzysztof,

I think that when granting X Y access to a specific issue, we should be sure that X Y in turn are not able to share with other people that might be unauthorized to access the issue.
Hmm I'm no so sure about this because what to do if we add a PTL to the issue and he or she would like to delegate fixing bug to other person?
P: Indeed you are right. What about: if we give read access only to project devs (and nothing more), and rely on the PTL to update the status (that's more load on PTLs' shoulders, but more secure) -- would this be acceptable?
To be honest from my point of view the list of people who have access
should be big enough to fix the bug as soon as possible and not bigger;)

I think it was during SECCOM F2F when we discussed that every project
should have its "Security contact point". By default it's PTL but this
responsibility can be delegated to some dev.

So in a perfect situation we should add that person to every bug related
to that project and then he or she should decide if he or she is able to
fix this bug on his/her own or should delegate this to someone else. But
still I expect max 2 (security contact point + potential plumber) people
per project added to every issue. This is probably less than adding all
devs from project.

Now, that can also become tricky especially when several projects are impacted (like a common vulnerable dependency used by several projects) -- but it's a rather general issue (how would the vulnerabilities subcommittee know how many projects are really impacted? -- would this be tied to the scanning tool maybe?)
For that kind of issue we could add security contact points from all
projects and ask them to check if the project is vulnerable or not.
That's why it's good to have a single responsible person per project.

--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Jessica Wagantall via RT <onap-helpdesk@...>
 

Re adding Keong's email:
-----------------------------------


Hi Steve, Jess, Krzysztof, Pierre, et al,

From what I know of administering another JIRA and Confluence installation (that included differentiation between "external customers", "employee developers" and "managers" for the same reasons discussed in this thread), what you are asking for and proposing is all possible, however, it requires a number of configurations that the current ONAP JIRA and Confluence do not yet have setup (they are relying on defaults or single-all-inclusive configs), including:

- permission schemes
- notification schemes
- workflow schemes
- user groups membership
- user group permissions
- project roles

You will also need to consider the visibility of issues, comments, pages and fields, as experienced by different people with different permissions and roles. People with broader permissions / access can selectively make their comments, etc, available only to a restricted audience, but people with narrower permissions will not even know that such a thing is a choice.

If you want to do it selectively, then you can also assign permissions / access to individuals on a case-by-case basis, but this is usually too much maintenance overhead for most people to handle.

The schemes above do require some maintenance, but if done correctly, it simply boils down to assigning the user to the right group, which is a much simpler and more consistent method of control.


Keong

On Wed Jan 23 11:53:15 2019, k.opasiak@... wrote:


On 23.01.2019 01:41, Jessica Wagantall via RT wrote:
Hi Steve

I'm still reviewing this workflow that you are proposing.
I wanted to give my opinion from what I know JIRA can do, but maybe
is a good idea
to include Kenny's and any other JIRA user's opinion to see what they
think too.

Let me know if my comments help you:

1. Anyone can submit a vulnerability JIRA (with or without a LF ID)
(maybe we need a web front end??)
Currently only people with LFID can create a JIRA ticket in
jira.onap.org.
Opening the permissions to anonymous users here can cause a little
bit of issues
around other JIRA projects. We can talk more about this if you want.
Couldn't we modify permission for only one project? Like
everyone is able to create a ticket in "Vulnerabilities" project
(possibly after filling captcha to avoid spam) but in other projects
we
require LFID?



2. It supports default settings where the Vulnerability management
sub-committee members are the only ones that have the right to view
and access all the included Jiras
With a bit of work, I think we can achieve this via group
permissions.
Maybe I'll clarify requirement a little bit to make sure that it's
possible:
1. All the issues should be visible for Vulnerability management
sub-committee
2. Particular issue should be visible for creator and Vulnerability
management sub-committee
3. People outside of Vulnerability management sub-committee should be
able to create issues in this project.



3. The vulnerability management sub-committee receives a
notification
that there is a new jira, but without the details
I think only the watchers of a particular JIRA could receive email
notifications
in this case. Adding people to the watchers list is still done pretty
manually though.
Also, currently there is no way to add groups as a watcher, only
individuals.
Not sure how this will affect what you envision.
Yeah but the problem here is that by default jira sends the content of
issue via email which is considered insecure for vulnerabilities. So
we
would like to get notifications but without the content



4. It is possible to extend the security settings in a per JIRA
basis
and a per individual basis to include access for selected
individuals
that are required to solve the identified vulnerability.
Again, I think this can be done via group permissions, but can be a
little bit tricky.
Can we modify permissions for particular issue or only for whole
project?


5. Finally, it should be possible to move the access restrictions
and
move the JIRA (when completed) to the appropriate project jira.
Not sure I understood this one. Do you mean moving from one JIRA
project to another
as part of a workflow?

In general, if we use JIRA for this matter it will probably have to
have its own
workflow since the current workflow used by all other projects is
very specific.
So what we would like to get is a timeline like this:

1. Someone creates ticket
<now it's visible for vulnerability subcom and author>
2. Vulnerability subcom decides to X Y to access this issue
<now it's visible for vulnerability subcom, author and X Y, but only
this particular issue not others>
3. X Y fix the bug
<no changes in visibility>
4. Coordinated disclosure day comes. Vulnerability subcom publish the
issue
<now it's visible for everyone>

Best regards,

Jessica Wagantall via RT <onap-helpdesk@...>
 

Re adding Keong's email:
-----------------------------------


Hi Steve, Jess, Krzysztof, Pierre, et al,

From what I know of administering another JIRA and Confluence installation (that included differentiation between "external customers", "employee developers" and "managers" for the same reasons discussed in this thread), what you are asking for and proposing is all possible, however, it requires a number of configurations that the current ONAP JIRA and Confluence do not yet have setup (they are relying on defaults or single-all-inclusive configs), including:

- permission schemes
- notification schemes
- workflow schemes
- user groups membership
- user group permissions
- project roles

You will also need to consider the visibility of issues, comments, pages and fields, as experienced by different people with different permissions and roles. People with broader permissions / access can selectively make their comments, etc, available only to a restricted audience, but people with narrower permissions will not even know that such a thing is a choice.

If you want to do it selectively, then you can also assign permissions / access to individuals on a case-by-case basis, but this is usually too much maintenance overhead for most people to handle.

The schemes above do require some maintenance, but if done correctly, it simply boils down to assigning the user to the right group, which is a much simpler and more consistent method of control.


Keong

On Wed Jan 23 11:53:15 2019, k.opasiak@... wrote:


On 23.01.2019 01:41, Jessica Wagantall via RT wrote:
Hi Steve

I'm still reviewing this workflow that you are proposing.
I wanted to give my opinion from what I know JIRA can do, but maybe
is a good idea
to include Kenny's and any other JIRA user's opinion to see what they
think too.

Let me know if my comments help you:

1. Anyone can submit a vulnerability JIRA (with or without a LF ID)
(maybe we need a web front end??)
Currently only people with LFID can create a JIRA ticket in
jira.onap.org.
Opening the permissions to anonymous users here can cause a little
bit of issues
around other JIRA projects. We can talk more about this if you want.
Couldn't we modify permission for only one project? Like
everyone is able to create a ticket in "Vulnerabilities" project
(possibly after filling captcha to avoid spam) but in other projects
we
require LFID?



2. It supports default settings where the Vulnerability management
sub-committee members are the only ones that have the right to view
and access all the included Jiras
With a bit of work, I think we can achieve this via group
permissions.
Maybe I'll clarify requirement a little bit to make sure that it's
possible:
1. All the issues should be visible for Vulnerability management
sub-committee
2. Particular issue should be visible for creator and Vulnerability
management sub-committee
3. People outside of Vulnerability management sub-committee should be
able to create issues in this project.



3. The vulnerability management sub-committee receives a
notification
that there is a new jira, but without the details
I think only the watchers of a particular JIRA could receive email
notifications
in this case. Adding people to the watchers list is still done pretty
manually though.
Also, currently there is no way to add groups as a watcher, only
individuals.
Not sure how this will affect what you envision.
Yeah but the problem here is that by default jira sends the content of
issue via email which is considered insecure for vulnerabilities. So
we
would like to get notifications but without the content



4. It is possible to extend the security settings in a per JIRA
basis
and a per individual basis to include access for selected
individuals
that are required to solve the identified vulnerability.
Again, I think this can be done via group permissions, but can be a
little bit tricky.
Can we modify permissions for particular issue or only for whole
project?


5. Finally, it should be possible to move the access restrictions
and
move the JIRA (when completed) to the appropriate project jira.
Not sure I understood this one. Do you mean moving from one JIRA
project to another
as part of a workflow?

In general, if we use JIRA for this matter it will probably have to
have its own
workflow since the current workflow used by all other projects is
very specific.
So what we would like to get is a timeline like this:

1. Someone creates ticket
<now it's visible for vulnerability subcom and author>
2. Vulnerability subcom decides to X Y to access this issue
<now it's visible for vulnerability subcom, author and X Y, but only
this particular issue not others>
3. X Y fix the bug
<no changes in visibility>
4. Coordinated disclosure day comes. Vulnerability subcom publish the
issue
<now it's visible for everyone>

Best regards,

Pierre Close
 

Hi Krzysztof,

Sorry for the delay, I was off yesterday.

Thanks a lot for your reply.

About your comment:

So in a perfect situation we should add that person to every bug related to that project and then he or she should decide if he or she is able to fix this bug on his/her own or should delegate this to someone else. But still I expect max 2 (security contact point + potential plumber) people per project added to every issue. This is probably less than adding all devs from project.

P: I agree with your point, 2 seems a good catch (especially when one is on vacation and the other can take over).

And about

To be honest from my point of view the list of people who have access should be big enough to fix the bug as soon as possible and not bigger;)

P: +1

> Now, that can also become tricky especially when several projects are
> impacted (like a common vulnerable dependency used by several
> projects) -- but it's a rather general issue (how would the
> vulnerabilities subcommittee know how many projects are really
> impacted? -- would this be tied to the scanning tool maybe?)

For that kind of issue we could add security contact points from all projects and ask them to check if the project is vulnerable or not.
That's why it's good to have a single responsible person per project.

P: agreed as well, makes sense.

Thanks again and best regards,
Pierre

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On Behalf Of Krzysztof Opasiak
Sent: Wednesday, January 23, 2019 21:43
To: Close, Pierre <pierre.close@...>
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for Vulnerability Management

Hi Pierre,

On 23.01.2019 18:51, Close, Pierre wrote:
Hi Krzysztof,

Thanks for your comments, see mine inline below -- my apologies for
bringing many additional questions on this topic
No problem, that's the purpose of mailing list to ask and discuss with
people;)

On 23.01.2019 18:32, Pierre Close wrote:
Hi Krzysztof,

I think that when granting X Y access to a specific issue, we should be sure that X Y in turn are not able to share with other people that might be unauthorized to access the issue.
Hmm I'm no so sure about this because what to do if we add a PTL to the issue and he or she would like to delegate fixing bug to other person?
P: Indeed you are right. What about: if we give read access only to project devs (and nothing more), and rely on the PTL to update the status (that's more load on PTLs' shoulders, but more secure) -- would this be acceptable?
To be honest from my point of view the list of people who have access should be big enough to fix the bug as soon as possible and not bigger;)

I think it was during SECCOM F2F when we discussed that every project should have its "Security contact point". By default it's PTL but this responsibility can be delegated to some dev.

So in a perfect situation we should add that person to every bug related to that project and then he or she should decide if he or she is able to fix this bug on his/her own or should delegate this to someone else. But still I expect max 2 (security contact point + potential plumber) people per project added to every issue. This is probably less than adding all devs from project.

Now, that can also become tricky especially when several projects are
impacted (like a common vulnerable dependency used by several
projects) -- but it's a rather general issue (how would the
vulnerabilities subcommittee know how many projects are really
impacted? -- would this be tied to the scanning tool maybe?)
For that kind of issue we could add security contact points from all projects and ask them to check if the project is vulnerable or not.
That's why it's good to have a single responsible person per project.

--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Pierre Close
 

Thanks Jess and Keong for your inputs and feedback!

Best regards,
Pierre

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On Behalf Of Jessica Wagantall via RT
Sent: Thursday, January 24, 2019 01:39
Cc: onap-seccom@...; k.opasiak@...; keong.lim@...
Subject: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for Vulnerability Management

Re adding Keong's email:
-----------------------------------


Hi Steve, Jess, Krzysztof, Pierre, et al,

From what I know of administering another JIRA and Confluence installation (that included differentiation between "external customers", "employee developers" and "managers" for the same reasons discussed in this thread), what you are asking for and proposing is all possible, however, it requires a number of configurations that the current ONAP JIRA and Confluence do not yet have setup (they are relying on defaults or single-all-inclusive configs), including:

- permission schemes
- notification schemes
- workflow schemes
- user groups membership
- user group permissions
- project roles

You will also need to consider the visibility of issues, comments, pages and fields, as experienced by different people with different permissions and roles. People with broader permissions / access can selectively make their comments, etc, available only to a restricted audience, but people with narrower permissions will not even know that such a thing is a choice.

If you want to do it selectively, then you can also assign permissions / access to individuals on a case-by-case basis, but this is usually too much maintenance overhead for most people to handle.

The schemes above do require some maintenance, but if done correctly, it simply boils down to assigning the user to the right group, which is a much simpler and more consistent method of control.


Keong


On Wed Jan 23 11:53:15 2019, k.opasiak@... wrote:


On 23.01.2019 01:41, Jessica Wagantall via RT wrote:
Hi Steve

I'm still reviewing this workflow that you are proposing.
I wanted to give my opinion from what I know JIRA can do, but maybe
is a good idea to include Kenny's and any other JIRA user's opinion
to see what they think too.

Let me know if my comments help you:

1. Anyone can submit a vulnerability JIRA (with or without a LF ID)
(maybe we need a web front end??)
Currently only people with LFID can create a JIRA ticket in
jira.onap.org.
Opening the permissions to anonymous users here can cause a little
bit of issues around other JIRA projects. We can talk more about
this if you want.
Couldn't we modify permission for only one project? Like everyone is
able to create a ticket in "Vulnerabilities" project (possibly after
filling captcha to avoid spam) but in other projects we require LFID?



2. It supports default settings where the Vulnerability management
sub-committee members are the only ones that have the right to view
and access all the included Jiras
With a bit of work, I think we can achieve this via group
permissions.
Maybe I'll clarify requirement a little bit to make sure that it's
possible:
1. All the issues should be visible for Vulnerability management
sub-committee 2. Particular issue should be visible for creator and
Vulnerability management sub-committee 3. People outside of
Vulnerability management sub-committee should be able to create issues
in this project.



3. The vulnerability management sub-committee receives a
notification that there is a new jira, but without the details
I think only the watchers of a particular JIRA could receive email
notifications in this case. Adding people to the watchers list is
still done pretty manually though.
Also, currently there is no way to add groups as a watcher, only
individuals.
Not sure how this will affect what you envision.
Yeah but the problem here is that by default jira sends the content of
issue via email which is considered insecure for vulnerabilities. So
we would like to get notifications but without the content



4. It is possible to extend the security settings in a per JIRA
basis and a per individual basis to include access for selected
individuals that are required to solve the identified
vulnerability.
Again, I think this can be done via group permissions, but can be a
little bit tricky.
Can we modify permissions for particular issue or only for whole
project?


5. Finally, it should be possible to move the access restrictions
and move the JIRA (when completed) to the appropriate project jira.
Not sure I understood this one. Do you mean moving from one JIRA
project to another as part of a workflow?

In general, if we use JIRA for this matter it will probably have to
have its own workflow since the current workflow used by all other
projects is very specific.
So what we would like to get is a timeline like this:

1. Someone creates ticket
<now it's visible for vulnerability subcom and author> 2.
Vulnerability subcom decides to X Y to access this issue <now it's
visible for vulnerability subcom, author and X Y, but only this
particular issue not others> 3. X Y fix the bug <no changes in
visibility> 4. Coordinated disclosure day comes. Vulnerability subcom
publish the issue <now it's visible for everyone>

Best regards,

Close, Pierre via RT <onap-helpdesk@...>
 

Thanks Jess and Keong for your inputs and feedback!

Best regards,
Pierre

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On Behalf Of Jessica Wagantall via RT
Sent: Thursday, January 24, 2019 01:39
Cc: onap-seccom@...; k.opasiak@...; keong.lim@...
Subject: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for Vulnerability Management

Re adding Keong's email:
-----------------------------------


Hi Steve, Jess, Krzysztof, Pierre, et al,

From what I know of administering another JIRA and Confluence installation (that included differentiation between "external customers", "employee developers" and "managers" for the same reasons discussed in this thread), what you are asking for and proposing is all possible, however, it requires a number of configurations that the current ONAP JIRA and Confluence do not yet have setup (they are relying on defaults or single-all-inclusive configs), including:

- permission schemes
- notification schemes
- workflow schemes
- user groups membership
- user group permissions
- project roles

You will also need to consider the visibility of issues, comments, pages and fields, as experienced by different people with different permissions and roles. People with broader permissions / access can selectively make their comments, etc, available only to a restricted audience, but people with narrower permissions will not even know that such a thing is a choice.

If you want to do it selectively, then you can also assign permissions / access to individuals on a case-by-case basis, but this is usually too much maintenance overhead for most people to handle.

The schemes above do require some maintenance, but if done correctly, it simply boils down to assigning the user to the right group, which is a much simpler and more consistent method of control.


Keong


On Wed Jan 23 11:53:15 2019, k.opasiak@... wrote:


On 23.01.2019 01:41, Jessica Wagantall via RT wrote:
Hi Steve

I'm still reviewing this workflow that you are proposing.
I wanted to give my opinion from what I know JIRA can do, but maybe
is a good idea to include Kenny's and any other JIRA user's opinion
to see what they think too.

Let me know if my comments help you:

1. Anyone can submit a vulnerability JIRA (with or without a LF ID)
(maybe we need a web front end??)
Currently only people with LFID can create a JIRA ticket in
jira.onap.org.
Opening the permissions to anonymous users here can cause a little
bit of issues around other JIRA projects. We can talk more about
this if you want.
Couldn't we modify permission for only one project? Like everyone is
able to create a ticket in "Vulnerabilities" project (possibly after
filling captcha to avoid spam) but in other projects we require LFID?



2. It supports default settings where the Vulnerability management
sub-committee members are the only ones that have the right to view
and access all the included Jiras
With a bit of work, I think we can achieve this via group
permissions.
Maybe I'll clarify requirement a little bit to make sure that it's
possible:
1. All the issues should be visible for Vulnerability management
sub-committee 2. Particular issue should be visible for creator and
Vulnerability management sub-committee 3. People outside of
Vulnerability management sub-committee should be able to create issues
in this project.



3. The vulnerability management sub-committee receives a
notification that there is a new jira, but without the details
I think only the watchers of a particular JIRA could receive email
notifications in this case. Adding people to the watchers list is
still done pretty manually though.
Also, currently there is no way to add groups as a watcher, only
individuals.
Not sure how this will affect what you envision.
Yeah but the problem here is that by default jira sends the content of
issue via email which is considered insecure for vulnerabilities. So
we would like to get notifications but without the content



4. It is possible to extend the security settings in a per JIRA
basis and a per individual basis to include access for selected
individuals that are required to solve the identified
vulnerability.
Again, I think this can be done via group permissions, but can be a
little bit tricky.
Can we modify permissions for particular issue or only for whole
project?


5. Finally, it should be possible to move the access restrictions
and move the JIRA (when completed) to the appropriate project jira.
Not sure I understood this one. Do you mean moving from one JIRA
project to another as part of a workflow?

In general, if we use JIRA for this matter it will probably have to
have its own workflow since the current workflow used by all other
projects is very specific.
So what we would like to get is a timeline like this:

1. Someone creates ticket
<now it's visible for vulnerability subcom and author> 2.
Vulnerability subcom decides to X Y to access this issue <now it's
visible for vulnerability subcom, author and X Y, but only this
particular issue not others> 3. X Y fix the bug <no changes in
visibility> 4. Coordinated disclosure day comes. Vulnerability subcom
publish the issue <now it's visible for everyone>

Best regards,

Jessica Wagantall via RT <onap-helpdesk@...>
 

Dear Krzysztof,

Thanks for your previous comments.

In general, I am mostly worried about 2 of these requests that might not be able to be possible:
- The empty notifications. The content of the email in the notifications is not configurable
and even if we manage a way to hack it it will affect all projects and not just this one.
If we would have slack, we could potentially manage to send notifications there with a different
format, I think. Not much we can do with the built in notifications in Jira.
- We cannot open permissions outside LF registered users for just 1 project. Opening JIRA for
non LF registered users cannot happen in this JIRA instance.

Everything else could be a matter of having SECOMM under its own project workflow.

Let me know what you think about these 2 blockers

Thanks!
Jess

On Wed Jan 23 11:53:15 2019, k.opasiak@... wrote:


On 23.01.2019 01:41, Jessica Wagantall via RT wrote:
Hi Steve

I'm still reviewing this workflow that you are proposing.
I wanted to give my opinion from what I know JIRA can do, but maybe
is a good idea
to include Kenny's and any other JIRA user's opinion to see what they
think too.

Let me know if my comments help you:

1. Anyone can submit a vulnerability JIRA (with or without a LF ID)
(maybe we need a web front end??)
Currently only people with LFID can create a JIRA ticket in
jira.onap.org.
Opening the permissions to anonymous users here can cause a little
bit of issues
around other JIRA projects. We can talk more about this if you want.
Couldn't we modify permission for only one project? Like
everyone is able to create a ticket in "Vulnerabilities" project
(possibly after filling captcha to avoid spam) but in other projects
we
require LFID?



2. It supports default settings where the Vulnerability management
sub-committee members are the only ones that have the right to view
and access all the included Jiras
With a bit of work, I think we can achieve this via group
permissions.
Maybe I'll clarify requirement a little bit to make sure that it's
possible:
1. All the issues should be visible for Vulnerability management
sub-committee
2. Particular issue should be visible for creator and Vulnerability
management sub-committee
3. People outside of Vulnerability management sub-committee should be
able to create issues in this project.



3. The vulnerability management sub-committee receives a
notification
that there is a new jira, but without the details
I think only the watchers of a particular JIRA could receive email
notifications
in this case. Adding people to the watchers list is still done pretty
manually though.
Also, currently there is no way to add groups as a watcher, only
individuals.
Not sure how this will affect what you envision.
Yeah but the problem here is that by default jira sends the content of
issue via email which is considered insecure for vulnerabilities. So
we
would like to get notifications but without the content



4. It is possible to extend the security settings in a per JIRA
basis
and a per individual basis to include access for selected
individuals
that are required to solve the identified vulnerability.
Again, I think this can be done via group permissions, but can be a
little bit tricky.
Can we modify permissions for particular issue or only for whole
project?


5. Finally, it should be possible to move the access restrictions
and
move the JIRA (when completed) to the appropriate project jira.
Not sure I understood this one. Do you mean moving from one JIRA
project to another
as part of a workflow?

In general, if we use JIRA for this matter it will probably have to
have its own
workflow since the current workflow used by all other projects is
very specific.
So what we would like to get is a timeline like this:

1. Someone creates ticket
<now it's visible for vulnerability subcom and author>
2. Vulnerability subcom decides to X Y to access this issue
<now it's visible for vulnerability subcom, author and X Y, but only
this particular issue not others>
3. X Y fix the bug
<no changes in visibility>
4. Coordinated disclosure day comes. Vulnerability subcom publish the
issue
<now it's visible for everyone>

Best regards,

Jessica Wagantall via RT <onap-helpdesk@...>
 

Dear Krzysztof,

Thanks for your previous comments.

In general, I am mostly worried about 2 of these requests that might not be able to be possible:
- The empty notifications. The content of the email in the notifications is not configurable
and even if we manage a way to hack it it will affect all projects and not just this one.
If we would have slack, we could potentially manage to send notifications there with a different
format, I think. Not much we can do with the built in notifications in Jira.
- We cannot open permissions outside LF registered users for just 1 project. Opening JIRA for
non LF registered users cannot happen in this JIRA instance.

Everything else could be a matter of having SECOMM under its own project workflow.

Let me know what you think about these 2 blockers

Thanks!
Jess

On Wed Jan 23 11:53:15 2019, k.opasiak@... wrote:


On 23.01.2019 01:41, Jessica Wagantall via RT wrote:
Hi Steve

I'm still reviewing this workflow that you are proposing.
I wanted to give my opinion from what I know JIRA can do, but maybe
is a good idea
to include Kenny's and any other JIRA user's opinion to see what they
think too.

Let me know if my comments help you:

1. Anyone can submit a vulnerability JIRA (with or without a LF ID)
(maybe we need a web front end??)
Currently only people with LFID can create a JIRA ticket in
jira.onap.org.
Opening the permissions to anonymous users here can cause a little
bit of issues
around other JIRA projects. We can talk more about this if you want.
Couldn't we modify permission for only one project? Like
everyone is able to create a ticket in "Vulnerabilities" project
(possibly after filling captcha to avoid spam) but in other projects
we
require LFID?



2. It supports default settings where the Vulnerability management
sub-committee members are the only ones that have the right to view
and access all the included Jiras
With a bit of work, I think we can achieve this via group
permissions.
Maybe I'll clarify requirement a little bit to make sure that it's
possible:
1. All the issues should be visible for Vulnerability management
sub-committee
2. Particular issue should be visible for creator and Vulnerability
management sub-committee
3. People outside of Vulnerability management sub-committee should be
able to create issues in this project.



3. The vulnerability management sub-committee receives a
notification
that there is a new jira, but without the details
I think only the watchers of a particular JIRA could receive email
notifications
in this case. Adding people to the watchers list is still done pretty
manually though.
Also, currently there is no way to add groups as a watcher, only
individuals.
Not sure how this will affect what you envision.
Yeah but the problem here is that by default jira sends the content of
issue via email which is considered insecure for vulnerabilities. So
we
would like to get notifications but without the content



4. It is possible to extend the security settings in a per JIRA
basis
and a per individual basis to include access for selected
individuals
that are required to solve the identified vulnerability.
Again, I think this can be done via group permissions, but can be a
little bit tricky.
Can we modify permissions for particular issue or only for whole
project?


5. Finally, it should be possible to move the access restrictions
and
move the JIRA (when completed) to the appropriate project jira.
Not sure I understood this one. Do you mean moving from one JIRA
project to another
as part of a workflow?

In general, if we use JIRA for this matter it will probably have to
have its own
workflow since the current workflow used by all other projects is
very specific.
So what we would like to get is a timeline like this:

1. Someone creates ticket
<now it's visible for vulnerability subcom and author>
2. Vulnerability subcom decides to X Y to access this issue
<now it's visible for vulnerability subcom, author and X Y, but only
this particular issue not others>
3. X Y fix the bug
<no changes in visibility>
4. Coordinated disclosure day comes. Vulnerability subcom publish the
issue
<now it's visible for everyone>

Best regards,

Jessica Wagantall via RT <onap-helpdesk@...>
 

Closing this RT for now.

I understand that the mentioned blockers will not allow us to proceed with the jira board ideas
mentioned in this ticket.

Also, I know that there is another workflow being prepared and presented to the TSC still.

Please create a new RT in future in case I can be of further help once the new idea is approved.
Will close this for now

Thanks!
Jess

On Tue Feb 05 21:17:27 2019, jwagantall wrote:
Dear Krzysztof,

Thanks for your previous comments.

In general, I am mostly worried about 2 of these requests that might
not be able to be possible:
- The empty notifications. The content of the email in the
notifications is not configurable
and even if we manage a way to hack it it will affect all projects
and not just this one.
If we would have slack, we could potentially manage to send
notifications there with a different
format, I think. Not much we can do with the built in notifications
in Jira.
- We cannot open permissions outside LF registered users for just 1
project. Opening JIRA for
non LF registered users cannot happen in this JIRA instance.

Everything else could be a matter of having SECOMM under its own
project workflow.

Let me know what you think about these 2 blockers

Thanks!
Jess

On Wed Jan 23 11:53:15 2019, k.opasiak@... wrote:


On 23.01.2019 01:41, Jessica Wagantall via RT wrote:
Hi Steve

I'm still reviewing this workflow that you are proposing.
I wanted to give my opinion from what I know JIRA can do, but maybe
is a good idea
to include Kenny's and any other JIRA user's opinion to see what
they
think too.

Let me know if my comments help you:

1. Anyone can submit a vulnerability JIRA (with or without a LF
ID)
(maybe we need a web front end??)
Currently only people with LFID can create a JIRA ticket in
jira.onap.org.
Opening the permissions to anonymous users here can cause a little
bit of issues
around other JIRA projects. We can talk more about this if you
want.
Couldn't we modify permission for only one project? Like
everyone is able to create a ticket in "Vulnerabilities" project
(possibly after filling captcha to avoid spam) but in other projects
we
require LFID?



2. It supports default settings where the Vulnerability management
sub-committee members are the only ones that have the right to
view
and access all the included Jiras
With a bit of work, I think we can achieve this via group
permissions.
Maybe I'll clarify requirement a little bit to make sure that it's
possible:
1. All the issues should be visible for Vulnerability management
sub-committee
2. Particular issue should be visible for creator and Vulnerability
management sub-committee
3. People outside of Vulnerability management sub-committee should
be
able to create issues in this project.



3. The vulnerability management sub-committee receives a
notification
that there is a new jira, but without the details
I think only the watchers of a particular JIRA could receive email
notifications
in this case. Adding people to the watchers list is still done
pretty
manually though.
Also, currently there is no way to add groups as a watcher, only
individuals.
Not sure how this will affect what you envision.
Yeah but the problem here is that by default jira sends the content
of
issue via email which is considered insecure for vulnerabilities. So
we
would like to get notifications but without the content



4. It is possible to extend the security settings in a per JIRA
basis
and a per individual basis to include access for selected
individuals
that are required to solve the identified vulnerability.
Again, I think this can be done via group permissions, but can be a
little bit tricky.
Can we modify permissions for particular issue or only for whole
project?


5. Finally, it should be possible to move the access restrictions
and
move the JIRA (when completed) to the appropriate project jira.
Not sure I understood this one. Do you mean moving from one JIRA
project to another
as part of a workflow?

In general, if we use JIRA for this matter it will probably have to
have its own
workflow since the current workflow used by all other projects is
very specific.
So what we would like to get is a timeline like this:

1. Someone creates ticket
<now it's visible for vulnerability subcom and author>
2. Vulnerability subcom decides to X Y to access this issue
<now it's visible for vulnerability subcom, author and X Y, but only
this particular issue not others>
3. X Y fix the bug
<no changes in visibility>
4. Coordinated disclosure day comes. Vulnerability subcom publish the
issue
<now it's visible for everyone>

Best regards,

Jessica Wagantall via RT <onap-helpdesk@...>
 

Closing this RT for now.

I understand that the mentioned blockers will not allow us to proceed with the jira board ideas
mentioned in this ticket.

Also, I know that there is another workflow being prepared and presented to the TSC still.

Please create a new RT in future in case I can be of further help once the new idea is approved.
Will close this for now

Thanks!
Jess

On Tue Feb 05 21:17:27 2019, jwagantall wrote:
Dear Krzysztof,

Thanks for your previous comments.

In general, I am mostly worried about 2 of these requests that might
not be able to be possible:
- The empty notifications. The content of the email in the
notifications is not configurable
and even if we manage a way to hack it it will affect all projects
and not just this one.
If we would have slack, we could potentially manage to send
notifications there with a different
format, I think. Not much we can do with the built in notifications
in Jira.
- We cannot open permissions outside LF registered users for just 1
project. Opening JIRA for
non LF registered users cannot happen in this JIRA instance.

Everything else could be a matter of having SECOMM under its own
project workflow.

Let me know what you think about these 2 blockers

Thanks!
Jess

On Wed Jan 23 11:53:15 2019, k.opasiak@... wrote:


On 23.01.2019 01:41, Jessica Wagantall via RT wrote:
Hi Steve

I'm still reviewing this workflow that you are proposing.
I wanted to give my opinion from what I know JIRA can do, but maybe
is a good idea
to include Kenny's and any other JIRA user's opinion to see what
they
think too.

Let me know if my comments help you:

1. Anyone can submit a vulnerability JIRA (with or without a LF
ID)
(maybe we need a web front end??)
Currently only people with LFID can create a JIRA ticket in
jira.onap.org.
Opening the permissions to anonymous users here can cause a little
bit of issues
around other JIRA projects. We can talk more about this if you
want.
Couldn't we modify permission for only one project? Like
everyone is able to create a ticket in "Vulnerabilities" project
(possibly after filling captcha to avoid spam) but in other projects
we
require LFID?



2. It supports default settings where the Vulnerability management
sub-committee members are the only ones that have the right to
view
and access all the included Jiras
With a bit of work, I think we can achieve this via group
permissions.
Maybe I'll clarify requirement a little bit to make sure that it's
possible:
1. All the issues should be visible for Vulnerability management
sub-committee
2. Particular issue should be visible for creator and Vulnerability
management sub-committee
3. People outside of Vulnerability management sub-committee should
be
able to create issues in this project.



3. The vulnerability management sub-committee receives a
notification
that there is a new jira, but without the details
I think only the watchers of a particular JIRA could receive email
notifications
in this case. Adding people to the watchers list is still done
pretty
manually though.
Also, currently there is no way to add groups as a watcher, only
individuals.
Not sure how this will affect what you envision.
Yeah but the problem here is that by default jira sends the content
of
issue via email which is considered insecure for vulnerabilities. So
we
would like to get notifications but without the content



4. It is possible to extend the security settings in a per JIRA
basis
and a per individual basis to include access for selected
individuals
that are required to solve the identified vulnerability.
Again, I think this can be done via group permissions, but can be a
little bit tricky.
Can we modify permissions for particular issue or only for whole
project?


5. Finally, it should be possible to move the access restrictions
and
move the JIRA (when completed) to the appropriate project jira.
Not sure I understood this one. Do you mean moving from one JIRA
project to another
as part of a workflow?

In general, if we use JIRA for this matter it will probably have to
have its own
workflow since the current workflow used by all other projects is
very specific.
So what we would like to get is a timeline like this:

1. Someone creates ticket
<now it's visible for vulnerability subcom and author>
2. Vulnerability subcom decides to X Y to access this issue
<now it's visible for vulnerability subcom, author and X Y, but only
this particular issue not others>
3. X Y fix the bug
<no changes in visibility>
4. Coordinated disclosure day comes. Vulnerability subcom publish the
issue
<now it's visible for everyone>

Best regards,

Krzysztof Opasiak
 

Jess!

On 14.02.2019 20:02, Jessica Wagantall via RT wrote:
Closing this RT for now.

I understand that the mentioned blockers will not allow us to proceed with the jira board ideas
mentioned in this ticket.

Also, I know that there is another workflow being prepared and presented to the TSC still.

Please create a new RT in future in case I can be of further help once the new idea is approved.
Will close this for now
I may present this unclear but actually the recommendation is to drop
these 2 requirements that were blocking us and proceed with this jira
project with custom workflow;)

--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Krzysztof Opasiak via RT <onap-helpdesk@...>
 

Jess!

On 14.02.2019 20:02, Jessica Wagantall via RT wrote:
Closing this RT for now.

I understand that the mentioned blockers will not allow us to proceed with the jira board ideas
mentioned in this ticket.

Also, I know that there is another workflow being prepared and presented to the TSC still.

Please create a new RT in future in case I can be of further help once the new idea is approved.
Will close this for now
I may present this unclear but actually the recommendation is to drop
these 2 requirements that were blocking us and proceed with this jira
project with custom workflow;)

--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Bengt Thuree via RT <onap-helpdesk@...>
 

Would this not be a rather big security risk, that someone, anyone, can publish a just discovered security risk, that has not yet been plugged, and hence makes it easier for anyone to try to gain access to various telecom systems that might be using ONAP?

Perhaps it makes more sence to keep this to a mailing list with authorized recipients.

On Thu Feb 14 14:14:44 2019, k.opasiak@... wrote:
Jess!

On 14.02.2019 20:02, Jessica Wagantall via RT wrote:
Closing this RT for now.

I understand that the mentioned blockers will not allow us to proceed
with the jira board ideas
mentioned in this ticket.

Also, I know that there is another workflow being prepared and
presented to the TSC still.

Please create a new RT in future in case I can be of further help
once the new idea is approved.
Will close this for now
I may present this unclear but actually the recommendation is to drop
these 2 requirements that were blocking us and proceed with this jira
project with custom workflow;)

Bengt Thuree via RT <onap-helpdesk@...>
 

Would this not be a rather big security risk, that someone, anyone, can publish a just discovered security risk, that has not yet been plugged, and hence makes it easier for anyone to try to gain access to various telecom systems that might be using ONAP?

Perhaps it makes more sence to keep this to a mailing list with authorized recipients.

On Thu Feb 14 14:14:44 2019, k.opasiak@... wrote:
Jess!

On 14.02.2019 20:02, Jessica Wagantall via RT wrote:
Closing this RT for now.

I understand that the mentioned blockers will not allow us to proceed
with the jira board ideas
mentioned in this ticket.

Also, I know that there is another workflow being prepared and
presented to the TSC still.

Please create a new RT in future in case I can be of further help
once the new idea is approved.
Will close this for now
I may present this unclear but actually the recommendation is to drop
these 2 requirements that were blocking us and proceed with this jira
project with custom workflow;)