De dienst healthdata.be (Sciensano) behandelt elke melding van een incident volgens een Standard Operating Procedure (SOP). Een publieke versie van deze SOP "HD Incident Management Process" is ook beschikbaar op deze docs.healthdata.be portaal.

Om een incident te melden met betrekking tot de registers en applicaties die in productie zijn, en gefaciliteerd of beheerd worden door de service healthdata.be van Sciensano, dient u eerst in te loggen op het HD Service- en Supportportaal: Jira Service management (JSM).

Meer informatie over het aanvragen van een account vindt u hier.

Na de inlogstap komt u op de hoofdpagina van het portaal.

Om een ticket te starten, selecteer "Create a Support ticket"

U ziet dan de onderstaande pagina. Zodra u alle verplichte velden hebt ingevuld, klikt u op “Send”.

Om een verzoek om informatie over het healthdata.be platform in te dienen, moet u eerst inloggen op het HD Service- en Supportportaal: Jira Service management (JSM) portal.

Na de inlogstap komt u op de hoofdpagina van het portaal.

Als u vragen of opmerkingen heeft, of als u een klacht wilt indienen, kunt u dit doen door op de knop ‘Verbetering suggereren’ op de hoofdpagina van het Jira Service Management-portaal te klikken

WHAT IS THE PROBLEM?

Sciensano blocks e-mails from organizations if the configuration of their e-mail and/or DNS services allow potential abuse by spammers/attackers. More specifically, if the configuration enables other senders to impersonate your organization by allowing them to mimic your organization’s e-mail “Header From”.

In other words, they can send phishing and spam mails that cannot be distinguished from genuine mails from your organization.

If you’re responsible for managing your ICT infrastructure, keep reading. If not, pass this message on to your ICT department or to the ICT service that’s managing your ICT infrastructure.

HOW TO SOLVE IT?

You’ll have to verify that your configuration complies with “Sender Alignment” security requirements.
More specifically, your mail services and DNS will have to be configured according to ICT standards.

These configurations are common, well-documented and supported by hosting companies. Some useful links:

• https://dmarcian.com/alignment/
• https://mxtoolbox.com/dmarc/spf/spf-alignment
• https://o365info.com/how-does-sender-verification-work-how-we-identify-spoof-mail-the-fiveheros-spf-dkim-dmarc-exchange-and-exchange-online-protection-part-9-of-9/

We’ve noticed that this issue frequently occurs in organizations which moved their ICT infrastructure to cloud services such as Microsoft (O365), Amazon, Google, and MS Azure without properly configuring the ICT infrastructure which is not managed by these providers.

The configurations and recommendations need to be implemented on the customer’s ICT infrastructure, either internally or externally. DNS and Mail services are the main ICT platforms for these actions.

THE USE OF DIFFERENT DOMAINS IN THE MAIL SENDING PROCESS

E-mails contain an “Envelope From” and a “Header From”. Both need to match to avoid that the mail is blocked.

Some examples:

1. A public service is using its new domain name in the “Header From” and its old domain name in the “Envelope From”.

• Envelope From = noreply@publicservice.fgov.be
• Header From = noreply@publicservice.belgium.be

➔ These e-mails will be blocked.

Remark: Because it’s a noreply address, the sender will not even be aware of us rejecting the e-mail …

2. An organization is using a cloud service (Freshservice) for its helpdesk tool and the “Envelope From” has not been customised.

• EnvelopeFrom = bounces+us.3.52773-helpdesk=organisation.be@emailus.freshservice.com
• Header From = helpdesk@organisation.be

➔ These e-mails will be blocked.

3. A company uses a cloud service (Amazon SES) to send the delivery notification and the “Envelope From” has not been customized.

• Envelope From = 01020188573f374-96de6437-9134-45f4-8aa6-3e9ac18d5848-000000@euwest-1.amazonses.com
• Header From = noreply@company.be

➔ These e-mails will be blocked.