Prof. Dr. Hartmut Pohl - Security as a Service: The New Normal?

Welcome to this final day of the EIC conference, which starts with a, a keynote from Dr. Professor Dr. He poll and, and Mr. Klein from Soft's check, who are going to talk about the continuing problem and how to solve it, the continuing problem of software vulnerabilities. Thank you very much over to you gentlemen. Thank you very much, Mr. Small. My name is Harwood pool from the university of applied sciences in one line Z cologne. I'm the CEO of soft Trek. It's an it consulting yeah, security testing company.

And I will tell some aspects about security as a service, especially software security. You all know the, I think indispensable security matters.

I saw 27,000 with excess control with anti V horse with firewalls, web application, firewalls, and so on with encryption. That's a normal way to secure your systems, but nobody is asking the question about the quality of these security measures. All the people are doing security, but I ask the question. Did you ever test your firewall? Did you functional test of your firewall or functional test of all the features of encryption? Maybe some of you will do that, but who tested the security level of these functions of all these functions? That's very seldom.

And I think this is a good point for company, a good point to outsource these security tests while security as a service, you are okay, you need, so you do not need so much experts. You do not do not need expertise with your employees. The costs may be lower. You can get higher security, but there's on the other side, you should trust the company with which you are working. That's an important thing, the trust, and you may know how to measure the trust to the third party. Okay? Many outsourcing companies are using a cloud.

I think a cloud is very unsecure or again, the question did you tested the functionality of a cloud? And the second question, the most important question is did you tested the security quality of the cloud you are using? And the security services, which are in which are using clouds may be secure, but the cloud itself is very unsecure. Okay? This was the first point. The second point is we are all discussing ethics every day. Thousands of new viruses, every day, new ethics, you know, St. Net it's St. Net is eight years old already. There are many followers of the, of this warm St. Net.

All people are discussing ethics. Some people are discussing security measures against for example, St.

Net, but there are no classical security measures. Nobody is thinking about the vulnerabilities. And I think that's the most important question. That's a tax net here with all the followers here. The followers written down about 10 or 12, which are in the world. This is important slide. Here are some ethics on the left side, you have ethics, exploiting vulnerabilities, but the vulnerabilities are pitched and ethics cannot be successful because each to be successful needs vulnerability.

The vulnerability is patched to, as these vulnerabilities are patched, therefore, all these ethics, again, exploiting the vulnerabilities are not definitely not successful on the right side. You have ethics and pass using open port of a firewall or so, and exploiting vulnerability, not patched or not published. Very new one zero day vulnerabilities. These ethics goes through all security measures, using unpatched vulnerabilities or very new vulnerabilities, zero vulnerabilities. As they goes through all the security measures to the encryption, to the keys, to your assets, to your data.

Then the importance thing is to close vulnerabilities. If you close vulnerabilities, the software is real. Your system is really secure and no attack is successful. If you close these, you are in this situation. And then the system is really, really secure. So the question is how to identify all the vulnerabilities, especially the new one, the zero day vulnerabilities. The security testing poses is as follows. You have discussion about the security requirements. You have a scratch modeling, discussing arch architecture, the, the eye architecture of a system you have.

I will explain that you have static source codes, code review. You have classical penetration testing. Sure. And you have a force method fuzzing. If you do all these for method, you really get all the vulnerabilities. You will identify all the especially and new one vulnerabilities.

First, the scrap modeling start modeling is all these method are simple. We have here data flows, for example, the user to web service. And the user is sending data for log in. Procedure buys this data flow and you first have to list all the data flows in the system.

Yeah, here's this, the second is you have to list security requirements on each data flow. This is here, maybe confidentiality. Yeah. And the third part third is to identify the security measures, which support this requirement. Confidentiality. If the security measure is there. Okay. If it is not there, if there is no security measure for the confidentiality, for example, encryption, then there's a vulnerability three steps to get the vulnerability of the whole system. Okay. So it has a list. We have to list data flows, requirements and security measures.

It's a little bit time consuming, but no, you need not much intelligence. Okay. Aesthetic source code, code reading.

I think, you know, all, I will explain fuzzing. You have a target system, for example, a firewall or encryption system or web application firewall. And you have a program which feeds this target system with input data, not random data, but data from experience, which are at taking system. Huh? Okay. And then you look at the target system. What is it doing if it is okay, then there's nothing. If it crashes or it's, or it condu consumes much processor, power or storage, then the expert has to look at the system at which point of the code was that.

And he looks at it and maybe that he sees buffer overflow or such possibility such for vulnerability. Okay. That's all. And then you are looking for more, you, you identify one and the next one and so on. Very simple. So that's the whole, whole process. We are looking to the code coverage, how much code we analyzed.

We are, can do it on every operating system. You can do it on each processor and so on. And we use a monitor looking at the target systems. And it's more simple for the expert to see the point where the court is not okay. Okay. We will look at the achievements of these methods with scrap modeling that's that are figures from the last 10 projects with scrap modeling, we identified one, 100 about 100, very new vulnerabilities, zero day vulnerabilities.

This, this are only zero day vulnerabilities. Yeah. With static source corn 17. Okay. But we should think about the XTE needs only one vulnerability to exploit a system. Yeah. It's not the question how many we identified, but we are in the situation to want to identify all vulnerabilities, especially the zero day vulnerabilities with penetration testing, nothing new. And with fuzzing about 27 around all per project, we identified 150 about such number, very new vulnerabilities. Okay. We will show you this. Mr. KLE will show you this on the example of web application firewall. Yes.

Thank you, professor Paul. I think we are short in times will skip some details. I think most of you will know what the web application firewall is. Web application firewall filters, HTTP requests for malicious code. So I will go on with our demonstration In our today's life demonstration, we will show how a whole system may, may get vulnerable by a vulnerability in security software. We have an Apache web server on this host. That's running in a virtual machine and on Apache web server, we hosted this test site. It's a web application where you can do injections, cross site scripting.

And so on. I can show you an example. If I want to go, want to make an injection, I can do a typical test here, for example, or one equals one. So typical test for ESCR injection. And if I'm sending this, this link with the parameter or one equals one, I get forbidden here. In this case, we have a web application firewall. It's an open source, firewall, not security it's well known. And this firewall is plucked into the Apache server, gets our HTTP request and we gather forbidden. So the request is blocked.

The problem with this is that we also have a vulnerability in this web application firewall. I can show this here, here. We have account of the Apache processes, which is 13 at the moment. And we have a web application, penetration testing tool called BEB suite. This is this window. We have our target IP. That's C IP of the Apache web server here. And we craft a HTTP request with BEB suite and send it to the web server. This is a ordinary HTTP request and embedded in this request. We have some lines of XM L code. And in this XM L code, we've defined an entity.

This entity refers to deaf random, which is a random number generator and Munich systems. That means if you call deaf random, you get back a random number. And the generation of this random number depends on keyboard, inputs, mouse, inputs, and so on. And like most of you will know in front of a server, there's no one sitting using the keyboard or using the mouse or something else. And so this call of the entity will never get back any random numbers. So when we start this attack and we craft HTTP requests and send them to the Apache web server, the process count of Apache will increase.

I start the attack and you will see this it'll raise very fast. We have about hundred processes at the moment, and now we are at hundred 51.

And this, this was the number I was waiting for because standard configuration of Apache only allows 150 parallel processes of Apache. And at this moment, The Apache server isn't reachable anymore. If we try to open up the web application again, you'll see Chrome is working, but there won't come any response from the web server. So the web server is unreachable at the moment and you can use this for denial of service attack. And if I restart the Apache process, I have to stop the attack first, or the process count will raise again. If I restart the Petri process, where's a little script here.

The process count is in a normal stage and the website is reachable. Again. What we wanted to show is that the well-engineered and over years, Corona system like Apache, which seems to be very safe, may become insecure by adding a security feature, like the mod security web application firewall. So also security software has to be security tested professor. Paul will go on.

Yeah, thank you very much. That was board security. In contrary, we analyzed web application firewall with, which is now very secure because we identified, as we say, by experience all vulnerabilities, that's at airlock From the company argon. Okay. What we wanted to show is security as a service, it's a new normal, I think, yes it is. You otherwise you need personally, you need specialized me specialized methods. Like we showed these four methods, threat modeling, aesthetic source, cor penetration testing, and a specially fuzzing. You need experienced special, which stay experienced. Yeah.

And you need the up to date tool selections of about 300 tools, which are in the world to security test systems all over these. It is massive coast cutting to use a secure, to use a service for your security. Thank you very much. I want to invite you to our booth where we can explain these four methods in detail. Thank you. Thank you. Thank you very much, professor Dr.

Cole, and it's very frightening to see the demonstration of as, as you put it a mature system being compromised by adding a security. So thank you very much for that insight. Thank you so forth.