Date   
[ONAP Helpdesk #67450] Jira board for Vulnerability Management

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

Hi

I am working on Workflow v1.1 now.
Just wanted to confirm if this looks ok, or if we can simplify it or not.

Cheers

Bengt

On Tue Mar 19 05:06:15 2019, bthuree wrote:
Hi Krzysztof
Sorry, somehow what I did for OJSI affected the normal ONAP workflows,
so I had to revert those.
And more specifically, those three status that you commented on.

I will re-look at the OJSI workflow tomorrow, and figure out how to
untie the connection between OJSI and regurlar ONAP workflow....

Apologise again for the confusion...

Cheers

Bengt

On Tue Mar 19 04:52:25 2019, k.opasiak@... wrote:


On 19.03.2019 04:52, Bengt Thuree via RT wrote:
Hi

Ok, it looks like three Link Status names has changed.

Would you agree with me that the following three Link Status Names
should change.

Not a security bug -----> Closed
Hmm I can kind of agree with that one

Hardening opportunity -----> Done
Nope, it's definitely not done. It's a task that should be
implemented
but it's potentially large and require public discussion

Not a bug -----> Reopened
Nope. I think that done is more appropriate for this one as it says
"it's a feature not a bug"

[ONAP Helpdesk #67450] Jira board for Vulnerability Management

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

Hi

I am working on Workflow v1.1 now.
Just wanted to confirm if this looks ok, or if we can simplify it or not.

Cheers

Bengt

On Tue Mar 19 05:06:15 2019, bthuree wrote:
Hi Krzysztof
Sorry, somehow what I did for OJSI affected the normal ONAP workflows,
so I had to revert those.
And more specifically, those three status that you commented on.

I will re-look at the OJSI workflow tomorrow, and figure out how to
untie the connection between OJSI and regurlar ONAP workflow....

Apologise again for the confusion...

Cheers

Bengt

On Tue Mar 19 04:52:25 2019, k.opasiak@... wrote:


On 19.03.2019 04:52, Bengt Thuree via RT wrote:
Hi

Ok, it looks like three Link Status names has changed.

Would you agree with me that the following three Link Status Names
should change.

Not a security bug -----> Closed
Hmm I can kind of agree with that one

Hardening opportunity -----> Done
Nope, it's definitely not done. It's a task that should be
implemented
but it's potentially large and require public discussion

Not a bug -----> Reopened
Nope. I think that done is more appropriate for this one as it says
"it's a feature not a bug"

Re: Wildest problem in a while. Ran out of SecureRandom bytes

Keong Lim
 

Hi Jonathan,

Why is that old bug even still active? It is marked as a duplicate of https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4705093
which contains a workaround from 2002!

{quote}
WORK AROUND

Edit the jre/lib/security/java.security file to point to /dev/urandom or any other URL or set the System property java.security.egd when invoking Java, e.g. "java -Djava.security.egd=file:/dev/urandom com.foo.MyApp"

###@###.### 2002-07-24
{quote}

See also https://www.2uo.de/myths-about-urandom/

{quote}
tldr;
Just use /dev/urandom!
{quote}

Updated Event: #seccom Subcommittee (UTC) #seccom #cal-invite

onap-seccom@lists.onap.org Calendar <onap-seccom@...>
 

#seccom Subcommittee (UTC)

When:
Wednesday, 20 March 2019
2:00pm to 3:00pm
(GMT+00:00) UTC
Repeats: Weekly on Wednesday

Where:
https://zoom.us/j/793296315

Organizer:
pawel.pawlak3@... Bridge: ONAP2

Description:

https://zoom.us/j/793296315
 
One tap mobile
+16465588656,,793296315# US (New York)
+16699006833,,793296315# US (San Jose)
 
Dial by your location
        +1 646 558 8656 US (New York)
        +1 669 900 6833 US (San Jose)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
Meeting ID: 793 296 315
Find your local number: https://zoom.us/u/aedFyNdWz8

Updated Event: #seccom Subcommittee (UTC) #seccom #cal-invite

onap-seccom@lists.onap.org Calendar <onap-seccom@...>
 

#seccom Subcommittee (UTC)

When:
Wednesday, 20 March 2019
1:00pm to 2:00pm
(GMT+00:00) UTC
Repeats: Weekly on Wednesday

Where:
https://zoom.us/j/793296315

Organizer:
pawel.pawlak3@... Bridge: ONAP2

Description:

https://zoom.us/j/793296315
 
One tap mobile
+16465588656,,793296315# US (New York)
+16699006833,,793296315# US (San Jose)
 
Dial by your location
        +1 646 558 8656 US (New York)
        +1 669 900 6833 US (San Jose)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
Meeting ID: 793 296 315
Find your local number: https://zoom.us/u/aedFyNdWz8

[ONAP Helpdesk #67450] Jira board for Vulnerability Management

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

Hi Krzysztof
Sorry, somehow what I did for OJSI affected the normal ONAP workflows, so I had to revert those.
And more specifically, those three status that you commented on.

I will re-look at the OJSI workflow tomorrow, and figure out how to untie the connection between OJSI and regurlar ONAP workflow....

Apologise again for the confusion...

Cheers

Bengt

On Tue Mar 19 04:52:25 2019, k.opasiak@... wrote:


On 19.03.2019 04:52, Bengt Thuree via RT wrote:
Hi

Ok, it looks like three Link Status names has changed.

Would you agree with me that the following three Link Status Names
should change.

Not a security bug -----> Closed
Hmm I can kind of agree with that one

Hardening opportunity -----> Done
Nope, it's definitely not done. It's a task that should be implemented
but it's potentially large and require public discussion

Not a bug -----> Reopened
Nope. I think that done is more appropriate for this one as it says
"it's a feature not a bug"

[ONAP Helpdesk #67450] Jira board for Vulnerability Management

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

Hi

So sorry for this taking a bit of time to sort out. Just wanted to re-check and double check a few times...
I have now renamed the weird names to the proper names.

Of course, this means that OJSI workflow is not reliable for the moment.
I will look more closer at that one tomorrow, as well as confirm that OJSI is apart from the normal work flow.

Hopefully it looks ok now.
I checked https://jira.onap.org/browse/AAI-2151 which now has status closed.
Also the three ONAP Workflow diagrams all look good to me as well.

Cheers

Bengt

On Tue Mar 19 04:03:17 2019, catherine.lefevre@... wrote:
Hi Stephen,



All the projects seem to be impacted – I have checked APPC, CLAMP,
CCSDK, CLAMP, DCAE, Documentaion, Policy, Portal, SDC, SDNC, SO, VID,
TSC, etc

I think that the ONAP Helpdesk is trying to roll back the change

The value “CLOSED” status and “DONE do not exist in the field status

The status workflow is also impacted

[cid:image003.jpg@...]



The status field includes "NOT A SECURITY BUG" and “NOT A BUG” while
the “labels” or “Resolution” field should have been used for this
purpose.



JIRA is also extremely slow this morning



Best regards

Catherine



-----Original Message-----
From: onap-seccom@... [mailto:onap-seccom@...]
On Behalf Of Stephen Terrill via RT
Sent: Tuesday, March 19, 2019 8:51 AM
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for
Vulnerability Management



Hi,



I notice that this seems to have effected other JIRA boards as well -
I see it in the Architecture JIRA, and it looks like its on the TSC
jiras we well.



BR,



Steve



-----Original Message-----
From: onap-seccom@...<mailto:onap-seccom@...>
<onap-seccom@...<mailto:onap-seccom@...>> On
Behalf Of Bengt Thuree via RT
Sent: Monday 18 March 2019 23:40
Cc: pierre.close@...<mailto:pierre.close@...>;
keong.lim@...<mailto:keong.lim@...>; onap-
seccom@...<mailto:seccom@...>;
jwagantall@...<mailto:jwagantall@...>;
k.opasiak@...<mailto:k.opasiak@...>
Subject: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for
Vulnerability Management
Hi Keong
Yes, that was a unexpected and unwanted effect.
Even if I modified only the OJSI area, some items were modified on
other schemes.
Looking on how to revert those now.
Looks like we will need to create a new copy of the workflow, and
modify that one, and re-apply it.
Cheers, and thanks for highlighting it to me
Bengt
On Mon Mar 18 13:58:24 2019,
k.opasiak@...<mailto:k.opasiak@...> wrote:
On 18.03.2019 18:39, Krzysztof Opasiak wrote:
On 18.03.2019 12:05, Bengt Thuree via RT wrote:
Hi
I added the workflow you wanted, with very simple transitions
between the statuses. Most of it goes to next one below in
chain,
but quite a lot also can go back to under development I think it
was.
We have two security options, Secure, and Public. Do you want
that, or should we just have Secure?
We definitely want both Secure and Public in order to be able to
open the ticket as a part of publication process.
also, have a think of the People/Groups with access to this
queue.
See earlier history in this ticket.
Any changes that should be made there or?
Actually we requested that we want to be able to grant access
rights to the individual users per ticket basis.
There is no reason for XXX PTL know that there is a vulnerability
in YYY or even worse developer from project XXX to know about
vulnerabilities in all other projects.
So summing up. We need:
Secure
Secure + people added by VMS
Public
BTW
Please use the names Secure\Public or Limited\Public as "Security
Issue"\"Not a security issue" for Security Level mey be misleading
when we publish a ticked which indeed is a security issue but it
has been fixed so we are publishing the whole history.
Best regards,








[ONAP Helpdesk #67450] Jira board for Vulnerability Management

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

Hi

So sorry for this taking a bit of time to sort out. Just wanted to re-check and double check a few times...
I have now renamed the weird names to the proper names.

Of course, this means that OJSI workflow is not reliable for the moment.
I will look more closer at that one tomorrow, as well as confirm that OJSI is apart from the normal work flow.

Hopefully it looks ok now.
I checked https://jira.onap.org/browse/AAI-2151 which now has status closed.
Also the three ONAP Workflow diagrams all look good to me as well.

Cheers

Bengt

On Tue Mar 19 04:03:17 2019, catherine.lefevre@... wrote:
Hi Stephen,



All the projects seem to be impacted – I have checked APPC, CLAMP,
CCSDK, CLAMP, DCAE, Documentaion, Policy, Portal, SDC, SDNC, SO, VID,
TSC, etc

I think that the ONAP Helpdesk is trying to roll back the change

The value “CLOSED” status and “DONE do not exist in the field status

The status workflow is also impacted

[cid:image003.jpg@...]



The status field includes "NOT A SECURITY BUG" and “NOT A BUG” while
the “labels” or “Resolution” field should have been used for this
purpose.



JIRA is also extremely slow this morning



Best regards

Catherine



-----Original Message-----
From: onap-seccom@... [mailto:onap-seccom@...]
On Behalf Of Stephen Terrill via RT
Sent: Tuesday, March 19, 2019 8:51 AM
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for
Vulnerability Management



Hi,



I notice that this seems to have effected other JIRA boards as well -
I see it in the Architecture JIRA, and it looks like its on the TSC
jiras we well.



BR,



Steve



-----Original Message-----
From: onap-seccom@...<mailto:onap-seccom@...>
<onap-seccom@...<mailto:onap-seccom@...>> On
Behalf Of Bengt Thuree via RT
Sent: Monday 18 March 2019 23:40
Cc: pierre.close@...<mailto:pierre.close@...>;
keong.lim@...<mailto:keong.lim@...>; onap-
seccom@...<mailto:seccom@...>;
jwagantall@...<mailto:jwagantall@...>;
k.opasiak@...<mailto:k.opasiak@...>
Subject: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for
Vulnerability Management
Hi Keong
Yes, that was a unexpected and unwanted effect.
Even if I modified only the OJSI area, some items were modified on
other schemes.
Looking on how to revert those now.
Looks like we will need to create a new copy of the workflow, and
modify that one, and re-apply it.
Cheers, and thanks for highlighting it to me
Bengt
On Mon Mar 18 13:58:24 2019,
k.opasiak@...<mailto:k.opasiak@...> wrote:
On 18.03.2019 18:39, Krzysztof Opasiak wrote:
On 18.03.2019 12:05, Bengt Thuree via RT wrote:
Hi
I added the workflow you wanted, with very simple transitions
between the statuses. Most of it goes to next one below in
chain,
but quite a lot also can go back to under development I think it
was.
We have two security options, Secure, and Public. Do you want
that, or should we just have Secure?
We definitely want both Secure and Public in order to be able to
open the ticket as a part of publication process.
also, have a think of the People/Groups with access to this
queue.
See earlier history in this ticket.
Any changes that should be made there or?
Actually we requested that we want to be able to grant access
rights to the individual users per ticket basis.
There is no reason for XXX PTL know that there is a vulnerability
in YYY or even worse developer from project XXX to know about
vulnerabilities in all other projects.
So summing up. We need:
Secure
Secure + people added by VMS
Public
BTW
Please use the names Secure\Public or Limited\Public as "Security
Issue"\"Not a security issue" for Security Level mey be misleading
when we publish a ticked which indeed is a security issue but it
has been fixed so we are publishing the whole history.
Best regards,








Re: [ONAP Helpdesk #67450] Jira board for Vulnerability Management

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

On 19.03.2019 04:52, Bengt Thuree via RT wrote:
Hi

Ok, it looks like three Link Status names has changed.

Would you agree with me that the following three Link Status Names should change.

Not a security bug -----> Closed
Hmm I can kind of agree with that one

Hardening opportunity -----> Done
Nope, it's definitely not done. It's a task that should be implemented
but it's potentially large and require public discussion

Not a bug -----> Reopened
Nope. I think that done is more appropriate for this one as it says
"it's a feature not a bug"

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

Re: [ONAP Helpdesk #67450] Jira board for Vulnerability Management

Krzysztof Opasiak
 

On 19.03.2019 04:52, Bengt Thuree via RT wrote:
Hi

Ok, it looks like three Link Status names has changed.

Would you agree with me that the following three Link Status Names should change.

Not a security bug -----> Closed
Hmm I can kind of agree with that one

Hardening opportunity -----> Done
Nope, it's definitely not done. It's a task that should be implemented
but it's potentially large and require public discussion

Not a bug -----> Reopened
Nope. I think that done is more appropriate for this one as it says
"it's a feature not a bug"

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

Re: [ONAP Helpdesk #67450] Jira board for Vulnerability Management

Lefevre, Catherine via RT <onap-helpdesk@...>
 

Hi Stephen,



All the projects seem to be impacted – I have checked APPC, CLAMP, CCSDK, CLAMP, DCAE, Documentaion, Policy, Portal, SDC, SDNC, SO, VID, TSC, etc

I think that the ONAP Helpdesk is trying to roll back the change

The value “CLOSED” status and “DONE do not exist in the field status

The status workflow is also impacted

[cid:image003.jpg@...]



The status field includes "NOT A SECURITY BUG" and “NOT A BUG” while the “labels” or “Resolution” field should have been used for this purpose.



JIRA is also extremely slow this morning



Best regards

Catherine

-----Original Message-----
From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of Stephen Terrill via RT
Sent: Tuesday, March 19, 2019 8:51 AM
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for Vulnerability Management



Hi,



I notice that this seems to have effected other JIRA boards as well - I see it in the Architecture JIRA, and it looks like its on the TSC jiras we well.



BR,



Steve



-----Original Message-----
From: onap-seccom@...<mailto:onap-seccom@...> <onap-seccom@...<mailto:onap-seccom@...>> On
Behalf Of Bengt Thuree via RT
Sent: Monday 18 March 2019 23:40
Cc: pierre.close@...<mailto:pierre.close@...>; keong.lim@...<mailto:keong.lim@...>; onap-
seccom@...<mailto:seccom@...>; jwagantall@...<mailto:jwagantall@...>;
k.opasiak@...<mailto:k.opasiak@...>
Subject: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for
Vulnerability Management
Hi Keong
Yes, that was a unexpected and unwanted effect.
Even if I modified only the OJSI area, some items were modified on
other schemes.
Looking on how to revert those now.
Looks like we will need to create a new copy of the workflow, and
modify that one, and re-apply it.
Cheers, and thanks for highlighting it to me
Bengt
On Mon Mar 18 13:58:24 2019, k.opasiak@...<mailto:k.opasiak@...> wrote:
On 18.03.2019 18:39, Krzysztof Opasiak wrote:
On 18.03.2019 12:05, Bengt Thuree via RT wrote:
Hi
I added the workflow you wanted, with very simple transitions
between the statuses. Most of it goes to next one below in chain,
but quite a lot also can go back to under development I think it
was.
We have two security options, Secure, and Public. Do you want
that, or should we just have Secure?
We definitely want both Secure and Public in order to be able to
open the ticket as a part of publication process.
also, have a think of the People/Groups with access to this queue.
See earlier history in this ticket.
Any changes that should be made there or?
Actually we requested that we want to be able to grant access
rights to the individual users per ticket basis.
There is no reason for XXX PTL know that there is a vulnerability
in YYY or even worse developer from project XXX to know about
vulnerabilities in all other projects.
So summing up. We need:
Secure
Secure + people added by VMS
Public
BTW
Please use the names Secure\Public or Limited\Public as "Security
Issue"\"Not a security issue" for Security Level mey be misleading
when we publish a ticked which indeed is a security issue but it
has been fixed so we are publishing the whole history.
Best regards,

Re: [ONAP Helpdesk #67450] Jira board for Vulnerability Management

Catherine LEFEVRE
 

Hi Stephen,

 

All the projects seem to be impacted – I have checked APPC, CLAMP, CCSDK, CLAMP, DCAE, Documentaion, Policy, Portal, SDC, SDNC, SO, VID, TSC, etc

I think that the ONAP Helpdesk is trying to roll back the change

The value “CLOSED” status and “DONE do not exist in the field status

The status workflow is also impacted

 

The status field includes "NOT A SECURITY BUG" and “NOT A BUG” while the “labels” or “Resolution” field should have been used for this purpose.

 

JIRA is also extremely slow this morning

 

Best regards

Catherine

 

-----Original Message-----
From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of Stephen Terrill via RT
Sent: Tuesday, March 19, 2019 8:51 AM
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for Vulnerability Management

 

Hi,

 

I notice that this seems to have effected other JIRA boards as well - I see it in the Architecture JIRA, and it looks like its on the TSC jiras we well.

 

BR,

 

Steve

 

> -----Original Message-----

> From: onap-seccom@... <onap-seccom@...> On

> Behalf Of Bengt Thuree via RT

> Sent: Monday 18 March 2019 23:40

> Cc: pierre.close@...; keong.lim@...; onap-

> seccom@...; jwagantall@...;

> k.opasiak@...

> Subject: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for

> Vulnerability Management

>

> Hi Keong

>

> Yes, that was a unexpected and unwanted effect.

> Even if I modified only the OJSI area, some items were modified on

> other schemes.

> Looking on how to revert those now.

>

> Looks like we will need to create a new copy of the workflow, and

> modify that one, and re-apply it.

>

> Cheers, and thanks for highlighting it to me

>

> Bengt

>

> On Mon Mar 18 13:58:24 2019, k.opasiak@... wrote:

> >

> >

> > On 18.03.2019 18:39, Krzysztof Opasiak wrote:

> > >

> > >

> > > On 18.03.2019 12:05, Bengt Thuree via RT wrote:

> > >> Hi

> > >>

> > >> I added the workflow you wanted, with very simple transitions

> > >> between the statuses. Most of it goes to next one below in chain,

> > >> but quite a lot also can go back to under development I think it

> > >> was.

> > >>

> > >> We have two security options, Secure, and Public. Do you want

> > >> that, or should we just have Secure?

> > >

> > > We definitely want both Secure and Public in order to be able to

> > > open the ticket as a part of publication process.

> > >

> > >>

> > >> also, have a think of the People/Groups with access to this queue.

> > >> See earlier history in this ticket.

> > >> Any changes that should be made there or?

> > >

> > > Actually we requested that we want to be able to grant access

> > > rights to the individual users per ticket basis.

> > >

> > > There is no reason for XXX PTL know that there is a vulnerability

> > > in YYY or even worse developer from project XXX to know about

> > > vulnerabilities in all other projects.

> > >

> > > So summing up. We need:

> > >

> > > Secure

> > > Secure + people added by VMS

> > > Public

> > >

> >

> > BTW

> >  Please use the names Secure\Public or Limited\Public as "Security

> > Issue"\"Not a security issue" for Security Level mey be misleading

> > when  we publish a ticked which indeed is a security issue but it

> > has been fixed so we are publishing the whole history.

> >

> > Best regards,

>

>

>

>

>

 

 

 

 

Re: [ONAP Helpdesk #67450] Jira board for Vulnerability Management

Stephen Terrill via RT <onap-helpdesk@...>
 

Hi,

I notice that this seems to have effected other JIRA boards as well - I see it in the Architecture JIRA, and it looks like its on the TSC jiras we well.

BR,

Steve

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On
Behalf Of Bengt Thuree via RT
Sent: Monday 18 March 2019 23:40
Cc: pierre.close@...; keong.lim@...; onap-
seccom@...; jwagantall@...;
k.opasiak@...
Subject: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for Vulnerability
Management

Hi Keong

Yes, that was a unexpected and unwanted effect.
Even if I modified only the OJSI area, some items were modified on other
schemes.
Looking on how to revert those now.

Looks like we will need to create a new copy of the workflow, and modify
that one, and re-apply it.

Cheers, and thanks for highlighting it to me

Bengt

On Mon Mar 18 13:58:24 2019, k.opasiak@... wrote:


On 18.03.2019 18:39, Krzysztof Opasiak wrote:


On 18.03.2019 12:05, Bengt Thuree via RT wrote:
Hi

I added the workflow you wanted, with very simple transitions
between the statuses. Most of it goes to next one below in chain,
but quite a lot also can go back to under development I think it
was.

We have two security options, Secure, and Public. Do you want that,
or should we just have Secure?
We definitely want both Secure and Public in order to be able to
open the ticket as a part of publication process.


also, have a think of the People/Groups with access to this queue.
See earlier history in this ticket.
Any changes that should be made there or?
Actually we requested that we want to be able to grant access rights
to the individual users per ticket basis.

There is no reason for XXX PTL know that there is a vulnerability in
YYY or even worse developer from project XXX to know about
vulnerabilities in all other projects.

So summing up. We need:

Secure
Secure + people added by VMS
Public
BTW
Please use the names Secure\Public or Limited\Public as "Security
Issue"\"Not a security issue" for Security Level mey be misleading
when we publish a ticked which indeed is a security issue but it has
been fixed so we are publishing the whole history.

Best regards,



Re: [ONAP Helpdesk #67450] Jira board for Vulnerability Management

Keong Lim via RT <onap-helpdesk@...>
 

Looks right to me.

-----Original Message-----
From: Bengt Thuree via RT [mailto:onap-helpdesk@...]
Sent: Tuesday, 19 March 2019 14:53
Cc: onap-seccom@...; Keong Lim <Keong.Lim@...>; Keong Lim <Keong.Lim@...>; pierre.close@...; jwagantall@...; k.opasiak@...
Subject: [ONAP Helpdesk #67450] Jira board for Vulnerability Management

Hi

Ok, it looks like three Link Status names has changed.

Would you agree with me that the following three Link Status Names should change.

Not a security bug -----> Closed
Hardening opportunity -----> Done
Not a bug -----> Reopened

Cheers

Bengt

On Mon Mar 18 18:40:01 2019, bthuree wrote:
Hi Keong

Yes, that was a unexpected and unwanted effect.
Even if I modified only the OJSI area, some items were modified on
other schemes.
Looking on how to revert those now.

Looks like we will need to create a new copy of the workflow, and
modify that one, and re-apply it.

Cheers, and thanks for highlighting it to me

Bengt

[ONAP Helpdesk #67450] Jira board for Vulnerability Management

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

Hi

Ok, it looks like three Link Status names has changed.

Would you agree with me that the following three Link Status Names should change.

Not a security bug -----> Closed
Hardening opportunity -----> Done
Not a bug -----> Reopened

Cheers

Bengt

On Mon Mar 18 18:40:01 2019, bthuree wrote:
Hi Keong

Yes, that was a unexpected and unwanted effect.
Even if I modified only the OJSI area, some items were modified on
other schemes.
Looking on how to revert those now.

Looks like we will need to create a new copy of the workflow, and
modify that one, and re-apply it.

Cheers, and thanks for highlighting it to me

Bengt

On Mon Mar 18 13:58:24 2019, k.opasiak@... wrote:


On 18.03.2019 18:39, Krzysztof Opasiak wrote:


On 18.03.2019 12:05, Bengt Thuree via RT wrote:
Hi

I added the workflow you wanted, with very simple transitions
between the statuses. Most of it goes to next one below in chain,
but quite a lot also can go back to under development I think it
was.

We have two security options, Secure, and Public. Do you want
that,
or should we just have Secure?
We definitely want both Secure and Public in order to be able to
open
the ticket as a part of publication process.


also, have a think of the People/Groups with access to this queue.
See earlier history in this ticket.
Any changes that should be made there or?
Actually we requested that we want to be able to grant access
rights
to
the individual users per ticket basis.

There is no reason for XXX PTL know that there is a vulnerability
in
YYY
or even worse developer from project XXX to know about
vulnerabilities
in all other projects.

So summing up. We need:

Secure
Secure + people added by VMS
Public
BTW
Please use the names Secure\Public or Limited\Public as "Security
Issue"\"Not a security issue" for Security Level mey be misleading
when
we publish a ticked which indeed is a security issue but it has been
fixed so we are publishing the whole history.

Best regards,

[ONAP Helpdesk #67450] Jira board for Vulnerability Management

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

Hi

Ok, it looks like three Link Status names has changed.

Would you agree with me that the following three Link Status Names should change.

Not a security bug -----> Closed
Hardening opportunity -----> Done
Not a bug -----> Reopened

Cheers

Bengt

On Mon Mar 18 18:40:01 2019, bthuree wrote:
Hi Keong

Yes, that was a unexpected and unwanted effect.
Even if I modified only the OJSI area, some items were modified on
other schemes.
Looking on how to revert those now.

Looks like we will need to create a new copy of the workflow, and
modify that one, and re-apply it.

Cheers, and thanks for highlighting it to me

Bengt

On Mon Mar 18 13:58:24 2019, k.opasiak@... wrote:


On 18.03.2019 18:39, Krzysztof Opasiak wrote:


On 18.03.2019 12:05, Bengt Thuree via RT wrote:
Hi

I added the workflow you wanted, with very simple transitions
between the statuses. Most of it goes to next one below in chain,
but quite a lot also can go back to under development I think it
was.

We have two security options, Secure, and Public. Do you want
that,
or should we just have Secure?
We definitely want both Secure and Public in order to be able to
open
the ticket as a part of publication process.


also, have a think of the People/Groups with access to this queue.
See earlier history in this ticket.
Any changes that should be made there or?
Actually we requested that we want to be able to grant access
rights
to
the individual users per ticket basis.

There is no reason for XXX PTL know that there is a vulnerability
in
YYY
or even worse developer from project XXX to know about
vulnerabilities
in all other projects.

So summing up. We need:

Secure
Secure + people added by VMS
Public
BTW
Please use the names Secure\Public or Limited\Public as "Security
Issue"\"Not a security issue" for Security Level mey be misleading
when
we publish a ticked which indeed is a security issue but it has been
fixed so we are publishing the whole history.

Best regards,

Re: [ONAP Helpdesk #67450] Jira board for Vulnerability Management

Stephen Terrill
 

Hi,

I notice that this seems to have effected other JIRA boards as well - I see it in the Architecture JIRA, and it looks like its on the TSC jiras we well.

BR,

Steve

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On
Behalf Of Bengt Thuree via RT
Sent: Monday 18 March 2019 23:40
Cc: pierre.close@...; keong.lim@...; onap-
seccom@...; jwagantall@...;
k.opasiak@...
Subject: [Onap-seccom] [ONAP Helpdesk #67450] Jira board for Vulnerability
Management

Hi Keong

Yes, that was a unexpected and unwanted effect.
Even if I modified only the OJSI area, some items were modified on other
schemes.
Looking on how to revert those now.

Looks like we will need to create a new copy of the workflow, and modify
that one, and re-apply it.

Cheers, and thanks for highlighting it to me

Bengt

On Mon Mar 18 13:58:24 2019, k.opasiak@... wrote:


On 18.03.2019 18:39, Krzysztof Opasiak wrote:


On 18.03.2019 12:05, Bengt Thuree via RT wrote:
Hi

I added the workflow you wanted, with very simple transitions
between the statuses. Most of it goes to next one below in chain,
but quite a lot also can go back to under development I think it
was.

We have two security options, Secure, and Public. Do you want that,
or should we just have Secure?
We definitely want both Secure and Public in order to be able to
open the ticket as a part of publication process.


also, have a think of the People/Groups with access to this queue.
See earlier history in this ticket.
Any changes that should be made there or?
Actually we requested that we want to be able to grant access rights
to the individual users per ticket basis.

There is no reason for XXX PTL know that there is a vulnerability in
YYY or even worse developer from project XXX to know about
vulnerabilities in all other projects.

So summing up. We need:

Secure
Secure + people added by VMS
Public
BTW
Please use the names Secure\Public or Limited\Public as "Security
Issue"\"Not a security issue" for Security Level mey be misleading
when we publish a ticked which indeed is a security issue but it has
been fixed so we are publishing the whole history.

Best regards,



Re: [ONAP Helpdesk #67450] Jira board for Vulnerability Management

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

On 18.03.2019 18:39, Krzysztof Opasiak wrote:


On 18.03.2019 12:05, Bengt Thuree via RT wrote:
Hi

I added the workflow you wanted, with very simple transitions between the statuses. Most of it goes to next one below in chain, but quite a lot also can go back to under development I think it was.

We have two security options, Secure, and Public. Do you want that, or should we just have Secure?
We definitely want both Secure and Public in order to be able to open
the ticket as a part of publication process.


also, have a think of the People/Groups with access to this queue. See earlier history in this ticket.
Any changes that should be made there or?
Actually we requested that we want to be able to grant access rights to
the individual users per ticket basis.

There is no reason for XXX PTL know that there is a vulnerability in YYY
or even worse developer from project XXX to know about vulnerabilities
in all other projects.

So summing up. We need:

Secure
Secure + people added by VMS
Public
BTW
Please use the names Secure\Public or Limited\Public as "Security
Issue"\"Not a security issue" for Security Level mey be misleading when
we publish a ticked which indeed is a security issue but it has been
fixed so we are publishing the whole history.

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

[ONAP Helpdesk #67450] Jira board for Vulnerability Management

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

Hi Keong

Yes, that was a unexpected and unwanted effect.
Even if I modified only the OJSI area, some items were modified on other schemes.
Looking on how to revert those now.

Looks like we will need to create a new copy of the workflow, and modify that one, and re-apply it.

Cheers, and thanks for highlighting it to me

Bengt

On Mon Mar 18 13:58:24 2019, k.opasiak@... wrote:


On 18.03.2019 18:39, Krzysztof Opasiak wrote:


On 18.03.2019 12:05, Bengt Thuree via RT wrote:
Hi

I added the workflow you wanted, with very simple transitions
between the statuses. Most of it goes to next one below in chain,
but quite a lot also can go back to under development I think it
was.

We have two security options, Secure, and Public. Do you want that,
or should we just have Secure?
We definitely want both Secure and Public in order to be able to open
the ticket as a part of publication process.


also, have a think of the People/Groups with access to this queue.
See earlier history in this ticket.
Any changes that should be made there or?
Actually we requested that we want to be able to grant access rights
to
the individual users per ticket basis.

There is no reason for XXX PTL know that there is a vulnerability in
YYY
or even worse developer from project XXX to know about
vulnerabilities
in all other projects.

So summing up. We need:

Secure
Secure + people added by VMS
Public
BTW
Please use the names Secure\Public or Limited\Public as "Security
Issue"\"Not a security issue" for Security Level mey be misleading
when
we publish a ticked which indeed is a security issue but it has been
fixed so we are publishing the whole history.

Best regards,

[ONAP Helpdesk #67450] Jira board for Vulnerability Management

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

Hi Keong

Yes, that was a unexpected and unwanted effect.
Even if I modified only the OJSI area, some items were modified on other schemes.
Looking on how to revert those now.

Looks like we will need to create a new copy of the workflow, and modify that one, and re-apply it.

Cheers, and thanks for highlighting it to me

Bengt

On Mon Mar 18 13:58:24 2019, k.opasiak@... wrote:


On 18.03.2019 18:39, Krzysztof Opasiak wrote:


On 18.03.2019 12:05, Bengt Thuree via RT wrote:
Hi

I added the workflow you wanted, with very simple transitions
between the statuses. Most of it goes to next one below in chain,
but quite a lot also can go back to under development I think it
was.

We have two security options, Secure, and Public. Do you want that,
or should we just have Secure?
We definitely want both Secure and Public in order to be able to open
the ticket as a part of publication process.


also, have a think of the People/Groups with access to this queue.
See earlier history in this ticket.
Any changes that should be made there or?
Actually we requested that we want to be able to grant access rights
to
the individual users per ticket basis.

There is no reason for XXX PTL know that there is a vulnerability in
YYY
or even worse developer from project XXX to know about
vulnerabilities
in all other projects.

So summing up. We need:

Secure
Secure + people added by VMS
Public
BTW
Please use the names Secure\Public or Limited\Public as "Security
Issue"\"Not a security issue" for Security Level mey be misleading
when
we publish a ticked which indeed is a security issue but it has been
fixed so we are publishing the whole history.

Best regards,