Home / Terms & Conditions / DPA Security Measurements

DPA Security Measurements

Organizational generic measures

Yenlo has the following generic organisational security measurements in place for the total group and all employees and services provided towards our customers.

We work conform Certifications as mentioned in article 5.2 of the DPA.
We are ISO9001, ISO27001 and NEN7510 certified.
To prevent data loss, and support disaster recovery, data is frequently backed up.
Backup and restore: Regular (quarterly) Business Continuity Plan testing.
Regular Audit controls, including Configuration Audit.
Awareness training. All Yenlo staff enters in a yearly security awareness training.
Knowledge Management. The Yenlo System Handbook describes the security principles and guidelines all Yenlo employees are subject to. The Yenlo Employee Handbook promotes the “Safe use of information systems”.
Certificate of Good Conduct/Personal screening of all employees. For each employee at Yenlo, a VOG (Certificate of Good Conduct) statement will be requested and kept up to date. For foreign employees, the way in which relevant screening information can be collected shall be checked.
Identity, Access and Network security policies. Multi-Factor-Authentication is applied if and where possible.
Password management. Yenlo uses secure password management with 2-factor authentication to safeguard access to admin accounts.
We have a dedicated security officer (securityofficer@yenlo.com).
Security incident and response management.
Every suspected breach of security is reported to the security officer, who informs the Data Controller, who on its turn informs the local Privacy Authority, if needed.
Secured laptop’s with aggressive encryption policies and anti-virus scanners.

Connext Platform specific measures

Next to the generic organisational security measurements we have specific for our Connext Platform solution/service additional security measurements in place as well.

Security Model

Unsurprisingly, the Yenlo Connext Platform security model is designed with three layers of responsibility – AWS, Yenlo Managed Services and the Yenlo Connext Customer.
AWS’s prime responsibility is the security of the cloud and the cloud service they offer. This includes the secure housing of computer systems, the secure design, configuration, operation and management of the network, storage and computing equipment. Additionally, AWS is responsible for the security of its cloud services.
Yenlo Managed Services is responsible for the Yenlo Connext Platform managed integration services. This includes the secure configuration, operation and management of the Yenlo Connext Platform – in fact, the configuration of the virtual network, virtual machines and AWS services making up the Yenlo Connext Platform – and the Yenlo Connext Platform Managed Services Team – the design, configuration, operation and management of the middleware.
Yenlo Connext Platform enables secure integration – through offering API Management and Identity and Entitlement services, including two-factor authentication, on top of the core integration and business process security features. Additionally, to prevent message loss, Yenlo Connext Platform comes with a full-fledged message broker. However, it remains the responsibility of the Yenlo Connext Customer to design and manage its policies, to manage its user accounts accordingly, and to govern secure development and data management practices (which includes consent and web token management. To help customers live up to these tasks, Yenlo offers Development Support as a supplementary service. Please ask your account representative for further details.

Shared Responsibilities

In some cases, there are responsibilities which reside with the Yenlo Connext Platform Customer, but require operator intervention to change. Take for instance the adding a new language to the API store. This is clearly a retained control, however, deploying the change in production requires operator permissions. Yenlo Connext Platform has a simple fulfilment process to handle such requests.
Product extensions and customizations as well as changes to the default configuration parameters Yenlo Managed Services has set, is also possible, but will be subject to an assessment to review the security and maintainability impact. Think for instance of a custom grant type, a custom mediator, a custom API handler, or a custom User Store Manager. Such changes potentially deeply impact the managed service Yenlo Connext Platform is committed to provide. Also, our managed services staff will need to know about the changes, albeit only to prevent the next Yenlo Connext Platform release to overwrite them. Therefore, Yenlo Managed Services must be involved in the change process of such adaptations.

Security Policy

Access to the Connext Platform admin consoles only by personal MFA.
All traffic is bi-directional encrypted front-to-back and back-to-front.
All inbound traffic is monitored and protected for DDoS attacks and advanced shielding.
Default Security Settings.
To secure the Yenlo Connext Platform, it is designed and set up with security controls in mind. Specifically, with confidentiality, integrity and availability controls.
Only accept TLS encrypted http connections. Weak ciphers are excluded.
Encrypt all network traffic between the middleware components.
Encrypt data in storage (S3 buckets).
Encrypt credentials in configuration files (using Secure Vault).
Encrypt data in databases (RDS).
The Yenlo Connext Platform application modules are only accessible over a Bastion Host:
Services are public available only over an API Management gateway.
Connext Platform and/or applications running on top of, are only available over secured VPN access.
For management, Yenlo operational support team, has direct access to AWS resources using a secured VPN tunnel.
Only necessary ports are open for access.
Only necessary URL paths are made available over a reverse proxy.
A strictly limited set of permissions is granted to the customer admin to use the management console.
Core servers are separated from servers that support management and development.
Software deployment and configuration is reproducible (i.e. scripted).
Data is frequently backed up.
Availability controls (production servers).
All core servers are clustered.
Cluster members are distributed over multiple availability zones.
All servers and platform services are monitored 24×7.
Recovery of failing servers is automated (auto-healing).

Security Process

Technology alone will not be sufficient to provide a secure platform. Therefore, Connext Platform has additional security processes defined.
Log collection and analysis. On top of default analytics from the middleware products, Connext Platform includes a monitoring server which hosts the health dashboard and analysis log files for potential security breaches.
Patch management, particularly urgent security patches. As soon as technology vendors publishes a security patch, the Yenlo Connext Platform security officer creates a deployment plan.
Backup and restore. To prevent data loss, and support disaster recovery, data is frequently backed up.

Penetration testing

Regular pen tests (black box testing).
As always, the proof of the pudding is in the eating. No matter how good we try, testing the outcome is still important, especially in a multi-party setting. So, penetration testing by a third party is a sensible control to manage residual risks, and Connext Platform endorses the practice.
Penetration testing does require proper preparation, where Yenlo Managed Services needs to be involved. Note that AWS requires prior permission to run a penetration test. Also, Yenlo needs a reasonable lead time to assess your test plan and to plan for resources to help run the test and collect the results. Usually, we need at least two weeks to prepare. When tests are planned during non-office hours, or during the holiday season, please allow for a more generous lead time.

For the respective Security at the Sub-processors AWS and WSO2 (for both Connext Platform and Connext GO), we refer to:

Amazon Web Services	Overview of Security Processes	https://d1.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf
WSO2 Documentation	Security Guidelines for Production Deployment	https://docs.wso2.com/display/ADMIN44x/Security+Guidelines+for+Production+Deployment
WSO2 Documentation	ESB Security Implementation	https://docs.wso2.com/display/EI6xx/Security+Implementation
WSO2 Documentation	Working with Security	https://docs.wso2.com/display/AM210/Working+with+Security
WSO2 Documentation	Consent Management	https://docs.wso2.com/display/IS570/Consent+Management
WSO2 Documentation	General Data Protection Regulation (GDPR)	https://docs.wso2.com/display/IS570/General+Data+Protection+Regulation
OWASP	The Open Web Application Security Project	https://www.owasp.org/index.php/Main_Page
WSO2	Secure application development guidelines	https://wso2.com/technical-reports/wso2-secure-engineering-guidelines
WSO2	Security Advisories	https://docs.wso2.com/display/Security/Security+Advisories

Connext GO specific measures

Next to the generic organisational security measurements we have specific for our Connext GO solution/service additional security measurements in place as well.

Organizational

Within Yenlo, only people from the relevant team can work on the environment.
Credentials for access are only stored in the relevant segment within our password management tool, meaning only Connext GO! employees have access (is centrally arranged).
For the management of the environment itself, only the people of Internal IT have access to the machines.

Technical

Secure Coding practices are guaranteed through automatic processes in the development process of our links.

Security

Data storage limited to strictly necessary. By definition, our links do not store any data. Only if an integration process needs to hold in-flight data is it temporarily stored and deleted as soon as possible or as soon as the integration process is completed.
Input validation. Messages delivered on our links are validated for syntax and content.
Password and certificate management is decoupled from the development process. The developer can only specify passwords and certificates that are required for development purposes. The CI/CD process enforces passwords for deployment purposes overwriting any developer-specified passwords.
The middleware we use for our links provides us with an abstract configuration language with which links are built. This abstraction layer provides protection against SQL injection attacks and code injection attacks as well as logging and monitoring capabilities.
Least privileged principle. Software runs with the minimum privileges required for that process.

Quality

Peer code reviews ensure code quality assurance through (at least) a four-eyes principle.
Code quality verification tooling enforces code-style best practices and prevents known pitfalls.
CICD pipelines are designed to perform an additional objective control step during the building and assembly of a deployment artifact.
Automated testing detects regression and ensures that what has been laid down in designs has been built as such.
Documentation of interface designs, infrastructure and software architecture and technical implementation of interfaces are secured in a central location and the maintenance of this documentation is an integral part of the applied SDLC (Software Dev LifeCycle).
Quality metrics for a continuous improvement process.

Monitoring

System monitoring on the platform as a whole.
Audit logging; An audit location has been set up on the management console of our middleware. Access to administrative consoles is only possible for read access.
Message tracing; For root cause analysis, there is limited historical insight into link message traces. After a specified period, message traces are automatically removed from the platform.
Alerting; The platform contains alerting that notifies support employees in the event of problems.
Metrics; the platform contains (for internal employees) insight into resource use of link instances with which infrastructure monitoring and alerting is also set up.

For the respective Security at the Sub-processors AWS and WSO2 we refer the Connext Platform section.

Central Aansluitpunt (CA) specific measures

Next to the generic organisational security measurements we have specific for our CA solution/service additional security measurements in place as well.

In principal has Yenlo no access to any personal data to any (personal) data transmitted in and via the DIGID koppeling (to open up Key registers (Basisregistraties) and National Facilities (Landelijke Voorzieningen). The content in the DIGID koppeling are end to end encrypted. Even for Yenlo. Despite that, Yenlo is still by the Dutch Privacy Authority considered to be a Data Processor for Centraal Aansluitpunt.

The service Central Aansluitpunt functions on the Connext GO platform, with following specific additional measures.

Technical

All traffic is filtered by IP-filtering.
Access to the platform where the processing takes place is restricted.
- At the front, access is only allowed for contract parties. There are several layers:
  - All traffic is filtered by IP filtering.
  - Two way TLS.
  - All traffic for Dutch based government bodies are protected PKI Government certificates, Authorisation based on authentication data combined with the interface used, based on a certificate. The certificate must be at least of the category ‘organisation validated’, but preferably PKI-O.
- Within Yenlo only people from the CA team can access the machines.
- Networks are segmented.
- Credentials for access are only stored in the CA segment within our password management tool. Only CA employees have access to this tool (is centrally arranged).
- In the data centres, only the people who are authorised have access to the machines. Within Yenlo this is limited to a small number of people (in 2019 there are 5), who have to be registered for all activities on-site.
The most recent security standards are used to maintain optimal security and to protect privacy.
Annual penetration tests by external companies.
Active patch management (weekly).