OpenNCP Task Force - Security

12 Jan 2016

Estimated - 13:30 to 14:30 CET

Performed - 13:35 to 14:30 CET

AGENDA

0. Housekeeping (Jerome)

1. Formalization, advices and security policies

Control or audit the correctness and safety of an NCP installation.
Code quality review tool also related to the release management process.
Formalizing security requirements necessary for entry the trust zone (client and National Implementation).

2. Technical vulnerabilities and remediation

Analysis of the assertions provider (HCPA and user Assertion), TRC-STS component.
Situation of the clients (Portal and epSOS-Web).
Detailed review of the vulnerabilities document (Nathan).

3. AOB

Testing secured web services (impossible to parse XSD with the current way of importing them).
Real B to B test session organised with Luxembourg NCP.
Test session of the components with the help of EC experts (Gwen).

4. Next meeting

LOCATION

Adobe Connect: http://ec-wacs.adobeconnect.com/openncp/

Room Passcode: (Ask if necessary)

----------------

If you have never attended an Adobe Connect meeting before:

Test your connection: http://ec-wacs.adobeconnect.com/common/help/en/support/meeting_test.htm

Get a quick overview: http://www.adobe.com/products/adobeconnect.html

Adobe, the Adobe logo, Acrobat and Adobe Connect are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.

PARTICIPANTS

Today's Meeting Participants:

Kostas Karkaletsis

Heiko Zimmermann

Marco Bernardini

S

Nathan Taku

Gwen Quivy

Ngantchjon Eric

MEETING NOTES:

0. Housekeeping (Jerome):

S Security task force is the group in charge of fixing known security issues, and providing security policies document in order to improve the scalability of OpenNCP components.
A first testing session (security and load) has been run from a end to end flow (client --> NCPB --> NCPA).

1. Formalization, advices and security policies:

1. Control or audit the correctness and safety of an NCP installation:
  S and Gwen Quivy explained the content of the vulnerability and risks, the solution could be to deliver a control and audit process (document policy or automated script, alerts and QA control procedure).
  Heiko Zimmermann is agree and proposes to use secured audits/logs or an exhaustive check-list which provide all necessary information to validate the correctness of the node. In the other hand, an automated script could be a difficult to put in place because of the platform dependency (Linux, Windows etc.). Reference document D3.8.2 - Getting ready to piloting provides a lot of significant information to do this job.
  TODO: Decision to write a validating check-list document (perhaps part of the installation manual) --> S and Nathan Taku will work on this.
2. Code quality review tool also related to the release management process:
  Gwen Quivy explained the needs to use a QA, code review tool in order to keep the source code safe, and also the commit process and the role of the release management process team.
  Kostas Karkaletsis provides information related to the release management process and how it works into the community, we should adopt a strategy of peer review made by the RM team. Some tools were tested and it would be a nice idea to integrate one automatic tool into the release process which provides quality metrics etc about the source code.
  S EC will host the collaborative tool then a source code analyser will be selected and deployed.
3. Formalizing security requirements necessary for entry the trust zone (client and National Implementation):
  S this topic is linked to the previous point 1.a, and it will be included into the check-list for safe infrastructure also related to document D3.8.2.

2. Technical vulnerabilities and remediation:

1. Analysis of the assertions provider (HCPA and user Assertion), TRC-STS component.
  S this topic will be discuss into another meeting related to the implementation deviations and we will discuss about it later inside the security group.
2. Situation of the clients (Portal and epSOS-Web).
  S OpenNCP Portal and epSOS-Web client are not an official implementation/components of the OpenNCP but because they are available as a POC we have to ensure that they are secured client, the decision have been made to fix the security issues found because they are not so complex and time consuming.
  Kostas Karkaletsis proposed to configured the portal in a secure mode and execute once again the security tests. One page has been created to list the issues and how to fix them, this page is private and limited to the security group.
  TODO: Marco Bernardini and S will fix the issues into the epSOS-Web client and Kostas Karkaletsis and S will fix the issues linked to the Portal.
  Then Nathan Taku will execute a new security test session.
3. Detailed review of the vulnerabilities document (Nathan).
  Nathan Taku has explained the vulnerabilities in details and the guidelines to follow in order to solve the issues.
  Heiko Zimmermann ask what is the strategy that we will adopt: fixing issues, providing secured client, providing guidelines "how to secure the client", and I'm agree to fix the security issues, it will improve the quality of the clients and the components.
  S proposes to ask the question into the next Bi-weekly meeting and if the community in general is agree with our roadmap. The main idea is enhancing confidence through clients components by removing security risks.

3. AOB:

Testing secured web services (impossible to parse XSD with the current way of importing them).
Eric Ngantchjon: there is a problem for the parsers to load xsd files throughout an url because there are embedded into the war and jar archive. Our security and load software cannot read file when there are imported as it is describe after:
<xsd:include schemaLocation="XCPD_Service?xsd=schema/XXX.xsd"/>.
For the time being we use a workaround by adding manually the XSD files in order to execute properly the schema validation.
Is it possible to use a different way for WSD packaging into the ws-server web application?
S the XSD are all packaged into a zip file "schema.zip", this is a strange situation while the schemas are available throughout the browser.
Please Kostas Karkaletsis if you have an idea about this topic or an advice?
Real B to B test session organised with Luxembourg NCP:
Heiko Zimmermann is ok to start a real security test session with the PPT NCP node hosted in Luxembourg, but first we need to fix the known issues (not overcome the security test).
An external provider is doing some tests on the Luxembourg node and I perhaps could share the result with the group.
Do we execute the security test between LU and EC software through the VNP or not?
S if it's possible yes because the objective is to test a "Production mode" node, so if it's possible without proxy restriction etc. problem, we will try.
Test session of the components with the help of EC experts (Gwen).
Gwen Quivy: we will use the WhiteBox testing tool and we have requested support from EC to execute security tests components per components because of the User assertion generation necessary when .
Kostas Karkaletsis proposes his help about required security assertions required by the WSDL.
Heiko Zimmermann They are remaining questions about security relaxation as also explainend by Stéphane Spahni during the last technical committee (X509 certificates, merge of the certificates, the number of required certificates, SHA2 etc).
Deliverable 3.8.7 and 3.8.2 could help to answer or understand the relaxation, it's difficult to find a written relaxation. Maybe Marcello Melgara could help to find the info into the deliverables.
5 + 1 certificate for OSCP respond --> more info into the maintenance shop of Expand project.
Reference document:

4. Next meeting:

Deviation meeting schedule 13 Jan 2016 at 11:00 CET.
Task Force Meeting Not yet planned, probably in 2 weeks.