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]> 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 > > > > [image: 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 <+34%20609%2016%2085%2015> > [email protected] > www.ericsson.com > > > > [image: 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 > > > > _______________________________________________ > ONAP-TSC mailing list > [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
