1. ONAP security meeting

2. Agenda Information update Credentials Protection and Management
PKI infrastructure and CA
CII Badging for CLAMP
Vulnerability Management (deferred to 9/13)
Preparation for ad hoc seccom/SDC/VNF SDK meeting
AOB
September Developers event

3. Credentials Management – PKI Automation
Amy presented an internal AT&T document about the AAF Certificate Manager
Automation of certificate creation, request and renewal

4. CII Badging Questions - CLAMP
The CLAMP team asked for clarification on some of the CII requirements
Provide the Security subteam team the URLs for CVE listings
The release notes MUST identify every publicly known vulnerability that is fixed in each new release. This is “N/A” if there are no release notes or there have been no publicly known vulnerabilities
Clarify which warnings be raised by a software component
Requirement: It is SUGGESTED that projects be maximally strict with warnings in the software produced by the project, where practical. Some warnings cannot be effectively enabled on some projects. What is needed is evidence that the project is striving to enable warning flags where it can, so that errors are detected early

5. September Event Vulnerability scanning
Update from CII badging – feedback
Static code scanning

6. Slides from previous weeks

7. Network Security and ONAP
Best way to manage firewalls, DDoS, intrusion detection
Providing security functions to protect the ONAP deployment vs enabling ONAP to treat security functions as VNFs
Design, operations?
Does this need to be covered in this team? (yes)
Distinction between the team that deploys networks and the team that writes security requirements; operators have their own security requirements and practices
Don: good security topics; should those using ONAP already have these security controls in place;
Phil: recognizing threats
Zyg: what is the operational model of ONAP? What is different because you are using ONAP? Eg, integrating password store, PKI into ONAP; should ONAP create a layer of middleware that allows ONAP users to integrate their solutions; Middleware needs to be a project
Create a subteam lead by the ONAP security team (phil will facilitate)
Think about it this week (9/13)
Phil will bring some people in to present
September topic – operator security
Add a blackbox for testing (static, dynamic, penetration)
Add security requirements inside the service chain; network segmentation rules

8. CII Badging Program Two volunteer projects Next Steps: CLAMP AAF
See to subteam
About 80% of badging in place for Passing
To do: full code coverage; full documentation; vulnerability identification and resolution
AAF
Next Steps:
David presented the CII badging process to teams on 8/16 (David, Catherine (CLAMP)).
CII oriented on small projects rather than large projects with sub projects
Should large projects be broken into smaller badging initiatives?
Can bring smaller initiatives onboard more quickly
ONAP CII would then aggregate the smaller initiatives
Next steps: develop a publicly available representation of partial certification for a project
in progress badges: see
How does ONAP encourage projects move to more complete certification? Does partial certification lead to projects not completing certification for the entire project?
Identify Linux Foundation projects that have gone through this recently

9. Credentials Protection and Management - how to achieve?
Conclusion from last meeting:
Amy has thoughts around this
Steve Goeringer raised the question of why passwords, why not certificates (or such approaches).
Stephen to create a security best practice sub-page – Amy/Steve Goeringer create a proposal to discuss in the community. Different ambition levels (R1 may not be able to achieve what we want, but at least we should point out the “gotchas”). Two weeks.
Maybe a common module for R2 …
Note: Evgeny Zemlerub also expressed views to incorporate
Updates:
Steve Goeringer, Igor Faynburg, Evgeny Zemelrub, Amy Zwarico met (8/15, 8/16)
Code signing: What about SOL-4 and PKI? Each machine will have all the roots to check the signature. Cert will include the CRL or OSCP URL.
Use case driving the need for Password Protection: The DNC needs to be able to configure a Juniper VNF
Password Vaulting: Evgeny presentation
Zyg: suggested that we look at Barbican (OpenStack open source secrets vault), noting that it does not have HSM or Kerberos integration
Zyg: there are two problems covered by the vault (1) the interface to provide credentials manage, (2) the underlying vault
Proposal: create a Project for R2 that will create a reference implementation of a password vault. We will have to find someone willing to implement this functionality to propose such a project.
Automated Certificate Management: AAF for certificate deployment to ONAP components (Amy presentation)
ETSI NFV SEC may issue a spec in the future on a more comprehensive approach to using PKI for NFV which can be visited by ONAP SEC when released. Steve is working on this right now but doesn’t know when he’ll be done.
Security monitoring notions from ETSI NFV SEC will be provided by Igor.

10. Vulnerability Management
Select one vulnerability and send to send in to “clean the cobwebs” from our process.

11. PKI infrastructure and CA (1/2)
For thte called ad-hoc meetings
The ASK from Chris
Does the Security Team have a PKI strategy? Anyone planning to host an ONAP CA? The reason I ask is that VNF SDK is considering implementing SOL-04, which has some vnf package integrity and authenticity options that require digital signatures. We’d like to align with other projects such as SDC, SO, VFC, and APPC that may need to validate the VNFs as part of the onboarding process, and we’re interested in taking advantage of any PKI mechanisms already in place.
Not that we’re looking for more work, but if no one else is working on PKI, VNF SDK wouldn’t be a bad place to home it, given that we’re building a reference “marketplace” for VNFs and will have a relationship with VNF vendors. Also, if the Security team wants to take this on, I’d like to recommend checking out Kyrio ( To my knowledge, they’re the largest issuer of device certificates on the planet (cable modems, passpoint, smart grid, and medical devices). As they say, “Kyrio is the preferred security provider for CableLabs, OpenADR, Wi-Fi Alliance, and Center for Medical Interoperability (CMI).” .

12. PKI infrastructure and CA (2/2)
For thte called ad-hoc meetings
From the VNF SDK perspective, we are supplying VNF packaging tools to vendors and then validating the uploaded VNF packages. If you think about a potential marketplace environment, where vendors upload their VNFs to a neutral marketplace (think Apple App Store or Google Play) and operators download the ones they’re interested in, operator certs may not make sense. We were thinking that vendors would acquire certificates from a central place (from ONAP CA? From a defined third-party (such as Kyrio) which ONAP would use as a trusted root? Something else?). The vendors would sign their VNF packages with that cert, and vnf sdk would then validate the digital signatures as part of the VNF package validation prior to onboarding.
Meeting notes:
Organize a discussion with VNF SDK team .
Avoid Mon-Wed (7-9) next week.
If next Thu, same hour as seccom is good

13. Static Scanning Met with Steve Winslow Explained Nexus IQ lifecycle.
Good for identifying the known vulnerabilities of the use code and in which version there is a fix.
Doesn’t do the active static scanning as such with fortify
Reflection
Could be good for the project leads to know which versions of components they have and which they should take.
Next Steps::
Meeting Discussion:
Nexus IQ lifecycle
Ask the LF to make it open to the PTLs.
Create communication to inform the PTLs about the possibility to do so. Could be good to inform Gildas to tie to a release.
Look at static code scanning tools to come with a recommendation
E.g. Fosology, fortify
Amy to propose a list of tools
When we align, we can take it to the LF.

14. Preparation for the Adhoc meeting
If we have something to propose regarding pwd handling etc, then we can propose it, otherwise take a discussion
For this meeting, the ambition should be to understand the questions/needs.
Maybe we have initial recommendations based on seccom’s collective experience, or maybe we have to take actions
For the CA discussion
We should listen to the proposal and take a discussion.
Other thoughts?

15. September developers event
Possible topics to raise
Known vulnerability scanning
Update from CII badging programe certification attempt feedback.
Static code scanning.
Purpose:?
Status update or pro-active security advise regarding best practices.
Don/zyg can help put together material
Still open to who will present due as its best to be physically present.
Stephen to include security as a topic in the September Developers event list of topics.