Found a security problem in our services?
Our responsible disclosure procedure is described here, including what can (not) be reported, conditions, and our reward program. Important information is also structured in our security.txt. Note that this procedure must not be used to report unavailable or incorrectly functioning sites and services.
Part of our reward program is a registration in our hall of fame:
Responsible Disclosure - Hall of Fame >
Our responsible disclosure procedure covers all Dutch Achmea brands, as well as a number of international subsidiaries. These are:
Dutch Brands
- Achmea
- Avéro Achmea
- Centraal Beheer
- De Friesland Zorgverzekeraar
- Eurocross
- FBTO
- InShared
- Interpolis
- De Christelijke Zorgverzekeraar
- Woonfonds
- Zilveren Kruis
International subsidiaries
- Achmea Australia
- Eureko Sigorta
- Interamerican
- Union
Some of our initiatives are also covered by this procedure. These are:
What can you report?
You can report security vulnerabilities in on our services. Examples include:
- Cross-Site Scripting (XSS) vulnerabilities.
- SQL injection vulnerabilities.
- Weakly configured secure connections.
- Vulnerabilities in (mobile) applications.
What can you not report?
This responsible disclosure procedure does not cover complaints. Furthermore, the procedure is not meant for:
- reporting of unavailable sites or services.
- reporting of incorrectly functioning sites or services.
- reporting fraud.
- reporting fake (phishing) email messages.
How can you report?
You can you report a discovered vulnerability in our services through the contact form at the bottom of this page or through the email address mentioned in our security.txt.
Clearly describe in your report how the vulnerability can be exploited. Clarify your findings with additional material, such as screenhots and a step-by-step explanation. Note the exact date and time that you used the vulnerability. This helps us when we analyze your finding.
Rules
We ask that you do not publish your finding, and that you only share it with Achmea’s experts. The time you give us to analyze your finding and to plan our actions is very appreciated.
You are not allowed to damage our systems or services. Also, our services must not be interrupted intentionally by your investigation.
It is possible that you break laws and regulations when investigating your finding. We will not file a police report if you act in good faith and work cautiously in the way we ask from you.
We ask that you:
- only contact Achmea about your finding, through the communication channels noted in this responsible disclosure procedure.
- report one finding in each report.
- only do what is strictly necessary to show the existence of the vulnerability.
- refrain from applying social engineering.
- refrain from using generic vulnerability scanning.
- do not install backdoors, for whatever reason (e.g. to show how a vulnerability works).
- do not to copy, change or remove data from our systems. Only send us the minimum of information required to describe your finding. For example, make a screenshot of a directory listing or of file content that shows the severity of the vulnerability.
- do not to influence the availability of our systems.
- refrain from applying brute-force attacks.
- do not share the finding with others.
- do not attempt to exploit the vulnerability after reporting it.
- respond when we ask for additional information about your report.
What will we do with your report?
- You will receive an automated confirmation of that we received your report. We will do our best to contact you about your report within three working days.
- We will only use your personal information to communicate with you about the report, and optionally to facilitate your participation in our reward program. We will not share your information with others, unless we have a legal obligation to do so or if we suspect that you do not act in good faith while performing criminal acts. The latter will be reported to the authorities.
- We will not contact you in any way if you report anonymously.
Conditions of our reward program
- We determine whether if and which reward is offered based on the severity of the security vulnerability. To apply for our reward program, the finding must be valid, significant and new. A reward can consist of:
- A mention in our Hall of Fame, referred at the top of this page and in our security.txt. This will be in agreement with the reporter, of course. We can limit or remove information in our Hall of Fame.
- A T-shirt.
- Gift coupons with a value up to 300 euro.
- A reward will not be offered if the reporter or the report do not conform to the rules of this procedure.
- A reward might not be offered if the report does not concern a security vulnerability or of the vulnerability is not significant. A non-exhaustive list of vulnerabilities not applicable for a reward can be found below.
- Assuming a vulnerability applies to the other conditions, if the same vulnerability is reported multiple times only the first reporter can apply for a reward. Achmea determines if multiple reports apply to the same vulnerability, and does not share details about such reports.
- A given reward will only be provided to a single person.
- Our goal is to reward equally and fairly for similar findings. Rewards and the findings they are rewarded to can change over time. Offered rewards in the past (from Achmea or from other organizations) are no indication for rewards that will be offered in the future.
- Anonymous reports are excluded from participating in the reward program.
Exceptions to the reward program
Achmea can decide that a finding concerning a vulnerability with a low or accepted risk will not be rewarded. Below are several examples of such vulnerabilities. This list is non-exhaustive.
- HTTP 404 codes and other non-HTTP 200 codes
- Run-on type inserted 404 paged.
- Version banners on public services
- Files and folders with non-sensitive information accessible tot he public
- Clickjacking on pages without login functionality
- Cross-site request forgery (CSRF) on forms accessible anonymously
- A lack of ‘secure’ or ‘HTTP Only’ flags on non-sensitive cookies
- Use of HTTP OPTIONS method.
- Host header injection
- Absence of SPF, DKIM and DMARC records
- Absence of DNSSEC
- Absence or incorrectly applied HTTP security headers, including but not limited to:
- Strict-Transport-Security (HSTS)
- HTTP Public Key Pinning (HPKP)
- Content-Security-Policy (CSP)
- X-Content-Type-Options
- X-Frame-Options
- X-WebKit-CSP
- X-XSS-Protection