Date   

CIS Docker benchmark

Pawel Pawlak
 

 

 

Paweł Pawlak

 

ONAP SECCOM Chair

Leader in IT & Network Convergent Operations
FT/TGI/OLN/TPP/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

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

 

 


Re: VNFREQs for FTPes and NetConf over TLS authentication

Horn, Linda (Nokia - US/Murray Hill)
 

Pawel,

 

I agree with you on the wording of the 2 new proposed security requirements.

 

SECCOM,

 

On a different but related topic, in looking at the existing Bulk Performance Measurement requirements, I have a few comments/questions for SECCOM:

 

R-841740:  The VNF or PNF SHOULD support FileReady VES event for event-driven bulk transfer of monitoring data.

Comment:  Why isn’t this event a MUST if bulk transfer is used?  Shouldn’t this be reworded as follows:

The VNF or PNF MUST support FileReady VES event when supporting the event-driven bulk transfer of monitoring data.

 

R-440220:  The VNF or PNF SHOULD support File transferring protocol, such as FTPES or SFTP, when supporting the event-driven bulk transfer of monitoring data. 

Comment:  Why isn’t this a MUST?  If the xNF is supporting bulk transfer, isn’t it a requirement to use either FTPES or SFTP?  Shouldn’t this be reworded as follows:

The VNF or PNF MUST support File transferring protocol, such as FTPES or SFTP, when supporting the event-driven bulk transfer of monitoring data. 

 

R-75943:  The VNF or PNF SHOULD support the data schema defined in 3GPP TS 32.435, when supporting the event-driven bulk transfer of monitoring data.

Comment:  Shouldn’t this be reworded as follows:

The VNF or PNF MUST support the data schema defined in 3GPP TS 32.435, when supporting the event-driven bulk transfer of 3GPP 4G monitoring data.  The VNF or PNF MUST support the data schema defined in 3GPP TS 28.550, when supporting the event-driven bulk transfer of 3GPP 5G monitoring data.

 

Linda
-----------------------------------------------------------------------------------
Linda S. Horn, DMTS

Cloud RAN Solution Definition and Architecture

Mobile Networks, Nokia

Phone:  +1-908-679-6580

 

From: Baniewski, Pawel (Nokia - PL/Wroclaw)
Sent: Thursday, August 08, 2019 4:53 AM
To: Horn, Linda (Nokia - US/Murray Hill) <linda.horn@...>; onap-seccom@...
Subject: RE: VNFREQs for FTPes and NetConf over TLS authentication

 

Linda, thanks for your opinion. I must submit, that I have wrongly interpreted SHOULD keyword as OPTIONAL, but this is not the true. I 100% agree with you. In such case, rephrased requirements:

  • xNF SHOULD support client certificate authentication when supporting the event-driven bulk transfer of monitoring data
  • If the xNF does not support Certificate Authentication, then the xNF MUST support Basic Authentication when supporting the event-driven bulk transfer of monitoring data

 

BTW: requirement mentioned by you is already defined - https://docs.onap.org/en/dublin/submodules/vnfrqts/requirements.git/docs/Chapter7/Monitoring-And-Management.html#R-440220. Above requirements are consistent with R-440220.  

 

 

 

Regards

 

Pawel Baniewski

____________________________________________

Nokia Mobile Networks  BTSOAM Serviceability ARCH Tribe Architect

 

mobile: +48 728 361 386

 

From: Horn, Linda (Nokia - US/Murray Hill) <linda.horn@...>
Sent: Wednesday, August 07, 2019 2:16 PM
To: Baniewski, Pawel (Nokia - PL/Wroclaw) <pawel.baniewski@...>; onap-seccom@...
Subject: RE: VNFREQs for FTPes and NetConf over TLS authentication

 

Just my opinion, but I would prefer to only support certificate authentication with FTPES.  If you have a xNF that can’t support certificates, then it could use SFTP with username and password.  Then the requirement could be that a xNF MUST support either FTPES or SFTP (or both) for bulk file transfer.

 

If we do allow basic auth with FTPES, at least it should be an option for the xNF to only support certificate auth.  As an xNF vendor, we do not want to be forced to support usernames and passwords.

 

The same is true for NETCONF.  xNF MUST support either SSH or TLS (or both) and if the xNF chooses to only support TLS then it doesn’t need to support usernames and passwords.

 

Linda
-----------------------------------------------------------------------------------
Linda S. Horn, DMTS

Cloud RAN Solution Definition and Architecture

Mobile Networks, Nokia

Phone:  +1-908-679-6580

 

From: onap-seccom@... <onap-seccom@...> On Behalf Of Pawel Baniewski (Nokia) via Lists.Onap.Org
Sent: Wednesday, August 07, 2019 5:32 AM
To: onap-seccom@...
Cc: onap-seccom@...
Subject: [Onap-seccom] VNFREQs for FTPes and NetConf over TLS authentication

 

Hi,

 

following our yesterday discussion about VNFREQs for mTLS I have checked and FTPes, according to RFC 4217, can support two authentication methods:

1.       Basic authentication -  https://tools.ietf.org/html/rfc4217#page-17

2.       Client certificate authentication - https://tools.ietf.org/html/rfc4217#page-18

Cause we already have client certificate authentication in opposite direction, I think SECCOM should define that:

  • xNF MUST support client certificate authentication when supporting the event-driven bulk transfer of monitoring data
  • xNF SHOULD support basic authentication when supporting the event-driven bulk transfer of monitoring data

 

 

 

 

Also, even if not explicitly mentioned, VNFREQ for mTLS in NetConf over TLS is covered by VNF requirement 997907 cause RFC 7589 chapter 7 enforces that server MUST verify the identity of the client with certificate-based authentication according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client.

 

 

@Samuli and @Linda: what do you think?

 

 

Regards

 

Pawel Baniewski

____________________________________________

Nokia Mobile Networks  BTSOAM Serviceability ARCH Security Architect

 

mobile: +48 728 361 386

 


Re: VNFREQs for FTPes and NetConf over TLS authentication

Pawel Baniewski (Nokia)
 

Linda, thanks for your opinion. I must submit, that I have wrongly interpreted SHOULD keyword as OPTIONAL, but this is not the true. I 100% agree with you. In such case, rephrased requirements:

  • xNF SHOULD support client certificate authentication when supporting the event-driven bulk transfer of monitoring data
  • If the xNF does not support Certificate Authentication, then the xNF MUST support Basic Authentication when supporting the event-driven bulk transfer of monitoring data

 

BTW: requirement mentioned by you is already defined - https://docs.onap.org/en/dublin/submodules/vnfrqts/requirements.git/docs/Chapter7/Monitoring-And-Management.html#R-440220. Above requirements are consistent with R-440220.  

 

 

 

Regards

 

Pawel Baniewski

____________________________________________

Nokia Mobile Networks  BTSOAM Serviceability ARCH Tribe Architect

 

mobile: +48 728 361 386

 

From: Horn, Linda (Nokia - US/Murray Hill) <linda.horn@...>
Sent: Wednesday, August 07, 2019 2:16 PM
To: Baniewski, Pawel (Nokia - PL/Wroclaw) <pawel.baniewski@...>; onap-seccom@...
Subject: RE: VNFREQs for FTPes and NetConf over TLS authentication

 

Just my opinion, but I would prefer to only support certificate authentication with FTPES.  If you have a xNF that can’t support certificates, then it could use SFTP with username and password.  Then the requirement could be that a xNF MUST support either FTPES or SFTP (or both) for bulk file transfer.

 

If we do allow basic auth with FTPES, at least it should be an option for the xNF to only support certificate auth.  As an xNF vendor, we do not want to be forced to support usernames and passwords.

 

The same is true for NETCONF.  xNF MUST support either SSH or TLS (or both) and if the xNF chooses to only support TLS then it doesn’t need to support usernames and passwords.

 

Linda
-----------------------------------------------------------------------------------
Linda S. Horn, DMTS

Cloud RAN Solution Definition and Architecture

Mobile Networks, Nokia

Phone:  +1-908-679-6580

 

From: onap-seccom@... <onap-seccom@...> On Behalf Of Pawel Baniewski (Nokia) via Lists.Onap.Org
Sent: Wednesday, August 07, 2019 5:32 AM
To: onap-seccom@...
Cc: onap-seccom@...
Subject: [Onap-seccom] VNFREQs for FTPes and NetConf over TLS authentication

 

Hi,

 

following our yesterday discussion about VNFREQs for mTLS I have checked and FTPes, according to RFC 4217, can support two authentication methods:

1.       Basic authentication -  https://tools.ietf.org/html/rfc4217#page-17

2.       Client certificate authentication - https://tools.ietf.org/html/rfc4217#page-18

Cause we already have client certificate authentication in opposite direction, I think SECCOM should define that:

  • xNF MUST support client certificate authentication when supporting the event-driven bulk transfer of monitoring data
  • xNF SHOULD support basic authentication when supporting the event-driven bulk transfer of monitoring data

 

 

 

 

Also, even if not explicitly mentioned, VNFREQ for mTLS in NetConf over TLS is covered by VNF requirement 997907 cause RFC 7589 chapter 7 enforces that server MUST verify the identity of the client with certificate-based authentication according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client.

 

 

@Samuli and @Linda: what do you think?

 

 

Regards

 

Pawel Baniewski

____________________________________________

Nokia Mobile Networks  BTSOAM Serviceability ARCH Security Architect

 

mobile: +48 728 361 386

 


Re: VNFREQs for FTPes and NetConf over TLS authentication

Horn, Linda (Nokia - US/Murray Hill)
 

Just my opinion, but I would prefer to only support certificate authentication with FTPES.  If you have a xNF that can’t support certificates, then it could use SFTP with username and password.  Then the requirement could be that a xNF MUST support either FTPES or SFTP (or both) for bulk file transfer.

 

If we do allow basic auth with FTPES, at least it should be an option for the xNF to only support certificate auth.  As an xNF vendor, we do not want to be forced to support usernames and passwords.

 

The same is true for NETCONF.  xNF MUST support either SSH or TLS (or both) and if the xNF chooses to only support TLS then it doesn’t need to support usernames and passwords.

 

Linda
-----------------------------------------------------------------------------------
Linda S. Horn, DMTS

Cloud RAN Solution Definition and Architecture

Mobile Networks, Nokia

Phone:  +1-908-679-6580

 

From: onap-seccom@... <onap-seccom@...> On Behalf Of Pawel Baniewski (Nokia) via Lists.Onap.Org
Sent: Wednesday, August 07, 2019 5:32 AM
To: onap-seccom@...
Cc: onap-seccom@...
Subject: [Onap-seccom] VNFREQs for FTPes and NetConf over TLS authentication

 

Hi,

 

following our yesterday discussion about VNFREQs for mTLS I have checked and FTPes, according to RFC 4217, can support two authentication methods:

1.       Basic authentication -  https://tools.ietf.org/html/rfc4217#page-17

2.       Client certificate authentication - https://tools.ietf.org/html/rfc4217#page-18

Cause we already have client certificate authentication in opposite direction, I think SECCOM should define that:

  • xNF MUST support client certificate authentication when supporting the event-driven bulk transfer of monitoring data
  • xNF SHOULD support basic authentication when supporting the event-driven bulk transfer of monitoring data

 

 

 

 

Also, even if not explicitly mentioned, VNFREQ for mTLS in NetConf over TLS is covered by VNF requirement 997907 cause RFC 7589 chapter 7 enforces that server MUST verify the identity of the client with certificate-based authentication according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client.

 

 

@Samuli and @Linda: what do you think?

 

 

Regards

 

Pawel Baniewski

____________________________________________

Nokia Mobile Networks  BTSOAM Serviceability ARCH Security Architect

 

mobile: +48 728 361 386

 


VNFREQs for FTPes and NetConf over TLS authentication

Pawel Baniewski (Nokia)
 

Hi,

 

following our yesterday discussion about VNFREQs for mTLS I have checked and FTPes, according to RFC 4217, can support two authentication methods:

1.       Basic authentication -  https://tools.ietf.org/html/rfc4217#page-17

2.       Client certificate authentication - https://tools.ietf.org/html/rfc4217#page-18

Cause we already have client certificate authentication in opposite direction, I think SECCOM should define that:

  • xNF MUST support client certificate authentication when supporting the event-driven bulk transfer of monitoring data
  • xNF SHOULD support basic authentication when supporting the event-driven bulk transfer of monitoring data

 

 

 

 

Also, even if not explicitly mentioned, VNFREQ for mTLS in NetConf over TLS is covered by VNF requirement 997907 cause RFC 7589 chapter 7 enforces that server MUST verify the identity of the client with certificate-based authentication according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client.

 

 

@Samuli and @Linda: what do you think?

 

 

Regards

Pawel Baniewski

____________________________________________

Nokia Mobile Networks  BTSOAM Serviceability ARCH Security Architect

 

mobile: +48 728 361 386

 


Re: ONAP SECCOM : file for generating communoication matrix for review.

Pawel Baniewski (Nokia)
 

Natacha, few comments from my side, which we can discuss on next ONAP SECCOM.

 

  1. I propose to split flows into three types:

external_communication – between Operator and K8s cluster which hosts ONAP (UI -> backend component)

inter_project_communication – between different ONAP projects (DCAE -> AAF)

internal_communication – as right now, within one ONAP project (DCAE X -> DCAE Y)

 

With this approach we can easily find services which are NodePorts but shouldn’t be, what should be exposed on Ingress Controller in the future, manage Service Mesh Traffic Management in the future, etc.

 

  1. I might be wrong, but usually clients knows to what they are establishing connections, while servers don’t care. Your approach took different direction – from service (server) perspective you want to list all clients (also from different ONAP projects) which might be unrealistic in such huge project. IMO every project should list internal communication, communication between Operator and K8s cluster and outgoing communication (from own component to other ONAP project’s service)

 

  1. Also, I think there will be a challenge with different naming, as different ONAP projects may call differently the same
    1. client used in external_used_by and internal_used_by
    2. service name

– to harmonize I propose to extend metadata by list of components and services and use only such names (when PTL from project X will fill in own metadata file (s)he will have to check how component/service from project Y is called and use such name – easy to validate when processing multiple metadata files and open solution if new components/services will be added in the future)

 

  1. Section port can’t be a list as usually different communication is used there (protocol, data flow, etc)

 

 

Regards

 

Pawel Baniewski

____________________________________________

Nokia Mobile Networks  BTSOAM Serviceability ARCH Tribe Architect

 

mobile: +48 728 361 386

 

From: onap-seccom@... <onap-seccom@...> On Behalf Of natacha.mach via Lists.Onap.Org
Sent: Tuesday, July 30, 2019 4:57 PM
To: onap-discuss@...
Cc: onap-seccom@...
Subject: [Onap-seccom] ONAP SECCOM : file for generating communoication matrix for review.

 

Hello,

 

We would like to submit for review the attached YAML file.

The initial purpose was to be able to centralize relevant information regarding the communications established between components (and their sub components) of ONAP.

 

  • The approach is proposed as collaborative, meaning that each project would be responsible for completing the file for its scope.
  • There will be a presentation of the file (either during PTL meeting, or during F2F ONAP).

 

Best regards,

 

Natacha Mach

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


Vulnerabilities fixed within 60 days

Krzysztof Opasiak
 

Dear SECCOM members,

I've just analyzed status of OJSI tickets with a view to the
"Vulnerabilities fixed within 60 days" CII Badging question.
You can find the results in the attached excel.

I plan to present the list of projects that should modify the answer
during next TSC call. Feel free to provide your input till Thursday.

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


Please review the Security Requirements for HTTPS

Horn, Linda (Nokia - US/Murray Hill)
 

SECCOM,

 

ONAP Security Requirements for the HTTPS Enhancements to support Certificate Authentication are ready for formal review and have been entered into JIRA.  The El Alto Security Requirements for HTTPS excel spreadsheet from Aug 6 2019 located near the bottom of the Secure Communication to Network Functions wiki page contains the requirement wording and a link to the associated JIRA ticket.  Please review the JIRA tickets and provide a +1 if you approve or provide comments in the JIRA ticket. 

 

These requirements are targeted for El Alto, so please review by Sep 3, 2019.  Thank you!

 

Linda
-----------------------------------------------------------------------------------
Linda S. Horn, DMTS

Cloud RAN Solution Definition and Architecture

Mobile Networks, Nokia

Phone:  +1-908-679-6580

 


Re: Enforcing Checkstyle

Krzysztof Opasiak
 

Hi Gerard,

On 01.08.2019 17:28, gerard.nugent@est.tech wrote:
Hi All,
We (DMaaP DR) are looking at enforcing checkstyle as per the CII Badging
requirement. We have checkstyle working using manual steps to add the
config and add the pre-commit file to git/hooks. I assume if we
documented doing this in our WoW or a projectsetup.md file that would
suffice for the requirement. But what we would really like to do is plug
in the config and hook when the repo is cloned. Has anyone tried this or
succeeded in implementing it?
As far as I remember in some policy repos checkstyle is run on every
build (as one of maven steps) so it's run automaticaly by CI system.

Could you explain why you would like to run this when the repo is cloned
instead of as a part of CI?

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


Enforcing Checkstyle

Gerard Nugent
 

Hi All,
We (DMaaP DR) are looking at enforcing checkstyle as per the CII Badging requirement. We have checkstyle working using manual steps to add the config and add the pre-commit file to git/hooks. I assume if we documented doing this in our WoW or a projectsetup.md file that would suffice for the requirement. But what we would really like to do is plug in the config and hook when the repo is cloned. Has anyone tried this or succeeded in implementing it?

Best Regards,
Gerard Nugent
Ericsson


ONAP F2F SECCOM - 26th and 27th of September

Pawel Pawlak
 

Dear ONAP SECCOM members,

Following our discussion held yesterday please find below list of topics that we would like to address during ONAP F2F meetings in Antwerp with identified leaders in brackets:

-          Container Security for ONAP (Pawel & Amy)

-          Kubernetes Security for ONAP (Pawel & Amy)

-          ONAP security requirements (Samuli)

-          OJSI status update + target (Krzysztof)

-          Nexus-IQ vs. Whitesoftware (Pawel & Amy)

-          AAF demo with certificates (Jonathan)

-          Communication matrix (Natacha)

-          Commonly found vulnerabilities – software composition analysis (Amy)

-          Status of node port removal (Krzysztof)

-          Passwords removal from OOM helm chart (Krzysztof)

-          What does it mean to get gold in CII Badging (Tony)

-          Frankfurt security goals review with the community (Pawel)

 

If you would have an idea about some other items, not listed above, respond to this e-mail and propose it!

 

Please check internally within your organizations if it would be possible for you to join us physically – our positive experience from previous F2F meetings allows me to believe that together we can achieve a lot to make ONAP more secure!.

 

Best regards

Paweł Pawlak

 

ONAP SECCOM Chair

Leader in IT & Network Convergent Operations
FT/TGI/OLN/TPP/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

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

 

 


Re: xNF Security Requirements for HTTPS

Horn, Linda (Nokia - US/Murray Hill)
 

v3 of the xNF and ONAP security requirements for HTTPS is available on the wiki here near the bottom of the page.

 

Linda
-----------------------------------------------------------------------------------
Linda S. Horn, DMTS

Cloud RAN Solution Definition and Architecture

Mobile Networks, Nokia

Phone:  +1-908-679-6580

 

-----Original Appointment-----

From: ZWARICO, AMY <az9121@...>
Sent: Tuesday, July 30, 2019 1:46 PM
To: ZWARICO, AMY; onap-seccom@...; Horn, Linda (Nokia - US/Murray Hill); 'Pawlak Paweł 3 - Korpo'; 'Krzysztof Opasiak'; CLOSE, PIERRE; THORPE, HENRY E; 'Michela Bevilacqua'; 'Zygmunt Lozinski'; HANSEN, TONY L; GATHMAN, JONATHAN C; 'natacha.mach@...'; 'Harald.Fuchs@...'; 'meng.zhaoxing1@...'
Subject: [Onap-seccom] xNF Security Requirements for HTTPS
When: Tuesday, August 06, 2019 7:00 AM-8:00 AM (UTC-06:00) Central Time (US & Canada).
Where: webex

 

 
-- Do not delete or change any of the following text. --  
 
 
Join Webex meeting  
Meeting number (access code): 738 777 659
Meeting password: pNjiik@2 
 

Join from a video system or application
Dial 738777659@... 
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.

 

 


xNF Security Requirements for HTTPS

Amy Zwarico
 

 
-- Do not delete or change any of the following text. --  
 
 
Join Webex meeting  
Meeting number (access code): 738 777 659
Meeting password: pNjiik@2 
 

Join from a video system or application
Dial 738777659@... 
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.
 
 


ONAP SECCOM : file for generating communoication matrix for review.

natacha.mach@...
 

Hello,

 

We would like to submit for review the attached YAML file.

The initial purpose was to be able to centralize relevant information regarding the communications established between components (and their sub components) of ONAP.

 

ð  The approach is proposed as collaborative, meaning that each project would be responsible for completing the file for its scope.

ð  There will be a presentation of the file (either during PTL meeting, or during F2F ONAP).

 

Best regards,

 

Natacha Mach

_________________________________________________________________________________________________________________________

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: xNF Security Requirements for HTTPS

Pawel Baniewski (Nokia)
 

Hello,

  1. Certificate Validation is described in RFC 5280, chapter 6.
  2.  
    1. No need to add info about HTTPS tunnel as only HTTPS is planned to be supported
    2. xNF’s certificate is required only for mutual TLS (mTLS)
  3. No, because N-3 describes client side (xNF) logic, while O-4 describes server side processing

 

 

Additionally:

 

During the last call (16th of July) there was a misunderstanding how server challenges client in client certificate authentication flow. It was told that when server challenges client to present client’s certificate it can’t fall back to Basic Auth and that is why every listening component needs to open TWO ports. But in fact all modern web-servers support usually two options:

·         Require Client Cert – yes/no

·         Fail if client doesn’t present own certificate – yes/no

 

In NGINX e.g. these two options are bundled and configured by one property - http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_verify_client

In Apache httpd the same story - https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html#intranet && https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslverifyclient

The same in Spring Boot - https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/web/server/Ssl.ClientAuth.html

The same in Tomcat - https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_-_SSLHostConfig

 

In such case, VES can open one port and require client cert = yes + don’t fail if client cert not present to fall back to Basic Authentication.

 

In other words, we can remove from auth.method two options: basicAuth and certOnly and change VES listener to behave as certBasicAuth by default. And in code check that when client presents cert, but also presents user/pass – do whatever we want – fail or choose cert. For development purpose, we can switch auth.method to noAuth.

This will simplify requirements, implementation and the most important – clients (xNF’s) won’t have to know how server (VES) is configured.

 

 

Regards

 

Pawel Baniewski

____________________________________________

Nokia Mobile Networks  BTSOAM Serviceability ARCH Tribe Architect

 

mobile: +48 728 361 386

 

From: onap-seccom@... <onap-seccom@...> On Behalf Of natacha.mach via Lists.Onap.Org
Sent: Monday, July 29, 2019 11:12 AM
To: Horn, Linda (Nokia - US/Murray Hill) <linda.horn@...>; ZWARICO, AMY <az9121@...>; onap-seccom@...; PAWLAK Pawel O-PL <pawel.pawlak3@...>; 'Krzysztof Opasiak' <k.opasiak@...>; CLOSE, PIERRE <pierre.close@...>; THORPE, HENRY E <ht1659@...>; 'Michela Bevilacqua' <michela.bevilacqua@...>; 'Zygmunt Lozinski' <zygmunt_lozinski@...>; HANSEN, TONY L <tony@...>; GATHMAN, JONATHAN C <jonathan.gathman@...>; 'Harald.Fuchs@...' <Harald.Fuchs@...>; 'meng.zhaoxing1@...' <meng.zhaoxing1@...>; Hillis, Marge (Nokia - US) <marge.hillis@...>; Kukulski, Marek (Nokia - PL/Wroclaw) <marek.kukulski@...>; Murgoski, Zlatko (Nokia - PL/Wroclaw) <zlatko.murgoski@...>
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] xNF Security Requirements for HTTPS

 

Hello,

 

Many thnaks for this new version of the document.

 

Here are a few remarks :

  • what are the criteria to determine whether a certificate is valid or not?
  • for the alternative O-3:
    • it should reminded that basic authentication credentials are sent within an HTTPS tunnel.
    • how is established this tunnel between xNF and DCAE if the xNF does not have a certificate?
  • isn't there a contradiction between N-3 and O-4:
    • N-3: If the xNF is using Certificate Authentication, then the xNF MUST NOT use Basic Authentication for authenticating HTTPS connections to the DCAE Event Listener.
      Note:  xNF fallback from certificate authentication to basic authentication is not allowed.
    • O-4: If auth.method = certBasicAuth, DCAE VES Event Listener MUST authenticate the HTTPS client as follows:

o    1.       For a client with a valid certificate, DCAE VES Event Listener MUST pass the client authentication and MUST use the Subject Name in the certificate as the client identity for authorization according to RFC 5280.

2.       For a client with no or an invalid certificate and with correct basic authentication credentials, DCAE VES Event Listener MUST pass the client authentication and MUST use the username in the Authorization header as the client identity for authorization.

3.       For a client with no or an invalid certificate and with no or incorrect basic authentication credentials, DCAE VES Event Listener MUST fail the client authentication.

 

==> indeed the N-3 forbids the basic authentication in case the client certificate is invalid whereas the 0-4 enables the fallback to basic authentication in case the certificate is invalid.

 

Best regards

Natacha

 

==

 

 

 


De : Horn, Linda (Nokia - US/Murray Hill) [linda.horn@...]
Envoyé : mercredi 24 juillet 2019 14:06
À : ZWARICO, AMY;
onap-seccom@...; PAWLAK Pawel O-PL; 'Krzysztof Opasiak'; CLOSE, PIERRE; THORPE, HENRY E; 'Michela Bevilacqua'; 'Zygmunt Lozinski'; HANSEN, TONY L; GATHMAN, JONATHAN C; MACH Natacha TGI/OLS; 'Harald.Fuchs@...'; 'meng.zhaoxing1@...'; Hillis, Marge (Nokia - US); Kukulski, Marek (Nokia - PL/Wroclaw); Murgoski, Zlatko (Nokia - PL/Wroclaw)
Objet : RE: xNF Security Requirements for HTTPS

All,

 

Updated version of the security requirements for HTTPS authentication enhancements are on the wiki here.

They are at the bottom of the page and dated July 23 2019.

 

These will be reviewed at the meeting on Tue July 30 at 8 am ET.  WebEx info is below.

To be discussed whether we can remove the noAuth option for HTTPS authentication.

 

Thank you!

 

Linda
-----------------------------------------------------------------------------------
Linda S. Horn, DMTS

Cloud RAN Solution Definition and Architecture

Mobile Networks, Nokia

Phone:  +1-908-679-6580

 

-----Original Appointment-----
From: ZWARICO, AMY <
az9121@...>
Sent: Tuesday, July 23, 2019 11:46 AM
To: ZWARICO, AMY;
onap-seccom@...; Horn, Linda (Nokia - US/Murray Hill); 'Pawlak Paweł 3 - Korpo'; 'Krzysztof Opasiak'; CLOSE, PIERRE; THORPE, HENRY E; 'Michela Bevilacqua'; 'Zygmunt Lozinski'; HANSEN, TONY L; GATHMAN, JONATHAN C; 'natacha.mach@...'; 'Harald.Fuchs@...'; 'meng.zhaoxing1@...'
Subject: xNF Security Requirements for HTTPS
When: Tuesday, July 30, 2019 7:00 AM-8:00 AM (UTC-06:00) Central Time (US & Canada).
Where: webex

 

 
-- Do not delete or change any of the following text. --  
 
 
Join Webex meeting  
Meeting number (access code): 732 539 754
Meeting password: tpdmsy4$ 
 

Join from a video system or application
Dial 732539754@... 
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.

 

 

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


CII Badging Clarification

Gerard Nugent
 

Hi SECCOM,
We are looking at our remaining items for Silver Badge and have a couple of inquiries.

For item:

The project MUST implement secure design principles (from "know_secure_design"), where applicable. If the project is not producing software, select "not applicable" (N/A).
The Saltzer and Schroeder principles are largely based around authorization and authentication. Is this covered by the use of AAF/CADI or is there something else we need to consider here?

For item:

Hardening mechanisms SHOULD be used in the software produced by the project so that software defects are less likely to result in security vulnerabilities.
From an individual project aspect what is expected here? Forcing use of HTTPS is a given but what else as a project (DMaaP Datarouter) would be expected of us?

Thanks for you time,
Gerard Nugent
Ericsson

 


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

natacha.mach@...
 

Hello,

many thanks for this information.

For my understanding: what do you mean by "extra credit" regarding the check against the CRL? isn't it performed each time it is possible?
Best regards

Natacha 

De : onap-seccom@... [onap-seccom@...] de la part de Amy Zwarico [amy.zwarico@...]
Envoyé : vendredi 28 juin 2019 23:32
À : HANSEN, TONY L; MACH Natacha TGI/OLS; onap-seccom@...
Cc : PAWLAK Pawel O-PL; CLOSE, PIERRE; GATHMAN, JONATHAN C
Objet : Re: [Onap-seccom] next steps with CII -- back to [crypto_certificate_verification]:

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

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: VNF Security Requirements - El Alto Refresh: Meeting 19/7/25

natacha.mach@...
 

Hello,

Just a few remarks:

regarding VNFRQTS-672

------ OLD TEXT 

      The VNF application processes SHOULD NOT run as root. If a VNF application process must run as root, the technical reason must be documented.

------ NEW TEXT

      The VNF application processes SHOULD NOT run as root.

      If a VNF application process needs to run commands with root privilege, the access to resource MUST be controlled so that the process can only be granted on resource that it is expected to manipulate. Access control to resources MUST be enabled e.g. using SELinux.

      If a VNF application process needs root privileges, the commands expected to be run with root privilege MUST be controlled e.g. using Linux Capabilities

      Rationale:

      There will be VNFs that require root privileges on the host for functionality such as SRI/OV.

==> indeed the initial requirement does not enable to ensure that running VNF application processes as root is performed in reliable and controlled conditions.
and another point, can this activity regarding unning VNF application processes as root be monitored? is it up to the VNF to handle this monitoring, or to the service? to ONAP?


regarding requirement: R-821839

    The VNF or PNF MUST deliver event records to ONAP using the common transport mechanisms and protocols defined in this specification.

==> it should be specified which information is expected by "event records"? is it sensitive? 

Regards
Natacha


De : onap-seccom@... [onap-seccom@...] de la part de Amy Zwarico [amy.zwarico@...]
Envoyé : vendredi 26 juillet 2019 02:59
À : onap-seccom@...; LOVETT, TREVOR J; THORPE, HENRY E; 'damian.nowak@...'; JAGANNATH, VINNY; Michela Bevilacqua
Objet : [Onap-seccom] VNF Security Requirements - El Alto Refresh: Meeting 19/7/25

The following requirements are ready for approval. Those interested in the requirements refresh, please review and provide your approval by +1. On 19/8/1 these requirements will be promoted to inclusion in the El Alto VNF Requirements.

 

VNF Requirement

Jira Ticket

R-98391

VNFRQTS-467, VNFRQTS-675

R-78010 specifies the protocols

VNFRQTS-481

R-22286

VNFRQTS-490

R-258686

VNFRQTS-672

 

We discussed that we will review the container security requirement in CIS and if they seem adequate for VNFs and ONAP, we will add a requirement that containerized VNFs must meet the CIS container security requirements.

 

Next week I propose that we begin the meeting with a discussion of whether or not to change the term VNF to xNF. Linda Horn brought this up, and we moved back to the topic of containerized VNFs before we completed the conversation about VNF or xNF.

 

 

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

 

_________________________________________________________________________________________________________________________

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: xNF Security Requirements for HTTPS

natacha.mach@...
 

Hello,

Many thnaks for this new version of the document.

Here are a few remarks :
  • what are the criteria to determine whether a certificate is valid or not?
  • for the alternative O-3:
    • it should reminded that basic authentication credentials are sent within an HTTPS tunnel.
    • how is established this tunnel between xNF and DCAE if the xNF does not have a certificate?
  • isn't there a contradiction between N-3 and O-4:
    • N-3: If the xNF is using Certificate Authentication, then the xNF MUST NOT use Basic Authentication for authenticating HTTPS connections to the DCAE Event Listener.
      Note:  xNF fallback from certificate authentication to basic authentication is not allowed.
    • O-4: If auth.method = certBasicAuth, DCAE VES Event Listener MUST authenticate the HTTPS client as follows:
    • 1.       For a client with a valid certificate, DCAE VES Event Listener MUST pass the client authentication and MUST use the Subject Name in the certificate as the client identity for authorization according to RFC 5280.

      2.       For a client with no or an invalid certificate and with correct basic authentication credentials, DCAE VES Event Listener MUST pass the client authentication and MUST use the username in the Authorization header as the client identity for authorization.

      3.       For a client with no or an invalid certificate and with no or incorrect basic authentication credentials, DCAE VES Event Listener MUST fail the client authentication.


==>
indeed the N-3 forbids the basic authentication in case the client certificate is invalid whereas the 0-4 enables the fallback to basic authentication in case the certificate is invalid.

Best regards
Natacha

==




De : Horn, Linda (Nokia - US/Murray Hill) [linda.horn@...]
Envoyé : mercredi 24 juillet 2019 14:06
À : ZWARICO, AMY; onap-seccom@...; PAWLAK Pawel O-PL; 'Krzysztof Opasiak'; CLOSE, PIERRE; THORPE, HENRY E; 'Michela Bevilacqua'; 'Zygmunt Lozinski'; HANSEN, TONY L; GATHMAN, JONATHAN C; MACH Natacha TGI/OLS; 'Harald.Fuchs@...'; 'meng.zhaoxing1@...'; Hillis, Marge (Nokia - US); Kukulski, Marek (Nokia - PL/Wroclaw); Murgoski, Zlatko (Nokia - PL/Wroclaw)
Objet : RE: xNF Security Requirements for HTTPS

All,

 

Updated version of the security requirements for HTTPS authentication enhancements are on the wiki here.

They are at the bottom of the page and dated July 23 2019.

 

These will be reviewed at the meeting on Tue July 30 at 8 am ET.  WebEx info is below.

To be discussed whether we can remove the noAuth option for HTTPS authentication.

 

Thank you!

 

Linda
-----------------------------------------------------------------------------------
Linda S. Horn, DMTS

Cloud RAN Solution Definition and Architecture

Mobile Networks, Nokia

Phone:  +1-908-679-6580

 

-----Original Appointment-----

From: ZWARICO, AMY <az9121@...>
Sent: Tuesday, July 23, 2019 11:46 AM
To: ZWARICO, AMY; onap-seccom@...; Horn, Linda (Nokia - US/Murray Hill); 'Pawlak Paweł 3 - Korpo'; 'Krzysztof Opasiak'; CLOSE, PIERRE; THORPE, HENRY E; 'Michela Bevilacqua'; 'Zygmunt Lozinski'; HANSEN, TONY L; GATHMAN, JONATHAN C; 'natacha.mach@...'; 'Harald.Fuchs@...'; 'meng.zhaoxing1@...'
Subject: xNF Security Requirements for HTTPS
When: Tuesday, July 30, 2019 7:00 AM-8:00 AM (UTC-06:00) Central Time (US & Canada).
Where: webex

 

 
-- Do not delete or change any of the following text. --  
 
 
Join Webex meeting  
Meeting number (access code): 732 539 754
Meeting password: tpdmsy4$ 
 

Join from a video system or application
Dial 732539754@... 
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.

 

 

_________________________________________________________________________________________________________________________

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.


Canceled: VNF Security Requirements Refresh for El Alto

Amy Zwarico
 

I am cancelling today because I have mandatory all day training. 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.
 
 

261 - 280 of 1690