Hi Phil, Thanks for the good questions. Regarding the “nexus-IQ scanning” we will be clearer when bring the recommendation to the TSC for approval. It was intended for high. For “not handled by onap component” I could have been clearer in the email – what I meant to say was to address the issues – addressing could be identifying that the issue is not relivant to the way that ONAP uses the code.
For the attack vectors, that’s a great idea – let me take it back to the team and we can put this on the backlog. BR, Steve From: Phil Robb [mailto:[email protected]] Sent: 20 December 2017 19:16 To: Stephen Terrill <[email protected]> Cc: onap-tsc <[email protected]>; [email protected] Subject: Re: [onap-tsc] Report to the ONAP TSC from ONAP security sub-committee Hi Steve: Thanks for the writeup and all your efforts on the Security Subcommittee in 2017. On the recommendations below, for the Nexus-IQ scanning, you state a recommendation of "M4 & release criteria to be "not releasing modules with vulnerabilities more than 60 days old". You do not state what severity level that applies to. Does it apply to all severity levels (there are many that are moderate/low risk), and does it apply if the vulnerability is not actually exposed by ONAP's use of the component?... ie vulnerabilities are often tied to how the component is used within ONAP. Is there a proposed process to evaluate vulnerabilities, determine their impact, the level of difficulty to remove/replace the component, etc? It seems as though all of that due diligence would be needed to make a judgement call on if a vulnerability were a show-stopper for a release or not. Second, and unrelated, I have been wondering if the Security subcommittee would find it helpful to the community to document the various attack surfaces that ONAP has and to identify what, if any tooling, counter-measures, etc exist for each, what has been covered, what is a continued gap, etc. Such attack surfaces are: - South-bound interfaces - communication with controllers, EMSs, VIMs, VNFs, etc. What authentication, authorization, and encryption are or can be put in place for these interfaces? - East/West interfaces - communication with other orchestrators, VNFCs, etc. "" - North-bound interfaces - Portal access, External API access, etc. - Component/Upgrade Security. How to ensure each ONAP component is an authentic part of the ONAP system? How to allow, but secure component upgrades? ... etc. Those are in addition to what we know we are already focused on such as: - ONAP code vulnerabilities - 3rd Party component published vulnerabilities (CVEs) Given the broad scope of "ONAP Security", would we find it helpful to spell out all the different types of security that we can imagine when dealing with this system, prioritizing what are most important, identifying where we have good/medium/poor coverage of a particular attack-surface and long range plans/aspirations on improving them? Please let me know your thoughts when you get the chance. Best, Phil. On Wed, Dec 20, 2017 at 10:27 AM, Stephen Terrill <[email protected]<mailto:[email protected]>> wrote: Hi, This is the last report from the ONAP security sub-committee. Firstly I would like to thank that participants for their contribution during 2017, its been great to have the team established and up-and going. We have been focussing on a few topics recently. Static Code scanning * Static code scanning is the scaning of ONAP produced code in search of not-yet known vulnerabilities in the code. * We have agreed on the following recommendation: * Use coverity for static code scaning * Request to integrate it into the CI/CD toolchain, with an email once a week to PTLs * Host a session to support the PTLs in the analysis. * To request the inclusion of the following MS criteria * MS-3 – no high vulnerabilities * MS 4 and release no medium vulnerabilities * This recommendation will be raised to the TSC for decision in January. Scanning for known vulnerabilities * Scanning for known vulnerabilities refers to the identification of vulnerabilities in modules that are outside of ONAP but that ONAP components rely on. This can re-use the NEXUS-IQ tool that is used for the licence scanning as presented by Phil Robb at the developers event. * The ONAP security sub-committee has agreed on the following recommendation * Open the tool to the PTLs (or whomever they nominate) * Request that the MS4 and release criteria: not releasing modules with vulnerabilities more than 60 days old. * Exceptions raised and discussed with the TSC. * Recommend to host a session to walkthrough the Nexus IQ tool with the PTLs if required. * Note: A demo was done and is available from the December ONAP Developers Event from Phil Rob. * This recommendation will be raised to the TSC for decision in January. Configuration scanning * This is the scanning of the installed infastructure (https://norad.gitlab.io/ ) * We thought that this was a good idea and propose to discuss with the integration team (Helen, I will setup a meeting with you for this). Support of 3SP with the CII badging program. * We have agreed to produce a “guide” for the projects for the CII badging program, this is to help with the questions that have a common answer for all projects, or a hint at how to answer this in the ONAP setup. * The plan is to have this ready by the end of january. * The we propose to have an online session for interested PTLs (or whom they nominate) to help the projects get started and answer initial questions. Best Regards, Steve [Ericsson]<http://www.ericsson.com/> STEPHEN TERRILL Technology Specialist POA Architecture and Solutions Business Unit Digital Services Ericsson Ericsson R&D Center, via de los Poblados 13 28033, Madrid, Spain Phone +34 339 3005 Mobile +34 609 168 515<tel:+34%20609%2016%2085%2015> [email protected]<mailto:[email protected]> www.ericsson.com<http://www.ericsson.com> [http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign> Legal entity: Ericsson España S.A, compay registration number ESA288568603. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer> _______________________________________________ ONAP-TSC mailing list [email protected]<mailto:[email protected]> https://lists.onap.org/mailman/listinfo/onap-tsc -- Phil Robb Executive Director, OpenDaylight Project VP Operations - Networking & Orchestration, The Linux Foundation (O) 970-229-5949 (M) 970-420-4292 Skype: Phil.Robb
_______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
