Date   
Canceled: VNF Security Requirements Refresh

Amy Zwarico
 

I forgot to send out the cancellation earlier. I need to reschedule this meeting because it now conflicts with the TSC>
 
Proposal: Tuesdays after the SECCOM call. Does that work for the participants of the VNF Security Requirements calls?
 
Weekly meeting to work on revisions to the VNF security requirements.
 
 

ONAP and Integration synch call

Pawel Pawlak
 

Just a reminder for those of you who want to join today’s Integration meeting, we will have a dedicated slot for security topics.
 
ONAP Meeting 2 is inviting you to a scheduled Zoom meeting.
 
 

Re: ONAP SECCOM and CLI synch call proposal

Pawel Pawlak
 

Hello Kanagaraj,

Still waiting for your valuable feedback.

BTW I do not see CLI weekly calls in the ONAP calendar, could you please share, how we can contact CLI project team?

Best regards

 

Paweł Pawlak

 

ONAP SECCOM Chair

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

 

 

From: Pawlak Paweł 3 - Korpo
Sent: Monday, November 18, 2019 10:19 AM
To: Kanagaraj Manickam (kanagaraj.manickam@...)
Cc: onap-seccom@...; David McBride <dmcbride@...> (dmcbride@...)
Subject: ONAP SECCOM and CLI synch call proposal
Importance: High

 

Hello Kanagaraj,

We would like to propose a synch call with CLI project team in order to address security concerns in the key security KPIs: OJSI, CII Badging and known vulnerabilities analysis.

Could you please confirm if you would be available tomorrow at 3 PM CET? If not, please feel free to propose any alternative slot this week.

Best regards

 

Paweł Pawlak

 

ONAP SECCOM Chair

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

 

 

Java 11 (LTS) recommended for ONAP for Frankfurt release

Pawel Pawlak
 

Hello,

Following today’s discussion at the PTL call, I would like to remind you to target Java 11.0.5 with Alpine 3.10.3 for Frankfurt release.

The choice of Java 11 release is due to its Long-term Support (see details: https://en.wikipedia.org/wiki/Java_version_history ).

Please do not consider Java 13 as its support is only till March 2020.

 

We will work on building Java and Alpine container with the Integration Team as discussed at the PTL call.

 

Best regards  

 

Paweł Pawlak

 

ONAP SECCOM Chair

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

 

 

ONAP SECCOM and CLI synch call proposal

Pawel Pawlak
 

Hello Kanagaraj,

We would like to propose a synch call with CLI project team in order to address security concerns in the key security KPIs: OJSI, CII Badging and known vulnerabilities analysis.

Could you please confirm if you would be available tomorrow at 3 PM CET? If not, please feel free to propose any alternative slot this week.

Best regards

 

Paweł Pawlak

 

ONAP SECCOM Chair

Leader in IT & Network Convergent Operations
FT/TGI/OLN/TOP/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: SECCOM and MSB synch call

zhao.huabing@...
 

Hi,

I created some jira tickets to address the vulnerability issues and security requests from seccom, if anyting is missing, we can discuss in today's meeting.

https://jira.onap.org/browse/MSB-404  Migrate self-signed certificate to AAF certificate

https://jira.onap.org/browse/MSB-406  Solve MSB vulnerability issues


Thanks,

Huabing


原始邮件
发件人:PawlakPaweł3-Korpo <Pawel.Pawlak3@...>
收件人:赵化冰10201488;onap-seccom@... <onap-seccom@...>;
日 期 :2019年11月14日 15:34
主 题 :SECCOM and MSB synch call
SECCOM and MSB synch call


  • 尊敬的 赵化冰10201488 女士\先生:



  • 您好!PawlakPaweł3-Korpo诚挚邀请您参会。



  • 会议主题:

    SECCOM and MSB synch call




  • 会议时间:

    2019-11-15 15:00 ~ 15:30 (雅典时间 UTC +2:00)



  • 会议地点:

    https://zoom.us/j/571164041



  • 会议主要内容:

    SECCOM and MSB synch call
    ONAP Meeting 2 is inviting you to a scheduled Zoom meeting.  Join Zoom Meeting  https://zoom.us/j/571164041 Meeting ID: 571 164 041 One tap mobile +16699006833,,571164041# US (San Jose) +16465588656,,571164041# US (New York) Dial by your location  +1 669 900 6833 US (San Jose)  +1 646 558 8656 US (New York)  877 369 0926 US Toll-free  855 880 1246 US Toll-free  +1 647 558 0588 Canada  855 703 8985 Canada Toll-free Meeting ID: 571 164 041 Find your local number: https://zoom.us/u/aedFyNdWz8



  • 与会人员:

    • Pawel.Pawlak3@...,

    • 赵化冰10201488,

    • onap-seccom@...,



  • ONAP Meeting 2 is inviting you to a scheduled Zoom meeting.
    Join Zoom Meeting
     
    Meeting ID: 571 164 041
    One tap mobile
    +16699006833,,571164041# US (San Jose)
    +16465588656,,571164041# US (New York)
    Dial by your location
    +1 669 900 6833 US (San Jose)
    +1 646 558 8656 US (New York)
    877 369 0926 US Toll-free
    855 880 1246 US Toll-free
    +1 647 558 0588 Canada
    855 703 8985 Canada Toll-free
    Meeting ID: 571 164 041
    Find your local number: https://zoom.us/u/aedFyNdWz8
     



  • 会议发起人:PawlakPaweł3-Korpo




Re: JDK 12 or 13, not quite so rosy for AAF

Amy Zwarico
 

Java 12 is no longer supported and it is recommended that all users of Java SE 12 switch to Java SE 13.

 

From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of GATHMAN, JONATHAN C
Sent: Thursday, November 14, 2019 1:13 PM
To: onap-seccom@...
Subject: [Onap-seccom] JDK 12 or 13, not quite so rosy for AAF

 

***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.

Greetings,

  In terms of my “JDK 12/13” investigation, it appears that simply switching to that JDK is fine.

 

  I am, however, running into issues where the “Config” Image doesn’t work correctly.  This is the one that sets up AAF Configs on a Volume (Used both BY AAF and FOR AAF Clients).

 

  I will have to figure out what is missing before I can give blessing to this JDK Versioning for AAF.

 

-- 

Jonathan Gathman

Principled-System Architect

ATO Tech Dev/SEAT/Platform Architecture and Technology Management

 

AT&T Services, Inc.

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

 

JDK 12 or 13, not quite so rosy for AAF

Jonathan Gathman <jonathan.gathman@...>
 

Greetings,

  In terms of my “JDK 12/13” investigation, it appears that simply switching to that JDK is fine.

 

  I am, however, running into issues where the “Config” Image doesn’t work correctly.  This is the one that sets up AAF Configs on a Volume (Used both BY AAF and FOR AAF Clients).

 

  I will have to figure out what is missing before I can give blessing to this JDK Versioning for AAF.

 

-- 

Jonathan Gathman

Principled-System Architect

ATO Tech Dev/SEAT/Platform Architecture and Technology Management

 

AT&T Services, Inc.

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

 

SECCOM and MSB synch call

Pawel Pawlak
 

ONAP Meeting 2 is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
 
Meeting ID: 571 164 041
One tap mobile
+16699006833,,571164041# US (San Jose)
+16465588656,,571164041# US (New York)
Dial by your location
+1 669 900 6833 US (San Jose)
+1 646 558 8656 US (New York)
877 369 0926 US Toll-free
855 880 1246 US Toll-free
+1 647 558 0588 Canada
855 703 8985 Canada Toll-free
Meeting ID: 571 164 041
Find your local number: https://zoom.us/u/aedFyNdWz8
 

Canceled: VNF Security Requirements Refresh

Amy Zwarico
 

Cancelling again because the meeting now conflicts with the TSC call. I will find a better time going forward.
 
Weekly meeting to work on revisions to the VNF security requirements.
 
 

Using Java 11 - AAF Exploration

Jonathan Gathman <jonathan.gathman@...>
 

Greetings,

  I have wanted to upgrade beyond JDK 8 for some time, so, given SECCOM is going to look at this on Tues, I thought I would do some exploration.

 

  1. No Alpine (sortof)
    1. I have been using openjdk:8-jre-alpine, as a minimal Container with Java (which is all AAF needs)
    2. There was no openjdk:11-jre-alpine or other variant that I could find for JDK 11

                                                      i.      Looking around the web, it seems they gave up on that, but did create openjdk:12-jdk-alpine, and I think some for jdk 13.

                                                    ii.      IMPLICATIONS:  We might want to say “At least JDK 11” rather than “Specifically JDK 11”

  1. XML (J2EE) libs removed.
    1. AAF uses javax classes to provide XML as well as JSON to every API interface.
    2. JAVAX was removed from the JDK in about 9 (or after 9).  Regardless, it’s not in the regular JDK.
    3. HOWEVER, I found someone had solved, and simply adds these Maven Dependencies where needed:

          <dependency>

            <groupId>javax.xml.bind</groupId>

            <artifactId>jaxb-api</artifactId>

            <version>2.3.1</version>

          </dependency>

          <dependency>

            <groupId>org.glassfish.jaxb</groupId>

            <artifactId>jaxb-runtime</artifactId>

            <version>2.3.1</version>

         </dependency>

 

Once I figured these two things out, and rebuilt, AAF (Helm) ran perfectly with initial Tests.

 

We can discuss on Tues what others have found as well.

 

-- 

Jonathan Gathman

Principled-System Architect

ATO Tech Dev/SEAT/Platform Architecture and Technology Management

 

AT&T Services, Inc.

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

 

SECOM proposal for java 11 and Alpine versions

Pawel Pawlak
 

Hello SECCOM team,

Following today’s TSC call we were asked to provide recommendations to ONAP community for java 11 and Alpine versions.

It will be a topic for the discussion during next week SECCOM call, but recommendations in advance by e-mail are appreciated, so we could ensure conclusion and final recommendation on Tuesday call.

 

Best regards

 

Paweł Pawlak

 

ONAP SECCOM Chair

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

 

 

FW: [JIRA] (REQ-219) Java 11 and 13 migration from v8

Pawel Pawlak
 

I think this question from Vijay is relevant, do we have any specific recommendations for that?

Best regards

 

Paweł Pawlak

 

ONAP SECCOM Chair

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

 

 

From: Vijay Venkatesh Kumar (Jira) [mailto:jira@...]
Sent: Wednesday, November 6, 2019 11:33 PM
To: Pawlak Paweł 3 - Korpo
Subject: [JIRA] (REQ-219) Java 11 and 13 migration from v8

 

Vijay Venkatesh Kumar commented on EpicREQ-219

 

Re: Java 11 and 13 migration from v8

Pawel Pawlak -   Is there a recommendation from SECCOM on Java 11 base image to be used?

Add Comment

Add Comment

 

 

CII badging requirements aimed at Application Quality and Security

Tony Hansen
 

As an aid for continuing the conversation in yesterday’s SECCOM meeting, I added a sorting option for the names in the dashboard, so you can easily see which items are oriented toward which areas. The sorting lets you sort by “section” (Basics, Security, Reporting, etc) and “type” (Application Quality, FLOSS, Infrastructure, etc). Try this view of the dashboard:

 

http://tlhansen.us/onap/cii.html?turnoff=requirements,summary,projects,releasestats&sortby=bytype

 

Here are all of the CII requirements that are of the type Application Quality and in the section Security. A few are listed multiple times because they change from SHOULD to MUST in the higher level.

 

Hope this helps.

 

                Tony

 

Passing

 

crypto_call  

If the software produced by the project is an application or library, and its primary purpose is not to implement cryptography, then it SHOULD only call on software specifically designed to implement cryptographic functions; it SHOULD NOT re-implement its own.

 

crypto_keylength  

The security mechanisms within the software produced by the project MUST use default keylengths that at least meet the NIST minimum requirements through the year 2030 (as stated in 2012). It MUST be possible to configure the software so that smaller keylengths are completely disabled.

 

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

 

crypto_pfs  

The security mechanisms within the software produced by the project SHOULD implement perfect forward secrecy for key agreement protocols so a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future.

 

crypto_published  

The software produced by the project MUST use, by default, only cryptographic protocols and algorithms that are publicly published and reviewed by experts (if cryptographic protocols and algorithms are used).

 

crypto_random  

The security mechanisms within the software produced by the project MUST generate all cryptographic keys and nonces using a cryptographically secure random number generator, and MUST NOT do so using generators that are cryptographically insecure.

 

crypto_weaknesses  

The default security mechanisms within the software produced by the project SHOULD NOT depend on cryptographic algorithms or modes with known serious weaknesses (e.g., the SHA-1 cryptographic hash algorithm or the CBC mode in SSH).

 

crypto_working 

 The default security mechanisms within the software produced by the project MUST NOT depend on broken cryptographic algorithms (e.g., MD4, MD5, single DES, RC4, Dual_EC_DRBG), or use cipher modes that are inappropriate to the context, unless they are necessary to implement an interoperable protocol (where the protocol implemented is the most recent version of that standard broadly supported by the network ecosystem, that ecosystem requires the use of such an algorithm or mode, and that ecosystem does not offer any more secure alternative). The documentation MUST describe any relevant security risks and any known mitigations if these broken algorithms or modes are necessary for an interoperable protocol.

 

vulnerabilities_critical_fixed  

Projects SHOULD fix all critical vulnerabilities rapidly after they are reported.

 

vulnerabilities_fixed_60_days  

There MUST be no unpatched vulnerabilities of medium or high severity that have been publicly known for more than 60 days.

 

Silver

 

assurance_case  

The project MUST provide an assurance case that justifies why its security requirements are met. The assurance case MUST include: a description of the threat model, clear identification of trust boundaries, an argument that secure design principles have been applied, and an argument that common implementation security weaknesses have been countered. (URL required)

 

crypto_algorithm_agility  

The project SHOULD support multiple cryptographic algorithms, so users can quickly switch if one is broken. Common symmetric key algorithms include AES, Twofish, and Serpent. Common cryptographic hash algorithm alternatives include SHA-2 (including SHA-224, SHA-256, SHA-384 AND SHA-512) and SHA-3.

 

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 replace them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

 

crypto_tls12  

The software produced by the project SHOULD, 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 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 communications, 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).

 

crypto_weaknesses (upgrade from Passing)

The default security mechanisms within the software produced by the project MUST NOT depend on cryptographic algorithms or modes with known serious weaknesses (e.g., the SHA-1 cryptographic hash algorithm or the CBC mode in SSH).

 

hardening

Hardening mechanisms SHOULD be used in the software produced by the project so that software defects are less likely to result in security vulnerabilities.

 

implement_secure_design

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

 

input_validation

The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (a *whitelist*), and reject invalid inputs, if there are any restrictions on the data at all.

 

Gold

 

crypto_tls12 (upgrade from Silver)

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

 

crypto_used_network (upgrade from Silver)

The software produced by the project 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 MUST be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network communications, select 'not applicable' (N/A).

 

hardening (upgrade from Silver)

Hardening mechanisms MUST be used in the software produced by the project so that software defects are less likely to result in security vulnerabilities. (URL required)

 

security_review  

The project MUST have performed a security review within the last 5 years. This review MUST consider the security requirements and security boundary.

Unable to attend today's SECCOM meeting

Pierre Close
 

Dear SECCOM,

 

Unfortunately I have an internal meeting which is conflicting with today’s SECCOM meeting time, so I won’t be able to attend.

 

I saw that my proposal was on the agenda, so please come back to me with comments and/or remarks that you would like to discuss on next meeting – or maybe we could have a separate dedicated session to discuss this point in particular?

 

Apologies for the inconvenience.

 

Best regards,

Pierre

 

From: onap-seccom@... <onap-seccom@...> On Behalf Of Pawel Pawlak via Lists.Onap.Org
Sent: Tuesday, November 5, 2019 10:59 AM
To: onap-seccom@...
Cc: onap-seccom@...
Subject: [Onap-seccom] SECCOM Agenda

 

Hello,

Please find attached slides for today’s SECCOM meeting. In order to avoid confusion related to meeting timing after recent clock changes, it will be held as last week at 2PM (UTC+1).

I am still waiting for your feedback if we should delay our meeting by 1 hour (I think more convenient for US colleagues) – but we have to check with Jonathan if we have no conflict with AAF meeting and with Steve if we have no conflict with Architecture Subcommittee (as of today we are using the same zoom bridge).

 

Best regards

 

Paweł Pawlak

 

ONAP SECCOM Chair

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

 

 

SECCOM Agenda

Pawel Pawlak
 

Hello,

Please find attached slides for today’s SECCOM meeting. In order to avoid confusion related to meeting timing after recent clock changes, it will be held as last week at 2PM (UTC+1).

I am still waiting for your feedback if we should delay our meeting by 1 hour (I think more convenient for US colleagues) – but we have to check with Jonathan if we have no conflict with AAF meeting and with Steve if we have no conflict with Architecture Subcommittee (as of today we are using the same zoom bridge).

 

Best regards

 

Paweł Pawlak

 

ONAP SECCOM Chair

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

 

 

Canceled: VNF Security Requirements Refresh

Amy Zwarico
 

I am OOO on Thursday. We will resume Thursday, 14th November.
Weekly meeting to work on revisions to the VNF security requirements.
 
 

VNF Security Requirements Refresh

Amy Zwarico
 

I am OOO on Thursday. We will resume Thursday, 14th November.
Weekly meeting to work on revisions to the VNF security requirements.
 
-- Do not delete or change any of the following text. --  
 
 
Join Webex meeting  
Meeting number (access code): 730 640 896 Meeting password: Jyw8imU@   

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

Re: revised code coverage requirement

Pawel Pawlak
 

+1

Paweł Pawlak

ONAP SECCOM Chair
Leader in IT & Network Convergent Operations
FT/TGI/OLN/TOP/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: Close, Pierre [mailto:pierre.close@...]
Sent: Monday, November 4, 2019 12:32 PM
To: k.opasiak@...; ZWARICO, AMY; Pawlak Paweł 3 - Korpo; onap-seccom@...
Subject: RE: [Onap-seccom] revised code coverage requirement

Amy,

I agree with the general plan, but I'm afraid that global 80% coverage could lead developers to build tests for the sake of only having more coverage, mostly because the amount of available resources for feature development not always allows to add/improve testing at the same time.

Colleagues suggested the following: contextualize the scope of coverage. By this, it is meant to:
- define, for each project, the core parts that need intensive testing (an API sensitive project might prioritize API testing so that all are covered, hardened, so that said APIs are robust)
- concentrate coverage on those areas, even if coverage is lower on other parts, so critical parts are better covered and tested.
This might improve OJSI resolution (and/or reduce findings), and better focuses the effort on testing based on available resources.
This would be even better if we could tell Sonar which parts of the code are the critical ones, but I don't know if that's feasible.

Thoughts are welcome

Best regards,
Pierre

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On Behalf Of Krzysztof Opasiak via Lists.Onap.Org
Sent: Monday, November 4, 2019 10:02 AM
To: ZWARICO, AMY <az9121@...>; Close, Pierre <pierre.close@...>; Pawlak Paweł 3 - Korpo <Pawel.Pawlak3@...>; onap-seccom@...
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] revised code coverage requirement



On 31.10.2019 13:36, ZWARICO, AMY wrote:
Unfortunately there is urgency, and considerable pushback. I propose that we investigate the "new code tested" feature of SONAR in the Frankfurt release, create a clear definition of "new code", find a project that will test it, and, if all goes well, add the requirement that all new code contributions have 80% statement coverage in the Guilin release.

Thoughts from others?
+1 from my side


-----Original Message-----
From: CLOSE, PIERRE
Sent: Thursday, October 31, 2019 6:14 AM
To: Krzysztof Opasiak <k.opasiak@...>; ZWARICO, AMY
<az9121@...>; Pawlak Paweł 3 - Korpo <Pawel.Pawlak3@...>;
onap-seccom@...
Subject: RE: [Onap-seccom] revised code coverage requirement

Hello Krzysztof,

Please find my comments inline.

Amy,

Is it possible to wait a little longer before agreeing on this requirement? Or do we have an urgency in deciding today -- in such a case, Krzysztof's comments lead me to delay the use of Sonar until we have a solid plan.

Best regards,
Pierre

-----Original Message-----
From: Krzysztof Opasiak <k.opasiak@...>
Sent: Wednesday, October 30, 2019 10:10 PM
To: Close, Pierre <pierre.close@...>; ZWARICO, AMY
<az9121@...>; Pawlak Paweł 3 - Korpo <Pawel.Pawlak3@...>;
onap-seccom@...
Subject: Re: [Onap-seccom] revised code coverage requirement

Hi,

On 30.10.2019 19:24, Pierre Close wrote:
Amy,

That’s a good question. But your explanation makes sense to me: when
a new Sonar scan is run it probably overrides the result of the
previous one, causing those counters to reset… Additionally, what is
considered “new code”? Is a configuration file change seen as new code?

I’ll try to look for an explanation from my colleagues and come back
to you when I got an answer (or maybe the LF knows?)
We would need a clear definition of the new code. Is a change in currently existing class a new code or only newly created classes? Is new function withing a class a new code?
[PC]: Agreed. That's what I was suggesting in my comment above.

Saying that we will just use the metric that the tool provides without
any explanation to the community is not a good thing I believe
[PC]: I think we need to dig further into the capabilities of the tool and verify how we can use the metrics in a proper and meaningful way, otherwise it won't be of any use, as you mention.


In the meantime, since the feature seems available in the tool, we
might want to consider binding the “new code coverage” objective to
the tool – in other words, if the feature is usable and gives what we
expect, we could start monitoring it.

Would that make sense?
As far as I can see (please correct me if I'm wrong) the tool gives
you only the current status of the code and diff since last run. What
we would need is a dashboard as bitergia where you can select any
arbitrary period of time and check the results
[PC]: I was under the impression that you could choose different versions to compare between... Now, your comments being valid, I propose that we take some time to further analyze what we can do, build (if possible) meaningful metrics and dashboards (as you mention), and then decide what route to take -- I know the timing is against us, but throwing all this into the community without further research is not constructive, so I support your statements. Would you agree with this approach?

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

Re: revised code coverage requirement

Pierre Close
 

Amy,

I agree with the general plan, but I'm afraid that global 80% coverage could lead developers to build tests for the sake of only having more coverage, mostly because the amount of available resources for feature development not always allows to add/improve testing at the same time.

Colleagues suggested the following: contextualize the scope of coverage. By this, it is meant to:
- define, for each project, the core parts that need intensive testing (an API sensitive project might prioritize API testing so that all are covered, hardened, so that said APIs are robust)
- concentrate coverage on those areas, even if coverage is lower on other parts, so critical parts are better covered and tested.
This might improve OJSI resolution (and/or reduce findings), and better focuses the effort on testing based on available resources.
This would be even better if we could tell Sonar which parts of the code are the critical ones, but I don't know if that's feasible.

Thoughts are welcome

Best regards,
Pierre

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On Behalf Of Krzysztof Opasiak via Lists.Onap.Org
Sent: Monday, November 4, 2019 10:02 AM
To: ZWARICO, AMY <az9121@...>; Close, Pierre <pierre.close@...>; Pawlak Paweł 3 - Korpo <Pawel.Pawlak3@...>; onap-seccom@...
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] revised code coverage requirement



On 31.10.2019 13:36, ZWARICO, AMY wrote:
Unfortunately there is urgency, and considerable pushback. I propose that we investigate the "new code tested" feature of SONAR in the Frankfurt release, create a clear definition of "new code", find a project that will test it, and, if all goes well, add the requirement that all new code contributions have 80% statement coverage in the Guilin release.

Thoughts from others?
+1 from my side


-----Original Message-----
From: CLOSE, PIERRE
Sent: Thursday, October 31, 2019 6:14 AM
To: Krzysztof Opasiak <k.opasiak@...>; ZWARICO, AMY
<az9121@...>; Pawlak Paweł 3 - Korpo <Pawel.Pawlak3@...>;
onap-seccom@...
Subject: RE: [Onap-seccom] revised code coverage requirement

Hello Krzysztof,

Please find my comments inline.

Amy,

Is it possible to wait a little longer before agreeing on this requirement? Or do we have an urgency in deciding today -- in such a case, Krzysztof's comments lead me to delay the use of Sonar until we have a solid plan.

Best regards,
Pierre

-----Original Message-----
From: Krzysztof Opasiak <k.opasiak@...>
Sent: Wednesday, October 30, 2019 10:10 PM
To: Close, Pierre <pierre.close@...>; ZWARICO, AMY
<az9121@...>; Pawlak Paweł 3 - Korpo <Pawel.Pawlak3@...>;
onap-seccom@...
Subject: Re: [Onap-seccom] revised code coverage requirement

Hi,

On 30.10.2019 19:24, Pierre Close wrote:
Amy,

That’s a good question. But your explanation makes sense to me: when
a new Sonar scan is run it probably overrides the result of the
previous one, causing those counters to reset… Additionally, what is
considered “new code”? Is a configuration file change seen as new code?

I’ll try to look for an explanation from my colleagues and come back
to you when I got an answer (or maybe the LF knows?)
We would need a clear definition of the new code. Is a change in currently existing class a new code or only newly created classes? Is new function withing a class a new code?
[PC]: Agreed. That's what I was suggesting in my comment above.

Saying that we will just use the metric that the tool provides without
any explanation to the community is not a good thing I believe
[PC]: I think we need to dig further into the capabilities of the tool and verify how we can use the metrics in a proper and meaningful way, otherwise it won't be of any use, as you mention.


In the meantime, since the feature seems available in the tool, we
might want to consider binding the “new code coverage” objective to
the tool – in other words, if the feature is usable and gives what we
expect, we could start monitoring it.

Would that make sense?
As far as I can see (please correct me if I'm wrong) the tool gives
you only the current status of the code and diff since last run. What
we would need is a dashboard as bitergia where you can select any
arbitrary period of time and check the results
[PC]: I was under the impression that you could choose different versions to compare between... Now, your comments being valid, I propose that we take some time to further analyze what we can do, build (if possible) meaningful metrics and dashboards (as you mention), and then decide what route to take -- I know the timing is against us, but throwing all this into the community without further research is not constructive, so I support your statements. Would you agree with this approach?

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