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

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

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

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

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

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."

Hi,

I will not be able to attend the review meeting of 16^th 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

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

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

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

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).

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

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

_________________________________________________________________________________________________________________________

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.

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

_________________________________________________________________________________________________________________________

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.

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