1. Hub architecture
Security

2. Census and ICT Hub (key issues)
Dissemination of aggregated data
No confidential data will be disseminated
Data are public
Single point for retrieving the data
Hosted in the European Commission premises
Countries are the owners of the data and should use the confidentiality policy at country level (applicable for the census data)
The client and the server should be protected (security mechanisms, protection and prevention)

3. C L I E N T side (Census Hub, ICT Hub, Etc.)
Security
C L I E N T side (Census Hub, ICT Hub, Etc.)

4. Decoupling and the Commission Data Centre
Purpose + architecture

5. Web Service security (Census and ICT)
Census/ICT Hubs are client applications and they support:
HTTP Basic Authentication
- Example Use Java
- Example Use .NET
WS-Security UsernameToken Authentication
HTTPS – 1 way SSL (server certificate)
For the Census Hub purposes, as the data are not confidential, WS security is not required. But if you decide to reuse your WS for other data exchange you might need to put security mechanism in place.
Basic Authentication for WS is not recommended, it is usually best to distinguish between the transport and the message, to allow routing and transformation. Authentication within the enveloppe is favoured.
The HTTP basic authentication uses a username and password to authenticate a service client to a secure endpoint. The basic authentication is located in the HTTP header that carries the Simple Object Access Protocol (SOAP) request. When the application server receives the HTTP request, the username and password are retrieved and verified using the authentication mechanism specific to the server.
Before transmission, the user name is appended with a colon and concatenated with the password. The resulting string is encoded with the Base64 algorithm. For example, given the user name 'Aladdin' and password 'open sesame', the string 'Aladdin:open sesame' is Base64 encoded, resulting in 'QWxhZGRpbjpvcGVuIHNlc2FtZQ=='. The Base64-encoded string is transmitted in the HTTP header and decoded by the receiver, resulting in the colon-separated user name and password string.
The general concept behind a token-based authentication system is simple. Allow users to enter their username and password in order to obtain a token which allows them to fetch a specific resource - without using their username and password. The WS-Security UserName Token mechanism allows sending and receiving of user credentials in a standards-compliant manner.
HTTPS Authentication established by Secure Sockets Layer (SSL) connection for secure communication between a sender and recipient. The sender is always regarded as the SSL client, and the recipient is regarded as the SSL server.
Two kinds of certificates are used in HTTPS authentication:
Server certificates: This certificate contains information about the server that allows a client to identify the server before sharing sensitive information.
Client certificates: This certificate contains personal information about the user and identifies the SSL client (the sender) to the server.
Census Hub supports/uses only server certificates
Secret Sockets Layer (SSL) provides secure connection that guarantees data confidentiality and data integrity by encrypting the data transferred between 2 applications or between a user and a web application.
1 way SSL and identification token, if the user is unknown, the system will notice it later in the process. That will consume resources on the system. 5

6. No SSL vs. 1 way SSL vs. 2 way SSL
Two steps analysis:
Step 1: NO SSL vs. SSL
Advantages
More secure
Control the access
Advantages
More secure
Control the access
Disadvantages
Regular Renewal
Complex Installation
Configuration
Troubleshooting
Performance
Extra work
Disadvantages
Regular Renewal
Complex Installation
Configuration
Troubleshooting
Performance
Extra work
Disadvantage: Regular Renewal Like a website domain and hosting plan, an SSL certificate expires after a short period of time—usually one to five years. You have to renew the SSL protection regularly and pay the subscription price again forever in order to keep the protection. If you forget to renew the SSL protection, your website will display an error on the user's computer stating that the certificate is not valid.
Disadvantage: Complex Installation SSL technology can be difficult to install on a website, especially for someone who isn't very familiar with website development. The provider will send you a set of files to install in a certain folder of your web server. You must also activate the certificate using specific instructions from the provider. The process can be overwhelming for a beginner, and some trial-and-error may be required to get the technology to work properly on your website.
more secure All web connections between the application tier, the data tier, are more secure because they require certificates.
control the access You can control access more easily by configuring certificates to expire when a project phase is expected to end.
Configuration You must not only configure but also manage a certification authority (CA) and certificate trusts.
troubleshooting You must spend significant time setting up and testing either of these configurations, and troubleshooting your deployment will become more difficult.
performance If you require HTTPS with SSL, your deployment's performance will be slower.
extra work it requires both parties to the communication to do extra work in exchanging handshakes and encrypting and decrypting the messages, making this form of communication slower than communication without SSL.

7. 1 way SSL vs. 2 way SSL Step 2: 1 way SSL vs. 2 way SSL
When using 1-way or 2-way ssl?
2-way SSL is far more complicated
In 90% of the case the use of 1 way SSL is recommended
Validity of 1 year max
CA internal to the commission, so usually, the server would still have to grant that CA explicitly
Advantages of using 2-way SSL
Limits the risk of flooding attacks
DIGIT recommendations: 1 way SSL and identification token
Secret Sockets Layer (SSL) provides secure connection that guarantees data confidentiality and data integrity by encrypting the data transferred between 2 applications or between a user and a web application.
We can have one-way SSL (only the server has to be identified through a server certificate) or two-way SSL (both client and server have their own certificate).
In a complete solution, securing the channel is not enough. We also need to identify the client and maybe also, based on his security profile (roles and groups he belongs to), check the resources he is allowed to access.
We have 2 choices:
One-way SSL + identification token (user-name token, binary x509token,…) => see section 5.6
Two-way SSL with identification based on the client certificate => see section 5.4
Using Policy Files with JAX-WS? For maximum portability, Oracle recommends that you use WS-Policy 1.2 and OASIS WS-SecurityPolicy 1.2 with JAX-WS.
TIP:
To increase security, it is also possible to add access control to limit the access of the service methods to only users with the right role(s) by adding some security constraints to the web.xml (JAX-RPC ad JAX-WS) or by using annotation (JAX-RPC only) as we have seen in section 5.4.
2-way SSL is far more complicated because you need to manage certificate of the users and the added value is not really big. So in 90% of the case, we advice you to use 1 way SSL.
The only advantage of using 2-way SSL is that it limits the risk of floading attacks. Indeed, if we accept only users we know, request from unknown users will be rejected more rapidly (during https handshake and not by the service itself). In this case, unknown users have less impact on the system performance.
Indeed, if we accept only users we know, request from unknown users will be rejected more rapidly (during https handshake and not by the service itself). In this case, unknown users have less impact on the system performance.
1 way SSL and identification token, if the user is unknown, the system will notice it later in the process. That will consume resources on the system.

8. S E R V E R side (SDMX Reference Infrastructure)
Security
S E R V E R side (SDMX Reference Infrastructure)

9. Security testing SDMX-RI
Vulnerability
Number of tests
Fuzzing Scan
500 requests testing 10 or more xml attributes and values
Invalid Types
1300 invalid xml types requests
SQL Injection
710 requests sql injections
Malformed XML
300 malformed xml requests
XML Bomb
142 xml bomb requests
XPath Injection
510 xpath injection attempts

10. Malformed Requests Sent Vulnerabilities detected
Results
Web Service Method
Requests
Warnings
Vulnerabilities
GetCompactData
Sample1
521
None
Sample2
630
Sample3
790
QueryStructure
761
715
SDMX-ML query
Malformed Requests Sent
Alerts Raised
Vulnerabilities detected
GetCodelist
834
None
GetStructureSpecificData
1049

11. List of the security threats tested (OWASP) A1: SQLi Injection
A2: Cross-Site Scripting (XSS)
A3: Broken Authentication and Session Management
A4: Insecure Direct Object References
A5: Cross-Site Request Forgery (CSRF)
A6: Security Misconfiguration
A7: Insecure Cryptographic Storage
A8: Failure to Restrict URL Access
A9: Insufficient Transport Layer Protection
A10: Unvalidated Redirects and Forwards
A1: Injection
SQLi occurs at the database level of an application. It is said to be the most common hacking technique, which attempts to pass SQL statements through a web application for execution on the database. With such a type of attack, data can be stolen or deleted from a database.
A2: Cross-Site Scripting (XSS)
XSS concerns an application-layer attack. It attempts to inject client-side scripts into web pages. With such type of attack a user can have access to information that browser maintains on behalf of the victim.
A3: Broken Authentication and Session Management
Consider anonymous external attackers, as well as users with their own accounts, who may attempt to steal accounts from others. Also consider insiders wanting to disguise their actions.
A4: Insecure Direct Object References
Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws and code analysis quickly shows whether authorization is properly verified.
A5: Cross-Site Request Forgery (CSRF)
CSRF takes advantage of web applications that allow attackers to predict all the details of a particular action. Since browsers send credentials like session cookies automatically, attackers can create malicious web pages which generate forged requests that are indistinguishable from legitimate ones. Detection of CSRF flaws is fairly easy via penetration testing or code analysis.
A6: Security Misconfiguration
Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, framework, and custom code. Developers and network administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc.
A7: Insecure Cryptographic Storage
The most common flaw in this area is simply not encrypting data that deserves encryption. When encryption is employed, unsafe key generation and storage, not rotating keys, and weak algorithm usage is common. Use of weak or unsalted hashes to protect passwords is also common. External attackers have difficulty detecting such flaws due to limited access. They usually must exploit something else first to gain the needed access.
A8: Failure to Restrict URL Access
Applications are not always protecting page requests properly. Sometimes, URL protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget. Detecting such flaws is easy. The hardest part is identifying which pages (URLs) exist to attack.
A9: Insufficient Transport Layer Protection
Applications frequently do not protect network traffic. They may use SSL/TLS during authentication, but not elsewhere, exposing data and session IDs to interception. Expired or improperly configured certificates may also be used. Detecting basic flaws is easy. Just observe the site’s network traffic. More subtle flaws require inspecting the design of the application and the server configuration.
A10: Unvalidated Redirects and Forwards
Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page is specified in an unvalidated parameter, allowing attackers to choose the destination page.

12. OWASP compliance Census HubID
Vulnerability
Number of warnings or vulnerabilities found A1
Injection
None A2
Broken Authentication and Session Management A3
Cross Site Scripting (XSS) A4
Insecure Direct Object References A5
Security Miss configuration A6
Sensitive Data Exposure A7
Missing Function Level Access Control A8
Cross Site Request Forgery (CSRF) A9
Using Components with Known Vulnerabilities
A10
Un-validated Redirects and Forwards

13. OWASP compliance SMDX-RIID
Vulnerability
Number of warnings or vulnerabilities found A1
Injection
None A2
Broken Authentication and Session Management A3
Cross Site Scripting (XSS) A4
Insecure Direct Object References
N/A A5
Security Miss configuration A6
Sensitive Data Exposure A7
Missing Function Level Access Control A8
Cross Site Request Forgery (CSRF) A9
Using Components with Known Vulnerabilities
A10
Un-validated Redirects and Forwards