Why penetration tests at ISO27001 audits?

Leave a Comment

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

Leave a Comment

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

Leave a Comment

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.

“Digital Forensics” lecture in study course of Business Information Technology

Leave a Comment

The recent hacker attack on the University of Gießen has made many people aware that the threat posed by attackers from the Internet is continuously growing. In order to to learn from such security incidents, IT forensic scientists are required to investigate the 7 W questions of criminalistics: Who (perpetrator), What (crime), When (time of crime), Where (crime scene), how (sequence of events) and Which (Tools) and Why (motive). They use the digital traces left by the attacker to reconstruct the security incident and – ideally – to convict the perpetrator.

Through university contacts in the winter semester 19/20, I had the opportunity to offer the module “Digital Forensics” in the master’s program Business Information Technology at the Technical University of Middle Hesse (THM). As a pentester from the attacker’s perspective, I am already avoiding traces left behind during an attack and how they can be concealed. So the following topics were on the agenda for me:

  1. Hacking
  2. Anti forensics
  3. Reports
  4. Live forensics
  5. Disk analysis
  6. Application forensics
  7. Creation of malware
  8. Malware analysis
  9. Reverse Engineering

Following Sunzi’s quote – “You have to know your enemy to be able to defeat him” – I changed the perspective between the two opponents depending on the lecture unit and had the content discussed in the following scenario applied by the students:

Dubius Payment Ltd. is a recently established payment service provider that stores, processes and forwards credit card information. Since November 14, 2019 at 4:45 p.m. (Thursday), the production system has been experiencing breakdowns and its intrusion detection system has regularly reported unusually high network traffic by its payment gateway. Fearing a hacker attack, they asked the students as IT forensic experts to analyze the case.

In their practical work, collecting and analyzing digital traces on the live system, students found that an employee of the company tapped credit card data from the database at regular intervals. Just as like in reality, the students had to verify this conclusion and answer the question of whether the user had been the victim of a hacker attack himself or was actually responsible for the theft of the data via a subsequent data medium analysis of the suspect’s work computer. They compiled their results in the form of an expert report.

Of course, not everything went smoothly at the beginning. For example, I had to struggle with the construction of my planned laboratory: My goal was that the students would learn to use their own toolkit on a compromised system. So I replaced the Linux program “/usr/bin/ls” with the following “malicious code” on the live system:

#include <iostream>

#include <cstdlib>

using namespace std;

int main() {

cout << "I've got ya! ;)" << endl;

system("sleep 1");

system("sudo reboot");

return 0;

}

However, since “ls” is also used by init scripts, the malware led to an endless loop in the event of a restart. The use of an alias in Linux provided a better solution here. The students response to the course was great:

“It is the most exciting module in the entire master course. It is captivating and lots of fun”

Student

The previous comment contributed to my goal designing for a new online course for the binsec academy: The “Digital Forensics Training”, in which participants will certify as Binsec Academy Certified Digital Forensic Professional (BACDFP) in the future.

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

Leave a Comment

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.

PCI DSS 3.0 – Requirement 6.6 (WAF): Monitoring Only – “Is configured to either block web-based attacks, or generate an alert.”

Leave a Comment

Today I was working on a presentation about PCI DSS 3.0. Since a major client of me is an international payment service provider doing credit card transaction, I am quite familiar with PCI DSS 2.0. I have already read the new Standard a few months ago, but today I stumbled about an interesting sentence in the Testing Procedure for PCI Requirement 6.6 (WAF) that makes me wonder about PCI DSS 3.0.

PCI DSS Requirement 6.6 forces companies to either use a Web Application Firewall (or some technical equivalent) or forces companies to perform manual or automated application vulnerability security assessments after every change:

6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
[..]
– Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.

Doing automated application vulnerability security assessment is a little bit tricky and needs a software development team and process on a high maturity level. I assume that most companies comply with Requirement 6.6 by using a Web Application Firewall (WAF). Companies can write their own rule sets for a WAF, use a rule set from the WAF’s vendor or use some rule set from OWASP (OWASP CRS Core Rule Set). Anyway it is useful to activate the blocking / enforcing mode of the WAF to actually prevent attacks. That is industry best practice and is or better maybe was required by PCI DSS when companies deployed a WAF to comply with Requirement 6.6

Despite a lot other changes there is a new sentence in the Testing Procedure of PCI Requirement 6.6, which seems a little awkward. Pay attention to the last sentence:

6.6 For public-facing web applications, ensure that either of the following methods is in place as follows:
[..]
Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:
– Is situated in front of public-facing web applications to detect and prevent web-based attacks.
– Is actively running and up to date as applicable.
– Is generating audit logs.
– Is configured to either block web-based attacks, or generate an alert.

So, I want to repeat it: WAF “Is configured to either block web-based attacks, or generate an alert.” Sorry, but what the fuck? After years of PCI DSS now it is okay to deploy a WAF in monitoring mode. At least it needs to generate alerts…

If found two links on the web, which also states this as a problem. Someone in a high position at Gartner[1] and some slides about PCI 3.0[2]. I tried to clarify this with our QSA Company, but just did a short answer, that a WAF needs to block attacks and no comment to this last sentence in Testing Procedure of 6.6. I decided to write an E-Mail to the PCI DSS Council and hope to get an answer that explains it. I will post the answer, if and once I get one.

For the security of customers’ credit card information I really hope this is some sort of mistake or typing error. Anyway I assume there will be some QSAs out in the world, which will accept a WAF in monitoring mode – It doesn’t matter if it was an error, if PCI DSS is treated like a law text and not correctly interpreted. And if this is no error and done on purpose, I wouldn’t really understand that change of mind in the PCI Council.

[1] http://blogs.gartner.com/anton-chuvakin/2013/11/08/briefly-on-pci-dss-3-0/
[2] https://www.netspi.com/blog/entryid/207/things-not-to-overlook-in-the-new-pci-dss-3-0

10/30/2014: The Council’s response.

The little HOB-Brandstätter shitstorm against OpenSSL/Open Source

Leave a Comment

I usually write my blog posts in German. Due to the great effort of Mr. Klaus Brandstätter (HOB’s CEO) I decided to write a post in English. As you may have already read in the Wall Street Journal or online (http://www.hobsoft.com/news/news220414.jsp) Mr. Brandstätter is advertising his company’s products by fighting a very old war against Open Source Software.

Mr. Brandstätter put his very bad example of an advertisement in various major German newspapers, too. After launching his little shitstorm against Open Source and OpenSSL he is already getting a very bad response in the German Open Source Community. Last month only few people knew HOB or Brandstätter, now he is getting famous in way he may not want to.

We all know that Heartbleed was a very bad bug and that there were some mistakes made. But this is no reason to personally attack the developers of OpenSSL and to claim that Open Source is written by unqualified people who aren’t adults. While big companies are starting financial support for OpenSSL and other critical products, HOB is attacking OpenSSL, Open Source and its developer.

We learned so far: Klaus Brandstätter dislikes Open Source very much. But instead of using commercial products for his website, the URL https://www.hobsoft.com is powered by Open Source.

Apache/2.0.52 (Unix) mod_ssl/2.0.52 OpenSSL/0.9.7k mod_jk/1.2.6 PHP/5.2.0 Server at www.hobsoft.com Port 443

You may ask, why aren’t they using their own HOB SSL? Don’t know. Maybe OpenSSL is still much more secure than HOB SSL? Or HOB SSL is too expensive and OpenSSL is free?

And by the way, do not get confused about this stuff that Heartbleed can be used in a denial of service attack. Neither is that true under realistic circumstances nor is it the real problem of Heartbleed. But keep in mind: Someone who is turning 60 this year, learned how to program in high school, wrote a million lines of code and understands Heartbleed has to be right. ;-)