Why penetration tests at ISO27001 audits?

As part of the ISO 27001 certification process, auditors are increasingly asking to see a penetration test report. But where does this requirement come from if the word pentest or penetration test does not exist in the text of ISO 27001?

ISO 27001 is the international standard for setting up and operating an ISMS (Information Security Management System). Appendix A of this standard contains control objectives for implementation. A more specific explanation of the individual controls can be found in the ISO 27002 standard, which corresponds in its document structure to the control objectives of Appendix A of ISO 27001.

In Appendix A of ISO 27001, section A.18.2 now contains the requirement to carry out “information security reviews”. The ISO27002 implementation guideline for this control includes performing vulnerability scans and/or penetration testing as a solution to fullfill this requirement.

Requirements for penetration tests of DiGa APPS – Penetration test for digital health applications in the german fast-track procedure

In order to be included in the register of reimbursable digital health applications (DiGa), the fast-track procedure at the BfArM must be completed. With the Digital Supply and Care Modernization Act (DVPMG), the corresponding guideline included the requirement that company applicants must have a penetration test carried out for their DiGa application.

Penetration tests: With the DVPMG, this requirement was included in the DiGAV for all DiGA. Ensuring the security of the data throughout the entire application process and all conceivable usage scenarios is an essential requirement for DiGA.
Penetration tests enable the simulation of possible attack patterns and can thus help to uncover security gaps. For the product version for which inclusion in the DiGA directory is requested, a penetration test must have been carried out for all components. These tests are to be repeated as required, e.g. B. when new interfaces are added. The implementation concept for penetration tests of the BSI and the current OWASP top 10 security risks are to be used as the basis for the pentest design. Upon request, the BfArM must be provided with proof of the execution of the corresponding tests.

Inofficial translation of:
https://www.bfarm.de/SharedDocs/Downloads/DE/Medizinprodukte/diga_leitfaden.pdf
(document status as of 18 March 2022)

In principle, the requirements for a DiGa pentest can be summarized as follows:

  • Implementation concept for penetration tests of the BSI
  • OWASP Top 10
  • for all components
  • to be repeated as required (e.g. new interfaces)

I have already had several discussions with manufacturers of DiGA apps that they only want to have the actual mobile app (i.e. usually the iOS and Android versions) checked. However, the scope should not include an underlying API, which is used to implement some business functionality, which handles user authentication and is intended to serve as a central storage location for health data.

Of course, a “Mobile App” and an “API” are two different things and the regulation speaks of digital health applications (so Mobile Apps). However, this interpretation of the regulation does not achieve the goal and is simply wrong. The penetration test is intended to ensure “the security of the data throughout the application process” and the penetration test must be carried out for “all components”. Of course, this means that backend systems and APIs in the background are also included in the scope of the penetration test and not just the actual mobile app from the Android or Apple store.

DDoS Ransom E-Mail: black shadow group

A blackmail e-mail from the black shadow group has just arrived at a customer:

FORWARD THIS MAIL TO WHOEVER IS IMPORTANT IN YOUR COMPANY AND CAN MAKE DECISION!
We are the BLACK SHADOW hacker group.
Your network will be DDoS-ed starting 12:00 UTC+1 on 08 May 2021 if you don’t pay protection fee – 10 Bitcoins @ 1FfmbHfnpbZjKFvyi1okTjJJusN455paPH
If you don’t pay by 12:00 UTC on 08 May 2021, attack will start, your service will go down permanently. Price to stop will increase up 5 BTC for every day of attack.
This is not a joke. We are the BLACK SHADOW liberty hackers.
Our attacks are extremely powerful – sometimes over 1,3 Tbps per second. And we pass CloudFlare, Link11 and others DDoS protections! So, neither cheap or expensive protection will help.
Try to reply, we will not read. Pay and we will know its you.

Mail black-shadow@protonmail.com

In fact, about 200GBits ingoing traffic on the uplink. Mainly UDP traffic. We had to blackhole the attacked IP addresses from the network and put new IPs on the services. Everything was back online in an hour when the traffic in DeCIX was thrown away by their routers due to the null route. Fortunately, the attacker did not react to our evasion technique.

The PCI Council’s response regarding a monitoring-only WAF (Req. 6.6, PCI DSS 3.0)

On July I wrote a blog post about the modified Requirement 6.6 in PCI DSS 3.0. I am not going into the details again, it’s sufficient to say that the new standard allows to operate a WAF in monitoring only mode without blocking requests:

6.6 For public-facing web applications, ensure that either of the following methods is in place as follows:
[..]
– Is configured to either block web-based attacks, or generate an alert.

That was a very strange change in PCI DSS 3.0 and I assumed it was some sort of typo error. I decided to send an E-Mail to the PCI Council to get some clarification about this change. It took some time, but I finally got a response. To sum up: It is no typo error.

The PCI Security Standards Council Response Team’s answer:

The intent of Requirement 6.6 is to ensure web-facing applications are protected from known attacks. One of the options defined by the requirement is to install an automated technical solution (such as WAF) that “detects and prevents” web-based attacks. The solution used can encompass a combination of technology and process. Where the solution includes a reliance on process, there must be mechanisms to ensure that processes are followed in order to prevent attacks and meet the intent of the requirement. For example, if a WAF is configured to “monitor only” rather than “block” attacks, there must also be real-time alerting and response procedures in place to react to, and thus prevent, incoming attacks in a timely manner.

The requirement wording is intended to allow organizations flexibility to choose protection methods that best meet their needs. Whichever mechanisms are employed, the required result is that attacks are prevented, not just identified.

I do understand the need of a company to not have an enforcing WAF. It’s about False Positive and how to handle this problem. Everyone who operates an Intrusion Detection System knows it: False Positives are a pain in the ass and it is really hard to get rid of them, but this problem will not disturb the business. When dealing with a WAF in enforcing mode this is different. A False Positive WAF block will indeed block legitimate traffic and can possibly disturb business processes. It’s quite hard to prevent this.

So now you can indeed operate a WAF in monitoring-only mode without violating PCI DSS, when having a 24/7 response team that is able to react on a WAF alert very quickly.