Date   
Re: Communication matrix

Hampus Tjader
 

Hi Natacha,

 

Great work with the matrix!

 

I have a question regarding the “external communication”. My assumption is that this category will also be used for “platform external” components, e.g say between DCAE-yyy and xNF.

Does the “communication_initiator” in this case then define the entity acting as TLS server or is it more related to who is initiating the connection (not related to TLS handshake)?  
Could be interesting to highlight this for platform-external interfaces, thus whether external facing ONAP components are hosting a TLS server or TLS client. It would also be good from a security perspective to have this inventory of platform-externally open ports for the ONAP components, so we in the future might be able to decrease the platform external attack vector.

 

Best regards,

Hampus

 

From: onap-seccom@... <onap-seccom@...> On Behalf Of natacha.mach via Lists.Onap.Org
Sent: den 25 juni 2019 16:46
To: onap-seccom@...
Cc: onap-seccom@...
Subject: [Onap-seccom] Communication matrix

 

Hello,

 

As discussed during the SECCOM of last week, i am sharing with you a proposal regarding the YAML file for the communication matrix work item.

 

Please share your comments, and then we can propose it to the PTLs.

 

Many thanks and best regards

Natacha

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: Runtime Online dependency - recommendation proposal

Horn, Linda (Nokia - US/Murray Hill)
 

Pawel,

Before or after the SECCOM call on July 16 is fine with me - whichever is better for others.

Linda
-----------------------------------------------------------------------------------
Linda S. Horn, DMTS
Cloud RAN Solution Definition and Architecture
Mobile Networks, Nokia
Phone:  +1-908-679-6580

-----Original Message-----
From: Pawlak Paweł 3 - Korpo <Pawel.Pawlak3@...>
Sent: Wednesday, June 26, 2019 3:02 AM
To: Horn, Linda (Nokia - US/Murray Hill) <linda.horn@...>
Cc: onap-seccom@...
Subject: RE: [Onap-seccom] Runtime Online dependency - recommendation proposal

Hello Linda,
Following the discussions below I would like to propose a dedicated call on 16th of July either before or after SECCOM meeting.
Please let us know your availabilities.

Best regards

Paweł Pawlak

ONAP SECCOM Chair
Leader in IT & Network Convergent Operations FT/TGI/OLN/QOP/OST

Orange Polska S.A.
Corporate Services Agency

Obrzeżna 7, 02-691 Warszawa
tel. +48 22 699 52 17
fax +48 22 857 99 86
tel. mob. +48 501 501 030

   Czy musisz drukować tę wiadomość? Pomyśl o środowisku.
__________________________________________________________________
Treść tej wiadomości jest własnością Orange Polska i zawiera informacje stanowiące tajemnicę przedsiębiorstwa Orange Polska. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę, prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. Orange Polska Spółka Akcyjna z siedzibą i adresem w Warszawie (02-326) przy Al. Jerozolimskich 160, wpisana do Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy dla m.st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 0000010681; REGON 012100784, NIP 526-02-50-995; z pokrytym w całości kapitałem zakładowym wynoszącym 3.937.072.437 złotych.

-----Original Message-----
From: Horn, Linda (Nokia - US/Murray Hill) [mailto:linda.horn@...]
Sent: Wednesday, June 12, 2019 9:18 PM
To: MACH Natacha TGI/OLS; ZWARICO, AMY; Pawlak Paweł 3 - Korpo; onap-seccom@...
Subject: RE: [Onap-seccom] Runtime Online dependency - recommendation proposal

Natacha,

Thank you for reviewing. My comments are in the attached doc. BTW there is a version v7 now but it has minor changes so your comments are still valid.

Linda
-----------------------------------------------------------------------------------
Linda S. Horn, DMTS
Cloud RAN Solution Definition and Architecture
Mobile Networks, Nokia
Phone:  +1-908-679-6580

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On Behalf Of natacha.mach via Lists.Onap.Org
Sent: Friday, June 07, 2019 10:19 AM
To: ZWARICO, AMY <az9121@...>; PAWLAK Pawel O-PL <pawel.pawlak3@...>; onap-seccom@...
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] Runtime Online dependency - recommendation proposal

hello,

Thanks for the comments, and here are some remarks for understanding first.
I hopr that we could discuss this document next week?

Regards
natacha
________________________________________
De : onap-seccom@... [onap-seccom@...] de la part de ZWARICO, AMY [az9121@...] Envoyé : jeudi 6 juin 2019 21:41 À : PAWLAK Pawel O-PL; onap-seccom@... Objet : Re: [Onap-seccom] Runtime Online dependency - recommendation proposal

I found another typo and made some other minor wording changes.

-----Original Message-----
From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of Pawel Pawlak via Lists.Onap.Org
Sent: Thursday, June 06, 2019 7:33 AM
To: onap-seccom@...
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] Runtime Online dependency - recommendation proposal

I have corrected 2 typos...
Best regards

Paweł Pawlak

ONAP SECCOM Chair
Leader in IT & Network Convergent Operations FT/TGI/OLN/QOP/OST

Orange Polska S.A.
Corporate Services Agency

Obrzeżna 7, 02-691 Warszawa
tel. +48 22 699 52 17
fax +48 22 857 99 86
tel. mob. +48 501 501 030

 Czy musisz drukować tę wiadomość? Pomyśl o środowisku.
__________________________________________________________________
Treść tej wiadomości jest własnością Orange Polska i zawiera informacje stanowiące tajemnicę przedsiębiorstwa Orange Polska. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę, prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. Orange Polska Spółka Akcyjna z siedzibą i adresem w Warszawie (02-326) przy Al. Jerozolimskich 160, wpisana do Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy dla m.st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 0000010681; REGON 012100784, NIP 526-02-50-995; z pokrytym w całości kapitałem zakładowym wynoszącym 3.937.072.437 złotych.


-----Original Message-----
From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of ZWARICO, AMY
Sent: Wednesday, June 5, 2019 11:14 PM
To: k.opasiak@...; CLOSE, PIERRE; onap-seccom@...
Subject: Re: [Onap-seccom] Runtime Online dependency - recommendation proposal

Very nice.

I made minor wording changes to slides 1,4,5,6 The only substantive changes: in all of the nonfunctional requirements I changed "should" to "shall", which makes the requirement stronger.

-Amy
-----Original Message-----
From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of Krzysztof Opasiak via Lists.Onap.Org
Sent: Wednesday, June 05, 2019 4:01 PM
To: CLOSE, PIERRE <pierre.close@...>; onap-seccom@...
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] Runtime Online dependency - recommendation proposal



On 05.06.2019 15:58, Close, Pierre wrote:
Hello Krzysztof,

It probably makes more sense to merge the two, if you don't mind, since they aim to achieve the same goal, and so that there is a centralized recommendation.
I tried to merged your remarks into the presentation, you can see the result in attachment.

Feel free to comment & modify.

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













_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: Communication matrix

natacha.mach@...
 

Hello,

many thanks for your feedback.
Your remark is really relevant, indeed the  “external communication” is related to “platform external” components also.
So i will add a tag regarding the hosting of TLS server or TLS client, as attached.
What do you think of this new version?

regards
natacha

De : onap-seccom@... [onap-seccom@...] de la part de Hampus Tjader [hampus.tjader@...]
Envoyé : mercredi 26 juin 2019 13:55
À : MACH Natacha TGI/OLS; onap-seccom@...
Objet : Re: [Onap-seccom] Communication matrix

Hi Natacha,

 

Great work with the matrix!

 

I have a question regarding the “external communication”. My assumption is that this category will also be used for “platform external” components, e.g say between DCAE-yyy and xNF.

Does the “communication_initiator” in this case then define the entity acting as TLS server or is it more related to who is initiating the connection (not related to TLS handshake)?  
Could be interesting to highlight this for platform-external interfaces, thus whether external facing ONAP components are hosting a TLS server or TLS client. It would also be good from a security perspective to have this inventory of platform-externally open ports for the ONAP components, so we in the future might be able to decrease the platform external attack vector.

 

Best regards,

Hampus

 

From: onap-seccom@... <onap-seccom@...> On Behalf Of natacha.mach via Lists.Onap.Org
Sent: den 25 juni 2019 16:46
To: onap-seccom@...
Cc: onap-seccom@...
Subject: [Onap-seccom] Communication matrix

 

Hello,

 

As discussed during the SECCOM of last week, i am sharing with you a proposal regarding the YAML file for the communication matrix work item.

 

Please share your comments, and then we can propose it to the PTLs.

 

Many thanks and best regards

Natacha

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: next steps with CII -- back to [crypto_certificate_verification]:

Tony Hansen
 

Thank you, Natacha, for your comments. I also listened to the conversation on this week’s SECCOM meeting, which I unfortunately had to miss.

 

To summarize the concerns brought up:

  • The CII question is ambiguous and could be read as meaning that using SSL instead of TLS would lead to a N/A answer.
  • We really need to be mandating that projects use TLS in place of SSL.

 

I definitely can see how the question COULD be read that way, so agree that it is ambiguous.

 

The fun thing is that, when there are ambiguities, WE (the SECCOM) get to decide how to interpret it. So my proposal is:

 

  • If a remote site supports SSL, they are covered by this question.

 

(I’ve also filed a github ticket on the CII code about the ambiguity.)

 

Now I know that some of you are probably asking yourselves, but what about the other concern?

 

There are two aspects to the concern, though.

 

  1. We do not control >>remote sites<< that ONAP connects to, so cannot mandate anything about them. We can guarantee that we do certificate verification even when the remote end only does SSL, and we can try to put pressure on them to upgrade. But we don’t control much more.

 

  1. We CAN do things with our own software. For these, though, I think they are adequately covered by other CII issues. In particular:

 

crypto_tls12

The software produced by the project SHOULD/MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select 'not applicable' (N/A).

 

crypto_used_network

The software produced by the project SHOULD/MUST support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network comunications, select 'not applicable' (N/A).

 

Both of these are SHOULD questions at the Silver level, and MUST questions at the Gold level.

 

Do we think that these are worth focusing on next? Since they keep coming up, I think this should be the order of the next 6 weeks’ worth of focus topics.

 

CII Badging Focus Topics order

  1. crypto_certificate_verification

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

  1. crypto_used_network

The software produced by the project SHOULD support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network comunications, select 'not applicable' (N/A).

  1. crypto_tls12

The software produced by the project MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select 'not applicable' (N/A).

  1. crypto_credential_agility

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

  1. crypto_verification_private

The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select 'not applicable' (N/A).

 

I’ll post updated slides shortly with the ambiguity dealt with.

 

                Tony

 

From: "natacha.mach@..." <natacha.mach@...>
Date: Tuesday, June 25, 2019 at 10:42 AM
To: "HANSEN, TONY L" <tony@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>, "onap-seccom@..." <onap-seccom@...>
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: RE:[Onap-seccom] next steps with CII -- focus on crypto_credential_agility

 

Hello,

 

Many thanks for your answer.

 

Regarding the following statement: 

"The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A)."

 

==> the "not applicable", in my understanding / opinion should not be possible.

TLS should be mandatory, with no other option. If TLS is not possible then the solution is not comptible and the statement unmet.

 

What do you think?

 

best regards

Natacha

 


De : HANSEN, TONY L [tony@...]
Envoyé : jeudi 20 juin 2019 14:27
À : MACH Natacha TGI/OLS; GATHMAN, JONATHAN C; onap-seccom@...
Cc : PAWLAK Pawel O-PL; ZWARICO, AMY; CLOSE, PIERRE
Objet : Re: [Onap-seccom] next steps with CII -- focus on crypto_credential_agility

Thank you for your email, Natacha.

 

These are both very important considerations, and they are covered under other CII topics:

 

The comment about hashing passwords is covered under the CII topic [crypto_password_storage]:

 

If the software produced by the project causes the storing of passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., PBKDF2, Bcrypt or Scrypt).

 

The comment about TLS certification verification is covered under the CII topic [crypto_certificate_verification]:

 

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

 

There is another thread on the [onap-seccom] mailing list that is focusing on the [crypto_certificate_verification] CII topic. Please take a look there and make sure that your concerns regarding certification verification are being sufficiently addressed.

 

Thank you again for your email, Natacha.

 

                Tony

 

From: "natacha.mach@..." <natacha.mach@...>
Date: Thursday, June 20, 2019 at 5:41 AM
To: "HANSEN, TONY L" <tony@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>, "onap-seccom@..." <onap-seccom@...>
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: RE:[Onap-seccom] next steps with CII -- focus on crypto_credential_agility

 

Hello 

 

Thanks for these informations.

 

i have 2 comments / questions:

- The storage of password must be hashed.

- regarding the following statement:

If your project software uses TLS, but its default mode is NOT to do certificate verification against a locally maintained list of Certificate Authority certificates.

  • Click [Unmet]
  • FILE A JIRA against your project
  • In the description, explain what you don’t do
  • Include the current date at the end of your explanation, as in [2019/06/24]
  • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
  • Include the JIRA ticket number(s) in your answer.

 

==> is TLS is available, the certificate verification should be mandatory.

 

What do you think?

 

Regards

Natacha

 

 

 

 

 


De : onap-seccom@... [onap-seccom@...] de la part de Tony Hansen [tony@...]
Envoyé : jeudi 20 juin 2019 05:34
À : GATHMAN, JONATHAN C; onap-seccom@...
Cc : PAWLAK Pawel O-PL; ZWARICO, AMY; CLOSE, PIERRE
Objet : Re: [Onap-seccom] next steps with CII -- focus on crypto_credential_agility

This message focuses on [crypto_credential_agility].

 

Reminder about the CII text:

 

[crypto_credential_agility]

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

 

My take is that this one covers both the credentials needed to access remote services by the application AND the credentials used for authentication of others connecting to the application.

 

  1. Correct, no hard coding of passwords within the source code.
  2. Good questions on containers. I’m not sure what the answers are.
    1. Kubernetes secrets would probably satisfy the requirement.
  1. It seems that AAF would be a perfectly reasonable way to satisfy this requirement.

 

One aspect is that if you have passwords (or hashes of the passwords, etc), should be saved in the a different file from where other configuration values are stored.

 

Additional discussion is welcome.

 

                Tony

 

From: "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Date: Wednesday, June 19, 2019 at 6:45 AM
To: "HANSEN, TONY L" <tony@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII

 

Question(s), Tony,

 

. . .

 

Agility

1.      Are you talking about storing Credentials, etc, of the App itself, or Clients

a.      By “Compile” are you talking about not Hard Coding Passwords in Source (i.e. .js, java, .c, .cpp, whatever) files.

b.      Or are we realizing that Containers essentially Freeze what used to be dynamic configs, so you have to plan for updates.

                                                      i.      Does “Use docker/kubectl Container Copy instructions” meet this goal?

                                                    ii.      The constant Top priority of “Start from Scratch” makes this difficult, of course.

c.       If Client Creds, it should be pointed out that Apps can use Externalization of Client Creds, which is, of course, the point of AAF (sorry for the plug)

 

. . .

     

 

-- 

Jonathan Gathman

Principled-System Architect

ATO Tech Dev/SEAT/Platform Architecture and Technology Management

 

AT&T Services, Inc.

m  314-550-3312  |  jonathan.gathman@...

 

 

From: "HANSEN, TONY L" <tony@...>
Date: Tuesday, June 18, 2019 at 11:49 AM
To: "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Subject: next steps with CII

 

Here are the next few items that I think we need to work on with respect to moving forward with CII badging. These three have lots of projects marked [?] under the Silver level.

 

[crypto_certificate_verification]

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

 

[crypto_credential_agility]

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

 

[crypto_verification_private]

The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select 'not applicable' (N/A).

 

As discussed at DDF, the idea is that we would

 

Week 1

Introduce a topic at the PTL meeting with instructions.

We give stats on how many projects that have answered this question already.

Week 2

One week later, we check to see what progress there is.

Give kudos to those who have made progress.

We file JIRA tickets on those projects that have not given any answer.

Introduce the next topic, etc

Week 3

We bump up the priority on those tickets.

 

So, for next week’s meeting, here are instructions for [crypto certificate verification]. Comments are welcome.

 

  • This week’s CII issue is

[crypto_certificate_verification]

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, but its default mode is NOT to do certificate verification against a locally maintained list of Certificate Authority certificates.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.
    • If some of your software meets the above but other parts do not:
      • Select [Unmet]
      • Include an explanation in the description for each part, following the above instructions.
    • If some of your software meets the above, but other parts do not use TLS,
      • Select [Met]
      • Include an explanation in the description for each part, following the aboe instructions.
  • VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: next steps with CII -- back to [crypto_certificate_verification]:

Tony Hansen
 

Here are updated slides from what Pawel showed on Tuesday. These are intended to be shared on the PTL meeting next Monday. If you have any comments, PLEASE share them.

 

Thank you.

 

                Tony

 

From: "HANSEN, TONY L" <tony@...>
Date: Thursday, June 27, 2019 at 12:31 PM
To: "natacha.mach@..." <natacha.mach@...>, "onap-seccom@..." <onap-seccom@...>
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Subject: Re: [Onap-seccom] next steps with CII -- back to [crypto_certificate_verification]:

 

Thank you, Natacha, for your comments. I also listened to the conversation on this week’s SECCOM meeting, which I unfortunately had to miss.

 

To summarize the concerns brought up:

  • The CII question is ambiguous and could be read as meaning that using SSL instead of TLS would lead to a N/A answer.
  • We really need to be mandating that projects use TLS in place of SSL.

 

I definitely can see how the question COULD be read that way, so agree that it is ambiguous.

 

The fun thing is that, when there are ambiguities, WE (the SECCOM) get to decide how to interpret it. So my proposal is:

 

  • If a remote site supports SSL, they are covered by this question.

 

(I’ve also filed a github ticket on the CII code about the ambiguity.)

 

Now I know that some of you are probably asking yourselves, but what about the other concern?

 

There are two aspects to the concern, though.

 

  1. We do not control >>remote sites<< that ONAP connects to, so cannot mandate anything about them. We can guarantee that we do certificate verification even when the remote end only does SSL, and we can try to put pressure on them to upgrade. But we don’t control much more.

 

  1. We CAN do things with our own software. For these, though, I think they are adequately covered by other CII issues. In particular:

 

crypto_tls12

The software produced by the project SHOULD/MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select 'not applicable' (N/A).

 

crypto_used_network

The software produced by the project SHOULD/MUST support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network comunications, select 'not applicable' (N/A).

 

Both of these are SHOULD questions at the Silver level, and MUST questions at the Gold level.

 

Do we think that these are worth focusing on next? Since they keep coming up, I think this should be the order of the next 6 weeks’ worth of focus topics.

 

CII Badging Focus Topics order

  1. crypto_certificate_verification

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

  1. crypto_used_network

The software produced by the project SHOULD support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network comunications, select 'not applicable' (N/A).

  1. crypto_tls12

The software produced by the project MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select 'not applicable' (N/A).

  1. crypto_credential_agility

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

  1. crypto_verification_private

The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select 'not applicable' (N/A).

 

I’ll post updated slides shortly with the ambiguity dealt with.

 

                Tony

 

From: "natacha.mach@..." <natacha.mach@...>
Date: Tuesday, June 25, 2019 at 10:42 AM
To: "HANSEN, TONY L" <tony@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>, "onap-seccom@..." <onap-seccom@...>
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: RE:[Onap-seccom] next steps with CII -- focus on crypto_credential_agility

 

Hello,

 

Many thanks for your answer.

 

Regarding the following statement: 

"The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A)."

 

==> the "not applicable", in my understanding / opinion should not be possible.

TLS should be mandatory, with no other option. If TLS is not possible then the solution is not comptible and the statement unmet.

 

What do you think?

 

best regards

Natacha

 


De : HANSEN, TONY L [tony@...]
Envoyé : jeudi 20 juin 2019 14:27
À : MACH Natacha TGI/OLS; GATHMAN, JONATHAN C; onap-seccom@...
Cc : PAWLAK Pawel O-PL; ZWARICO, AMY; CLOSE, PIERRE
Objet : Re: [Onap-seccom] next steps with CII -- focus on crypto_credential_agility

Thank you for your email, Natacha.

 

These are both very important considerations, and they are covered under other CII topics:

 

The comment about hashing passwords is covered under the CII topic [crypto_password_storage]:

 

If the software produced by the project causes the storing of passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., PBKDF2, Bcrypt or Scrypt).

 

The comment about TLS certification verification is covered under the CII topic [crypto_certificate_verification]:

 

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

 

There is another thread on the [onap-seccom] mailing list that is focusing on the [crypto_certificate_verification] CII topic. Please take a look there and make sure that your concerns regarding certification verification are being sufficiently addressed.

 

Thank you again for your email, Natacha.

 

                Tony

 

From: "natacha.mach@..." <natacha.mach@...>
Date: Thursday, June 20, 2019 at 5:41 AM
To: "HANSEN, TONY L" <tony@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>, "onap-seccom@..." <onap-seccom@...>
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: RE:[Onap-seccom] next steps with CII -- focus on crypto_credential_agility

 

Hello 

 

Thanks for these informations.

 

i have 2 comments / questions:

- The storage of password must be hashed.

- regarding the following statement:

If your project software uses TLS, but its default mode is NOT to do certificate verification against a locally maintained list of Certificate Authority certificates.

  • Click [Unmet]
  • FILE A JIRA against your project
  • In the description, explain what you don’t do
  • Include the current date at the end of your explanation, as in [2019/06/24]
  • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
  • Include the JIRA ticket number(s) in your answer.

 

==> is TLS is available, the certificate verification should be mandatory.

 

What do you think?

 

Regards

Natacha

 

 

 

 

 


De : onap-seccom@... [onap-seccom@...] de la part de Tony Hansen [tony@...]
Envoyé : jeudi 20 juin 2019 05:34
À : GATHMAN, JONATHAN C; onap-seccom@...
Cc : PAWLAK Pawel O-PL; ZWARICO, AMY; CLOSE, PIERRE
Objet : Re: [Onap-seccom] next steps with CII -- focus on crypto_credential_agility

This message focuses on [crypto_credential_agility].

 

Reminder about the CII text:

 

[crypto_credential_agility]

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

 

My take is that this one covers both the credentials needed to access remote services by the application AND the credentials used for authentication of others connecting to the application.

 

  1. Correct, no hard coding of passwords within the source code.
  2. Good questions on containers. I’m not sure what the answers are.
    1. Kubernetes secrets would probably satisfy the requirement.
  1. It seems that AAF would be a perfectly reasonable way to satisfy this requirement.

 

One aspect is that if you have passwords (or hashes of the passwords, etc), should be saved in the a different file from where other configuration values are stored.

 

Additional discussion is welcome.

 

                Tony

 

From: "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Date: Wednesday, June 19, 2019 at 6:45 AM
To: "HANSEN, TONY L" <tony@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII

 

Question(s), Tony,

 

. . .

 

Agility

1.      Are you talking about storing Credentials, etc, of the App itself, or Clients

a.      By “Compile” are you talking about not Hard Coding Passwords in Source (i.e. .js, java, .c, .cpp, whatever) files.

b.      Or are we realizing that Containers essentially Freeze what used to be dynamic configs, so you have to plan for updates.

                                                      i.      Does “Use docker/kubectl Container Copy instructions” meet this goal?

                                                    ii.      The constant Top priority of “Start from Scratch” makes this difficult, of course.

c.       If Client Creds, it should be pointed out that Apps can use Externalization of Client Creds, which is, of course, the point of AAF (sorry for the plug)

 

. . .

     

 

-- 

Jonathan Gathman

Principled-System Architect

ATO Tech Dev/SEAT/Platform Architecture and Technology Management

 

AT&T Services, Inc.

m  314-550-3312  |  jonathan.gathman@...

 

 

From: "HANSEN, TONY L" <tony@...>
Date: Tuesday, June 18, 2019 at 11:49 AM
To: "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Subject: next steps with CII

 

Here are the next few items that I think we need to work on with respect to moving forward with CII badging. These three have lots of projects marked [?] under the Silver level.

 

[crypto_certificate_verification]

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

 

[crypto_credential_agility]

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

 

[crypto_verification_private]

The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select 'not applicable' (N/A).

 

As discussed at DDF, the idea is that we would

 

Week 1

Introduce a topic at the PTL meeting with instructions.

We give stats on how many projects that have answered this question already.

Week 2

One week later, we check to see what progress there is.

Give kudos to those who have made progress.

We file JIRA tickets on those projects that have not given any answer.

Introduce the next topic, etc

Week 3

We bump up the priority on those tickets.

 

So, for next week’s meeting, here are instructions for [crypto certificate verification]. Comments are welcome.

 

  • This week’s CII issue is

[crypto_certificate_verification]

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, but its default mode is NOT to do certificate verification against a locally maintained list of Certificate Authority certificates.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.
    • If some of your software meets the above but other parts do not:
      • Select [Unmet]
      • Include an explanation in the description for each part, following the above instructions.
    • If some of your software meets the above, but other parts do not use TLS,
      • Select [Met]
      • Include an explanation in the description for each part, following the aboe instructions.
  • VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: next steps with CII -- back to [crypto_certificate_verification]:

Amy Zwarico
 

Very nice deck.

I suggest adding the following checks which are part of certificate validation:

1.      Check that the cert is still within its validity period.

2.      Perform the cryptography to ensure that the sender of the cert possesses the private key

For extra credit, the cert should be checked against a Certificate Revocation List (CRL).

 

From: HANSEN, TONY L
Sent: Friday, June 28, 2019 3:57 PM
To: natacha.mach@...; onap-seccom@...
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>; ZWARICO, AMY <az9121@...>; CLOSE, PIERRE <pierre.close@...>; GATHMAN, JONATHAN C <jonathan.gathman@...>
Subject: Re: [Onap-seccom] next steps with CII -- back to [crypto_certificate_verification]:

 

Here are updated slides from what Pawel showed on Tuesday. These are intended to be shared on the PTL meeting next Monday. If you have any comments, PLEASE share them.

 

Thank you.

 

                Tony

 

From: "HANSEN, TONY L" <tony@...>
Date: Thursday, June 27, 2019 at 12:31 PM
To: "natacha.mach@..." <natacha.mach@...>, "onap-seccom@..." <onap-seccom@...>
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Subject: Re: [Onap-seccom] next steps with CII -- back to [crypto_certificate_verification]:

 

Thank you, Natacha, for your comments. I also listened to the conversation on this week’s SECCOM meeting, which I unfortunately had to miss.

 

To summarize the concerns brought up:

  • The CII question is ambiguous and could be read as meaning that using SSL instead of TLS would lead to a N/A answer.
  • We really need to be mandating that projects use TLS in place of SSL.

 

I definitely can see how the question COULD be read that way, so agree that it is ambiguous.

 

The fun thing is that, when there are ambiguities, WE (the SECCOM) get to decide how to interpret it. So my proposal is:

 

  • If a remote site supports SSL, they are covered by this question.

 

(I’ve also filed a github ticket on the CII code about the ambiguity.)

 

Now I know that some of you are probably asking yourselves, but what about the other concern?

 

There are two aspects to the concern, though.

 

  1. We do not control >>remote sites<< that ONAP connects to, so cannot mandate anything about them. We can guarantee that we do certificate verification even when the remote end only does SSL, and we can try to put pressure on them to upgrade. But we don’t control much more.

 

  1. We CAN do things with our own software. For these, though, I think they are adequately covered by other CII issues. In particular:

 

crypto_tls12

The software produced by the project SHOULD/MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select 'not applicable' (N/A).

 

crypto_used_network

The software produced by the project SHOULD/MUST support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network comunications, select 'not applicable' (N/A).

 

Both of these are SHOULD questions at the Silver level, and MUST questions at the Gold level.

 

Do we think that these are worth focusing on next? Since they keep coming up, I think this should be the order of the next 6 weeks’ worth of focus topics.

 

CII Badging Focus Topics order

1)      crypto_certificate_verification

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

2)      crypto_used_network

The software produced by the project SHOULD support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network comunications, select 'not applicable' (N/A).

3)      crypto_tls12

The software produced by the project MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select 'not applicable' (N/A).

4)      crypto_credential_agility

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

5)      crypto_verification_private

The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select 'not applicable' (N/A).

 

I’ll post updated slides shortly with the ambiguity dealt with.

 

                Tony

 

From: "natacha.mach@..." <natacha.mach@...>
Date: Tuesday, June 25, 2019 at 10:42 AM
To: "HANSEN, TONY L" <tony@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>, "onap-seccom@..." <onap-seccom@...>
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: RE:[Onap-seccom] next steps with CII -- focus on crypto_credential_agility

 

Hello,

 

Many thanks for your answer.

 

Regarding the following statement: 

"The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A)."

 

==> the "not applicable", in my understanding / opinion should not be possible.

TLS should be mandatory, with no other option. If TLS is not possible then the solution is not comptible and the statement unmet.

 

What do you think?

 

best regards

Natacha

 


De : HANSEN, TONY L [tony@...]
Envoyé : jeudi 20 juin 2019 14:27
À : MACH Natacha TGI/OLS; GATHMAN, JONATHAN C; onap-seccom@...
Cc : PAWLAK Pawel O-PL; ZWARICO, AMY; CLOSE, PIERRE
Objet : Re: [Onap-seccom] next steps with CII -- focus on crypto_credential_agility

Thank you for your email, Natacha.

 

These are both very important considerations, and they are covered under other CII topics:

 

The comment about hashing passwords is covered under the CII topic [crypto_password_storage]:

 

If the software produced by the project causes the storing of passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., PBKDF2, Bcrypt or Scrypt).

 

The comment about TLS certification verification is covered under the CII topic [crypto_certificate_verification]:

 

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

 

There is another thread on the [onap-seccom] mailing list that is focusing on the [crypto_certificate_verification] CII topic. Please take a look there and make sure that your concerns regarding certification verification are being sufficiently addressed.

 

Thank you again for your email, Natacha.

 

                Tony

 

From: "natacha.mach@..." <natacha.mach@...>
Date: Thursday, June 20, 2019 at 5:41 AM
To: "HANSEN, TONY L" <tony@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>, "onap-seccom@..." <onap-seccom@...>
Cc: PAWLAK Pawel O-PL <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: RE:[Onap-seccom] next steps with CII -- focus on crypto_credential_agility

 

Hello 

 

Thanks for these informations.

 

i have 2 comments / questions:

- The storage of password must be hashed.

- regarding the following statement:

If your project software uses TLS, but its default mode is NOT to do certificate verification against a locally maintained list of Certificate Authority certificates.

  • Click [Unmet]
  • FILE A JIRA against your project
  • In the description, explain what you don’t do
  • Include the current date at the end of your explanation, as in [2019/06/24]
  • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
  • Include the JIRA ticket number(s) in your answer.

 

==> is TLS is available, the certificate verification should be mandatory.

 

What do you think?

 

Regards

Natacha

 

 

 

 

 


De : onap-seccom@... [onap-seccom@...] de la part de Tony Hansen [tony@...]
Envoyé : jeudi 20 juin 2019 05:34
À : GATHMAN, JONATHAN C; onap-seccom@...
Cc : PAWLAK Pawel O-PL; ZWARICO, AMY; CLOSE, PIERRE
Objet : Re: [Onap-seccom] next steps with CII -- focus on crypto_credential_agility

This message focuses on [crypto_credential_agility].

 

Reminder about the CII text:

 

[crypto_credential_agility]

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

 

My take is that this one covers both the credentials needed to access remote services by the application AND the credentials used for authentication of others connecting to the application.

 

  1. Correct, no hard coding of passwords within the source code.
  2. Good questions on containers. I’m not sure what the answers are.
    1. Kubernetes secrets would probably satisfy the requirement.
  1. It seems that AAF would be a perfectly reasonable way to satisfy this requirement.

 

One aspect is that if you have passwords (or hashes of the passwords, etc), should be saved in the a different file from where other configuration values are stored.

 

Additional discussion is welcome.

 

                Tony

 

From: "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Date: Wednesday, June 19, 2019 at 6:45 AM
To: "HANSEN, TONY L" <tony@...>, "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>
Subject: Re: next steps with CII

 

Question(s), Tony,

 

. . .

 

Agility

1.      Are you talking about storing Credentials, etc, of the App itself, or Clients

a.      By “Compile” are you talking about not Hard Coding Passwords in Source (i.e. .js, java, .c, .cpp, whatever) files.

b.      Or are we realizing that Containers essentially Freeze what used to be dynamic configs, so you have to plan for updates.

                                                      i.      Does “Use docker/kubectl Container Copy instructions” meet this goal?

                                                    ii.      The constant Top priority of “Start from Scratch” makes this difficult, of course.

c.       If Client Creds, it should be pointed out that Apps can use Externalization of Client Creds, which is, of course, the point of AAF (sorry for the plug)

 

. . .

     

 

-- 

Jonathan Gathman

Principled-System Architect

ATO Tech Dev/SEAT/Platform Architecture and Technology Management

 

AT&T Services, Inc.

m  314-550-3312  |  jonathan.gathman@...

 

 

From: "HANSEN, TONY L" <tony@...>
Date: Tuesday, June 18, 2019 at 11:49 AM
To: "onap-seccom@..." <onap-seccom@...>
Cc: Pawlak Paweł 3 - Korpo <pawel.pawlak3@...>, "ZWARICO, AMY" <az9121@...>, "CLOSE, PIERRE" <pierre.close@...>, "GATHMAN, JONATHAN C" <jonathan.gathman@...>
Subject: next steps with CII

 

Here are the next few items that I think we need to work on with respect to moving forward with CII badging. These three have lots of projects marked [?] under the Silver level.

 

[crypto_certificate_verification]

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

 

[crypto_credential_agility]

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

 

[crypto_verification_private]

The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select 'not applicable' (N/A).

 

As discussed at DDF, the idea is that we would

 

Week 1

Introduce a topic at the PTL meeting with instructions.

We give stats on how many projects that have answered this question already.

Week 2

One week later, we check to see what progress there is.

Give kudos to those who have made progress.

We file JIRA tickets on those projects that have not given any answer.

Introduce the next topic, etc

Week 3

We bump up the priority on those tickets.

 

So, for next week’s meeting, here are instructions for [crypto certificate verification]. Comments are welcome.

 

  • This week’s CII issue is

[crypto_certificate_verification]

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

  • Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
  • Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
  • Click the [Edit] button at the top.
  • Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
  • This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.
    • If your project software does not make any external API calls, then select “not applicable”
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes its architecture.
    • If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.
      • Click the [N/A] button
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.
      • Click [Met]
      • In the description, explain that you do not have any external API calls.
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
    • If your project software uses TLS, but its default mode is NOT to do certificate verification against a locally maintained list of Certificate Authority certificates.
      • Click [Unmet]
      • FILE A JIRA against your project
      • In the description, explain what you don’t do
      • Include the current date at the end of your explanation, as in [2019/06/24]
      • Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
      • Include the JIRA ticket number(s) in your answer.
    • If some of your software meets the above but other parts do not:
      • Select [Unmet]
      • Include an explanation in the description for each part, following the above instructions.
    • If some of your software meets the above, but other parts do not use TLS,
      • Select [Met]
      • Include an explanation in the description for each part, following the aboe instructions.
  • VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: Communication matrix

Harald Fuchs
 

Hi Natacha,

I think this is a really good format and excellent outcome.

So far I have only minor “semantic” comments, but admit I’m no native speaker :-).

So I would change the “outcoming” to “outgoing” and the incoming_outcoming tag to “direction” or something similar especially as there is a third value possible.

KR

Harald

 

 

From: onap-seccom@... <onap-seccom@...> On Behalf Of natacha.mach via Lists.Onap.Org
Sent: 27 June, 2019 17:27
To: Hampus Tjader <hampus.tjader@...>; onap-seccom@...
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] Communication matrix

 

Hello,

 

many thanks for your feedback.

Your remark is really relevant, indeed the  “external communication” is related to “platform external” components also.

So i will add a tag regarding the hosting of TLS server or TLS client, as attached.

What do you think of this new version?

 

regards

natacha


De : onap-seccom@... [onap-seccom@...] de la part de Hampus Tjader [hampus.tjader@...]
Envoyé : mercredi 26 juin 2019 13:55
À : MACH Natacha TGI/OLS; onap-seccom@...
Objet : Re: [Onap-seccom] Communication matrix

Hi Natacha,

 

Great work with the matrix!

 

I have a question regarding the “external communication”. My assumption is that this category will also be used for “platform external” components, e.g say between DCAE-yyy and xNF.

Does the “communication_initiator” in this case then define the entity acting as TLS server or is it more related to who is initiating the connection (not related to TLS handshake)?  
Could be interesting to highlight this for platform-external interfaces, thus whether external facing ONAP components are hosting a TLS server or TLS client. It would also be good from a security perspective to have this inventory of platform-externally open ports for the ONAP components, so we in the future might be able to decrease the platform external attack vector.

 

Best regards,

Hampus

 

From: onap-seccom@... <onap-seccom@...> On Behalf Of natacha.mach via Lists.Onap.Org
Sent: den 25 juni 2019 16:46
To: onap-seccom@...
Cc: onap-seccom@...
Subject: [Onap-seccom] Communication matrix

 

Hello,

 

As discussed during the SECCOM of last week, i am sharing with you a proposal regarding the YAML file for the communication matrix work item.

 

Please share your comments, and then we can propose it to the PTLs.

 

Many thanks and best regards

Natacha

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

ONAP Dublin - Please update your JIRA tickets accordingly

Catherine LEFEVRE
 

Good morning ONAP Security Subcommittee, Jim,

 

Can you please review and update the following JIRA tickets accordingly considering that the Dublin Release is not completed?

 

 

+ 24 Tickets OJSI

 

Jira query:

status != Closed AND status != Done AND project != "Sandbox Project" AND project != CI-Management AND project != "ONAP TSC" AND fixVersion = "Dublin Release" AND project = OJSI ORDER BY key ASC, priority DESC, updated DESC

 

Many thanks & regards

Catherine

 

Catherine Lefèvre

AVP Software Development & Engineering

 

AT&T Labs – Network Cloud & Infrastructure

D2 Platform & Systems Development

ECOMP/RUBY/SPP-NEAM-Appl. Servers/SIA

ONAP TSC Chair

 

 

Phone: +32 81 84 09 08

Mobile: +32 475 77 36 73

catherine.lefevre@...

 

TEXTING and DRIVING… It Can Wait

AT&T

BUROGEST OFFICE PARK SA

Avenue des Dessus-de-Lives, 2

5101 Loyers (Namur)

Belgium

 

 

NOTE: This email (or its attachments) contains information belonging to the sender, which may be confidential. proprietary and/or legally privileged. The information is intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, you are hereby notified that any disclosure, distribution or taking of any action in reliance on the content of this is strictly forbidden. If you have received this e-mail in error please immediately notify the sender identified above

 

Re: ONAP Dublin - Please update your JIRA tickets accordingly

Krzysztof Opasiak
 

Dear Catherine and Jim,


On 05.07.2019 11:34, Catherine LEFEVRE wrote:
Good morning ONAP Security Subcommittee, Jim,
Can you please review and update the following JIRA tickets accordingly considering that the Dublin Release is not completed?
+ 24 Tickets OJSI
Jira query:
status != Closed AND status != Done AND project != "Sandbox Project" AND project != CI-Management AND project != "ONAP TSC" AND fixVersion = "Dublin Release" AND project = OJSI ORDER BY key ASC, priority DESC, updated DESC
I've put together some dashboard to help you better underestand the current status of OJSI tickets:

https://wiki.onap.org/display/DW/OJSI+Tickets+Status

I'll provide some more details on it during Monday PTL call.

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

Re: ONAP Dublin - Please update your JIRA tickets accordingly

Catherine LEFEVRE
 

Thank you so much Krzysztof

-----Original Message-----
From: Krzysztof Opasiak [mailto:k.opasiak@...]
Sent: Friday, July 05, 2019 10:54 PM
To: Lefevre, Catherine <catherine.lefevre@...>; onap-seccom@...; jbaker@...
Subject: Re: [Onap-seccom] ONAP Dublin - Please update your JIRA tickets accordingly

Dear Catherine and Jim,


On 05.07.2019 11:34, Catherine LEFEVRE wrote:
Good morning ONAP Security Subcommittee, Jim,

Can you please review and update the following JIRA tickets
accordingly considering that the Dublin Release is not completed?

+ 24 Tickets OJSI

Jira query:

status != Closed AND status != Done AND project != "Sandbox Project"
AND project != CI-Management AND project != "ONAP TSC" AND fixVersion
= "Dublin Release" AND project = OJSI ORDER BY key ASC, priority DESC,
updated DESC
I've put together some dashboard to help you better underestand the current status of OJSI tickets:

https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_OJSI-2BTickets-2BStatus&d=DwIC-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=ZglJ8LOeAfevY7wWaSximhFMAzXaMdza5QYCg-DW6SU&m=gYz6ii8Y9q-xaUM974QmxAztgyV1-ocVsGwL2t0rEEY&s=P0_mfCboP61Rz6CDUXufEFqMlhGMzK1F7WDHoFf4Ai8&e=

I'll provide some more details on it during Monday PTL call.

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

Re: Runtime Online dependency - recommendation proposal

Hampus Tjader
 

Hi,

 

I will not be able to attend the review meeting of 16th July due to my vacation. Please see the provided comments from my company in the attachment. We see the modification of N-3 requirement as an important update before final approval.

 

Best regards,

Hampus

 

 

 

Hampus Tjäder

4G5G Product Architecture O&M and Security

 

Ericsson

Datalinjen 4

58330, Linköping, Sweden

Mobile: +46 107113292

ericsson.com

 

 

 

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On Behalf Of Horn, Linda (Nokia - US/Murray Hill) via Lists.Onap.Org
Sent: den 26 juni 2019 14:31
To: Pawlak Paweł 3 - Korpo <Pawel.Pawlak3@...>
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] Runtime Online dependency - recommendation proposal

 

Pawel,

 

Before or after the SECCOM call on July 16 is fine with me - whichever is better for others.

 

Linda

-----------------------------------------------------------------------------------

Linda S. Horn, DMTS

Cloud RAN Solution Definition and Architecture

Mobile Networks, Nokia        

Phone:  +1-908-679-6580

 

-----Original Message-----

From: Pawlak Paweł 3 - Korpo <Pawel.Pawlak3@...>

Sent: Wednesday, June 26, 2019 3:02 AM

To: Horn, Linda (Nokia - US/Murray Hill) <linda.horn@...>

Cc: onap-seccom@...

Subject: RE: [Onap-seccom] Runtime Online dependency - recommendation proposal

 

Hello Linda,

Following the discussions below I would like to propose a dedicated call on 16th of July either before or after SECCOM meeting.

Please let us know your availabilities.

 

Best regards

 

Paweł Pawlak

 

ONAP SECCOM Chair

Leader in IT & Network Convergent Operations FT/TGI/OLN/QOP/OST

 

Orange Polska S.A.

Corporate Services Agency

 

Obrzeżna 7, 02-691 Warszawa

tel. +48 22 699 52 17

fax +48 22 857 99 86

tel. mob. +48 501 501 030

 

   Czy musisz drukować tę wiadomość? Pomyśl o środowisku.

__________________________________________________________________

Treść tej wiadomości jest własnością Orange Polska i zawiera informacje stanowiące tajemnicę przedsiębiorstwa Orange Polska. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę, prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. Orange Polska Spółka Akcyjna z siedzibą i adresem w Warszawie (02-326) przy Al. Jerozolimskich 160, wpisana do Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy dla m.st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 0000010681; REGON 012100784, NIP 526-02-50-995; z pokrytym w całości kapitałem zakładowym wynoszącym 3.937.072.437 złotych.

 

-----Original Message-----

From: Horn, Linda (Nokia - US/Murray Hill) [mailto:linda.horn@...]

Sent: Wednesday, June 12, 2019 9:18 PM

To: MACH Natacha TGI/OLS; ZWARICO, AMY; Pawlak Paweł 3 - Korpo; onap-seccom@...

Subject: RE: [Onap-seccom] Runtime Online dependency - recommendation proposal

 

Natacha,

 

Thank you for reviewing.  My comments are in the attached doc.  BTW there is a version v7 now but it has minor changes so your comments are still valid.

 

Linda

-----------------------------------------------------------------------------------

Linda S. Horn, DMTS

Cloud RAN Solution Definition and Architecture

Mobile Networks, Nokia        

Phone:  +1-908-679-6580

 

-----Original Message-----

From: onap-seccom@... <onap-seccom@...> On Behalf Of natacha.mach via Lists.Onap.Org

Sent: Friday, June 07, 2019 10:19 AM

To: ZWARICO, AMY <az9121@...>; PAWLAK Pawel O-PL <pawel.pawlak3@...>; onap-seccom@...

Cc: onap-seccom@...

Subject: Re: [Onap-seccom] Runtime Online dependency - recommendation proposal

 

hello,

 

Thanks for the comments, and here are some remarks for understanding first.

I hopr that we could discuss this document next week?

 

Regards

natacha

________________________________________

De : onap-seccom@... [onap-seccom@...] de la part de ZWARICO, AMY [az9121@...] Envoyé : jeudi 6 juin 2019 21:41 À : PAWLAK Pawel O-PL; onap-seccom@... Objet : Re: [Onap-seccom] Runtime Online dependency - recommendation proposal

 

I found another typo and made some other minor wording changes.

 

-----Original Message-----

From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of Pawel Pawlak via Lists.Onap.Org

Sent: Thursday, June 06, 2019 7:33 AM

To: onap-seccom@...

Cc: onap-seccom@...

Subject: Re: [Onap-seccom] Runtime Online dependency - recommendation proposal

 

I have corrected 2 typos...

Best regards

 

Paweł Pawlak

 

ONAP SECCOM Chair

Leader in IT & Network Convergent Operations FT/TGI/OLN/QOP/OST

 

Orange Polska S.A.

Corporate Services Agency

 

Obrzeżna 7, 02-691 Warszawa

tel. +48 22 699 52 17

fax +48 22 857 99 86

tel. mob. +48 501 501 030

 

   Czy musisz drukować tę wiadomość? Pomyśl o środowisku.

__________________________________________________________________

Treść tej wiadomości jest własnością Orange Polska i zawiera informacje stanowiące tajemnicę przedsiębiorstwa Orange Polska. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę, prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. Orange Polska Spółka Akcyjna z siedzibą i adresem w Warszawie (02-326) przy Al. Jerozolimskich 160, wpisana do Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy dla m.st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 0000010681; REGON 012100784, NIP 526-02-50-995; z pokrytym w całości kapitałem zakładowym wynoszącym 3.937.072.437 złotych.

 

 

-----Original Message-----

From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of ZWARICO, AMY

Sent: Wednesday, June 5, 2019 11:14 PM

To: k.opasiak@...; CLOSE, PIERRE; onap-seccom@...

Subject: Re: [Onap-seccom] Runtime Online dependency - recommendation proposal

 

Very nice.

 

I made minor wording changes to slides 1,4,5,6 The only substantive changes: in all of the nonfunctional requirements I changed "should" to "shall", which makes the requirement stronger.

 

-Amy

-----Original Message-----

From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of Krzysztof Opasiak via Lists.Onap.Org

Sent: Wednesday, June 05, 2019 4:01 PM

To: CLOSE, PIERRE <pierre.close@...>; onap-seccom@...

Cc: onap-seccom@...

Subject: Re: [Onap-seccom] Runtime Online dependency - recommendation proposal

 

 

 

On 05.06.2019 15:58, Close, Pierre wrote:

> Hello Krzysztof,

> It probably makes more sense to merge the two, if you don't mind, since they aim to achieve the same goal, and so that there is a centralized recommendation.

 

I tried to merged your remarks into the presentation, you can see the result in attachment.

 

Feel free to comment & modify.

 

Best regards,

--

Krzysztof Opasiak

Samsung R&D Institute Poland

Samsung Electronics

 

 

 

 

 

 

 

 

 

 

 

 

 

_________________________________________________________________________________________________________________________

 

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

 

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

 

 

 

 

 

 

 

ONAP/LFN/LF Code of Conduct

Amy Zwarico
 

We have a code of conduct! The LFN TAC adopted the resolution to reiterate the importance of adhering to a Code of Conduct. The LF Projects Code of Conduct available at https://lfprojects.org/policies/code-of-conduct/ applies to all LFN projects. Kenny Paul is going to add the CoC link to the ONAP wiki.

 

I’ve updated https://wiki.onap.org/display/DW/CII+Badging+Program to indicate that the answer to [code_of_conduct] is Met.

The project MUST adopt a code of conduct and post it in a standard location. (URL required) [code_of_conduct]

 

Catherine is going to announce it at the 7/11 TSC call and I’ll ask for time on the 7/15 PTL call to ask the PTLs to answer [code_of_conduct] MET in their CII Silver badge report.

 

​​​​​Amy Zwarico, LMTS

Chief Security Office / Emerging Services Security

AT&T Services

(205) 613-1667

 

"This e-mail and any files transmitted with it are the property of AT&T,  and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your electronic device. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited."

 

Remaining ONAP Dublin tickets & Security tickets

Catherine LEFEVRE
 

Good morning  Security Subcommittee,

 

We have currently 24 OJSI and 2 SECCOM JIRA items with the FixVersion set to Dublin Release.

Have we completed these items or do we need to update the FixVersion to El-Alto or Frankfurt?

How would like to proceed? thanks

 

Jira Query

OJSI: status != Closed AND status != Done AND project != "Sandbox Project" AND project != CI-Management AND project != "ONAP TSC" AND fixVersion = "Dublin Release" AND project = OJSI ORDER BY key ASC, priority DESC, updated DESC

 

SECCOM: status != Closed AND status != Done AND project != "Sandbox Project" AND project != CI-Management AND project != "ONAP TSC" AND fixVersion = "Dublin Release" AND project = SECCOM ORDER BY key ASC, priority DESC, updated DESC

 

Many thanks & regards

Catherine/Jim

 

Catherine Lefèvre

AVP Software Development & Engineering

 

AT&T Labs – Network Cloud & Infrastructure

D2 Platform & Systems Development

ECOMP/RUBY/SPP-NEAM-Appl. Servers/SIA

ONAP TSC Chair

 

 

Phone: +32 81 84 09 08

Mobile: +32 475 77 36 73

catherine.lefevre@...

 

TEXTING and DRIVING… It Can Wait

AT&T

BUROGEST OFFICE PARK SA

Avenue des Dessus-de-Lives, 2

5101 Loyers (Namur)

Belgium

 

 

NOTE: This email (or its attachments) contains information belonging to the sender, which may be confidential. proprietary and/or legally privileged. The information is intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, you are hereby notified that any disclosure, distribution or taking of any action in reliance on the content of this is strictly forbidden. If you have received this e-mail in error please immediately notify the sender identified above

 

Re: Remaining ONAP Dublin tickets & Security tickets

Krzysztof Opasiak
 

Hi Catherine,

On 11.07.2019 11:35, Catherine LEFEVRE wrote:
Good morning  Security Subcommittee,
We have currently 24 OJSI and 2 SECCOM JIRA items with the FixVersion set to Dublin Release.
Have we completed these items or do we need to update the FixVersion to El-Alto or Frankfurt?
How would like to proceed? thanks
/_Jira Query_/
OJSI: status != Closed AND status != Done AND project != "Sandbox Project" AND project != CI-Management AND project != "ONAP TSC" AND fixVersion = "Dublin Release" AND project = OJSI ORDER BY key ASC, priority DESC, updated DESC
For OJSI I'd propose to change query to the one that I used to generate a chart on our dashboard:

project = OJSI AND labels != TO_BE_REMOVED AND fixVersion = "Dublin Release" AND resolution = "\"Unresolved\"" ORDER BY priority DESC, updated DESC

This should give you only 10 issues and all of them have a temporary fix applied into Dublin and are waiting for a proper fix in El Alto. That's why they have fix version set to both of them. If you would like us to modify this to make it easier for you please let us know.

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

Re: Remaining ONAP Dublin tickets & Security tickets

Catherine LEFEVRE
 

Thank you Krzysztof - that makes sense

KR
Catherine

-----Original Message-----
From: Krzysztof Opasiak [mailto:k.opasiak@...]
Sent: Thursday, July 11, 2019 12:21 PM
To: Lefevre, Catherine <catherine.lefevre@...>; Jim Baker <jbaker@...>; onap-seccom@...
Subject: Re: [Onap-seccom] Remaining ONAP Dublin tickets & Security tickets

Hi Catherine,

On 11.07.2019 11:35, Catherine LEFEVRE wrote:
Good morning  Security Subcommittee,

We have currently 24 OJSI and 2 SECCOM JIRA items with the FixVersion
set to Dublin Release.

Have we completed these items or do we need to update the FixVersion
to El-Alto or Frankfurt?

How would like to proceed? thanks

/_Jira Query_/

OJSI: status != Closed AND status != Done AND project != "Sandbox
Project" AND project != CI-Management AND project != "ONAP TSC" AND
fixVersion = "Dublin Release" AND project = OJSI ORDER BY key ASC,
priority DESC, updated DESC
For OJSI I'd propose to change query to the one that I used to generate a chart on our dashboard:

project = OJSI AND labels != TO_BE_REMOVED AND fixVersion = "Dublin Release" AND resolution = "\"Unresolved\"" ORDER BY priority DESC, updated DESC

This should give you only 10 issues and all of them have a temporary fix applied into Dublin and are waiting for a proper fix in El Alto. That's why they have fix version set to both of them. If you would like us to modify this to make it easier for you please let us know.

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

FW: [confluence] Recommended in Confluence for Amy Zwarico - Jul 11, 2019

Amy Zwarico
 

The LFN has resolved that all its projects will follow the LF Projects Code of Conduct as written. SECCOM has been working to get a Code of Conduct decision in place for several months which is important because it is a requirement for the Silver CII badge

 

From: Recommended Updates (Confluence) [mailto:noreply@...]
Sent: Thursday, July 11, 2019 8:02 AM
To: ZWARICO, AMY <az9121@...>
Subject: [confluence] Recommended in Confluence for Amy Zwarico - Jul 11, 2019

 

 

 

Recommended in Confluence

Jul 11, 2019

 

 

Go to Confluence

 

 

 

Proposal to the TSC about CVEs ?

Catherine LEFEVRE
 

Good afternoon Security Subcommittee,

 

Few days ago I took an action to present a proposal to the ONAP TSC about CVEs.

I plan to have this topic on 7/18.

 

Here is the proposal that we started to elaborate on PTL call (7/1)

 

·        Within the 60 days period, the expectations are that the project team will address the CVE from a development and testing perspective.

It is understood that the resolution will immediately be candidate for the next candidate release i.e. early drop, minor or major release.

Exception can be raised on extra-ordinary issue but the purpose is to avoid that we perform one CVE on a daily/weekly basis.

If there is an emergency, people can always use the container available the “staging” repositories.

 

We also need to assess interdependencies between projects i.e.

#1 issue in portal SDK consumed by Policy, CLAMP, SDC etc.

#2 vulnerabilities fixed in oParent

...

Feedback from the project team will remain “key” to assess if potentially this resolution has an impact (or not) on another component, or the overall release.

 

·        Any critical CVE that has reached the 60 days period and was not fixed at M4 (code freeze) should be presented to the TSC for review including

SECCOM Recommendations, following similar process than the IP Legal issues.

The project team must also provide the reason why they could not meet the deadline and the nature of the risk.

If TSC does not provide a waiver then the impacted project team will need to build a recovery plan.

If TSC gives a waiver then it means that the TSC acknowledges the risk.

 

Many thanks and regards

Catherine

 

Catherine Lefèvre

AVP Software Development & Engineering

 

AT&T Labs – Network Cloud & Infrastructure

D2 Platform & Systems Development

ECOMP/RUBY/SPP-NEAM-Appl. Servers/SIA

ONAP TSC Chair

 

 

Phone: +32 81 84 09 08

Mobile: +32 475 77 36 73

catherine.lefevre@...

 

TEXTING and DRIVING… It Can Wait

AT&T

BUROGEST OFFICE PARK SA

Avenue des Dessus-de-Lives, 2

5101 Loyers (Namur)

Belgium

 

 

NOTE: This email (or its attachments) contains information belonging to the sender, which may be confidential. proprietary and/or legally privileged. The information is intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, you are hereby notified that any disclosure, distribution or taking of any action in reliance on the content of this is strictly forbidden. If you have received this e-mail in error please immediately notify the sender identified above

 

xNF Security Requirements for HTTPS

Amy Zwarico
 

 
-- Do not delete or change any of the following text. --  
 
 
Join Webex meeting  
Meeting number (access code): 735 723 800
Meeting password: 8mP4XdM@ 
 

Join from a video system or application
Dial 735723800@... 
You can also dial 173.243.2.68 and enter your meeting number.  
 
Join by phone 
Tap to call in from a mobile device (attendees only) 
1-844-517-1415 United States Toll Free 
1-618-230-6039 United States Toll 
Global call-in numbers  |  Toll-free calling restrictions  
 
 
Accessibility and Assistive Technologies  
Select this job aid for tips and guides to make Webex Meetings accessible to persons with disabilities who may rely on assistive technologies.
 
 
Can't join the meeting?
 
If you are a host, go here to view host information.

IMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.
 
 

Proposed policy for fixing vulnerabilities in the ONAP code base

Amy Zwarico
 

Please review the draft policy for fixing vulnerabilities in the ONAP code base based on the SECCOM discussion at the 7/2 meeting. I plan to present it to the PTLs on 7/15.

 

​​​​​Amy Zwarico, LMTS

Chief Security Office / Emerging Services Security

AT&T Services

(205) 613-1667

 

"This e-mail and any files transmitted with it are the property of AT&T,  and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your electronic device. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited."

 

VNF Security Requirements Refresh for El Alto

Amy Zwarico
 

Scheduling a series of recurring meetings to refresh the VNF security requirements as part of the El Alto release. Please forward the invitation to others in your organization who should participate.
 
-- Do not delete or change any of the following text. --  
 
 
Join Webex meeting  
Meeting number (access code): 738 361 518
Meeting password: xtppmX?3 
 

Join from a video system or application
Dial 738361518@... 
You can also dial 173.243.2.68 and enter your meeting number.  
 
Join by phone 
Tap to call in from a mobile device (attendees only) 
1-844-517-1415 United States Toll Free 
1-618-230-6039 United States Toll 
Global call-in numbers  |  Toll-free calling restrictions  
 
 
Accessibility and Assistive Technologies  
Select this job aid for tips and guides to make Webex Meetings accessible to persons with disabilities who may rely on assistive technologies.
 
 
Can't join the meeting?
 
If you are a host, go here to view host information.

IMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.