IXON Security Assessment and Pentesting outcome
With regard to security, IXON has a major responsibility. Customer data and machines must always be properly secured. In order to get a good picture of the current level of security, IXON had a pentest carried out by a specialised cyber security company in August. In this interview we discuss the results and recommendations with IXON's Security Officer, Dylan Eikelenboom.
Hi Dylan, can you tell us a bit more about pentesting?
Sure! Pentesting is derived from 'penetration testing'. Basically, a pentest is simply an approved hacking attempt by a cybersecurity company hired for that purpose. These organisations employ a number of ethical hackers who, after approval by the client, in this case IXON, attempt to attack a company's infrastructure in the same way malicious hackers would do. So, with our approval, the pentesters were allowed to try to hack the IXON Cloud portal and the IXON router. One way or another.
Has IXON ever performed a pentest before?
Yes, it's actually the second time we've had Access42 run a pentest. The first one was last year. By having a regular pentest, we want to structurally improve on our security level.
The pentesters were allowed to try to hack the IXON Cloud portal and the IXON router. One way or another.
Are all pentests the same or are there any differences?
There are many different ways to conduct a penetration test. The difference lies mainly in the amount of information you give to the pentesters beforehand. You could give them nothing at all and say "this is our cloud portal, go ahead". They then actually start exactly as a malicious hacker would start: First they map the infrastructure, such as servers, IP addresses, services, etc., and then dig deeper and deeper, looking for vulnerabilities.
Then you have certain gradations where you give only specific data, such as log-in details. In the most transparent case, you can give them direct access to the complete source code of all software, so they can see everything in detail.
Depending on the type and amount of information given to the penetration testers, the pentesting scene usually distinguishes between Black Box (no information), White or Crystal Box (full disclosure) and Grey Box (all intermediate forms).
What type of pentest had IXON carried out?
Our test was really a Grey Box. We gave the pentesters a presentation in advance in which, among other things, the infrastructure was extensively discussed. Before they started, they already knew exactly which servers are in use, which kind of services run on it and how everything is intertwined.
We also gave them a number of routers, including the complete source code. So for that part you can really speak of a Crystal Box.
How much time has been set aside for the pentest?
At Access42, two ethical hackers each spent 40 hours on it.
Could you tell us a little more about how the pentest was done?
It basically started with an exploratory phase, in which the pentesters gathered information. They wanted to know things like: What are our assets? What does the IXON Cloud look like? What is our actual product offering? And more questions like that.
Of course, our infrastructure was mostly similar to last year's situation, but because there were some new people at Access42, we covered the complete infrastructure extensively in a presentation. First we discussed IXON, then our cloud portal and finally the IXrouter.
The overall security level of IXON's IIoT platform was found to be high.
Access42 used an automated vulnerability testing system to get a quick impression and check for attack vectors. They added all the IP addresses of our servers, and subsequently ran an initial rough, global scan. This gave them an idea of what was running on which server, which ports were open, which software packages and versions were running on them, etc. This way, pentesters try to figure out whether they can already identify certain elements that hackers can use to exploit a system in an easily accessible way. Next, they dig deeper and deeper into it. Finally, they write down their observations in a report in which they also make recommendations to improve the situation.
It was not possible to successfully penetrate any of the services required within the available time for this assignment.
What was the final assessment of the safety of IXON's product range?
Access42 summed up the results of the pentest in a report which they discussed with us. In the management summary, they concluded that the IXON Cloud platform is of quite a high security level. Had they been given more time, the conclusion would have been stronger. Nonetheless, I'm very satisfied with the result.
We understand that this is sensitive information, but can you tell us anything about the outcome of the pentest itself? Have any vulnerabilities come to light?
Yes, they definitely found something. And that, of course, is why we are doing it. We don't have a pentest carried out, just to show our customers a nice certificate and tell them that we are 100% secure. In a perfect world there might be something like 100% security, but in the real world it doesn't work that way. It's a perpetual battle between attackers and defenders.
Access42 reported 8 findings. For each of these findings, they indicated the severity. In our case there were two Medium issues, four had criterium Low and two were Informational. No serious issues came to light for which we had to intervene immediately.
In this penetration test, no findings have been made that have been classified as high or critical severity.
Could you tell us something about the background of the vulnerabilities that have come to light?
The impact of all security issues is very limited, even the medium issues. The chance that they would actually result in an incident is very small. The impact on customers is also very limited. For example, these vulnerabilities did not allow access to customer or machine data.
How is IXON dealing with these vulnerabilities?
All findings have been discussed with and reported to R&D. Internally, we then qualify the vulnerabilities using our own system, one that's often used by development teams. This starts with 'negligible', i.e. issues that have a very low impact. The chance of these being exploited is virtually negligible. We fix these when there's nothing left to do.
Then you have issues that have a 'low' impact. These vulnerabilities can be exploited, but the nature of the exposed information is only slightly confidential or in order to abuse this vulnerability, you must already have exploited another vulnerability. This type of vulnerability is also put on the backlog and addressed when a developer starts working on that part of the code.
Medium issues are more important and need to be addressed within three months. Of course, this will depend on the technical difficulty of identifying a proper solution. Some vulnerabilities can be solved with just one line of code – those are fixed right away. For other vulnerabilities, a whole chunk of code needs to be revised. Obviously, this will take considerably more time.
Finally, there are issues that are classified as 'severe' or 'critical'. When we run into these kinds of issues, all the work is put aside until the issues are resolved. The R&D team will immediately start looking for ways to resolve the vulnerability. In the meantime possible threats are mitigated as much as possible.
What follow-up actions will be taken in response to this pentest?
I always make sure that R&D gives the right priorities to solving these vulnerabilities, so that they will actually be solved in the end. My commitment is that all issues will be fixed before the end of 2020. To monitor progress, I have a monthly meeting with the product team to discuss this.
It was not possible to exploit any of the findings predetermined from the initial scans to access any confidential systems or information.
Have you also looked at older software versions?
The testers only looked at combinations of the latest version of the router firmware and VPN client. So they didn’t look at older versions. We know that some older firmware versions have small issues, because they are not quite in line with the latest industry standard. But there are also no known exploits. Yet, this is definitely something we always take into account internally.
We know that the software of routers in the field doesn’t necessarily have to be up to date, because manufacturers decide for themselves when they perform router updates. So we don't have that part entirely under our own control. We are dependent on machine builders, system integrators and, of course, the end customer. So I can't guarantee that it's 100% secure if you use an older version. At least, it won't be as safe as the latest version.
When is the next pentest planned?
We haven't pinpointed an exact date yet. Next time, I'm in favor of taking more time for the next penetration test and giving the pentesters more initial information.
We are also looking into doing something with a bug bounty program, such as HackerOne. But maybe it's a little too early for that, because you have less control. For the Access42 pentesters, we gave a whole list of information in advance. Besides "this is it" and "this is how it works", we also indicated which servers don't need to be included because they are about to be phased out. With a normal pentest it’s also easier to give extra focus, such as: "We would like it if you could also take a look at these security questions." "Did we set this up properly?" Et cetera.
You can do that with a pentesting agency, but not with a bug bounty program. By making the information public, you could make it a lot easier for the ill-intentioned.
What lesson can IXON learn from this penetration test?
One of the most important lessons you can learn from penetration testing is the myth that you have all knowledge in-house and that you have everything figured out.
For example, in this pentest some issues have been found that I could have thought of myself and that we actually had a good look at in the past. But because they have been re-examined and are being looked at with a fresh pair of eyes, things still have come to light.
Pentesters look at things with a different perspective and have a lot of practical experience. Because of this, things that seem simple at first sight suddenly turn out to be less simple. With pentesting you get an impartial, unbiased view of your process and services.
Is IXON often under attack by hackers?
Yes, we are on a daily basis. Especially untargeted attacks. For example, we often see bots pass by that automatically try to exploit certain vulnerabilities in commonly used software, like Wordpress or SSH. We haven't seen any targeted attacks yet.
What is the worst-case scenario that keeps you awake at night?
The worst-case scenario would really be the customer database becoming public. Downtime due to a malfunction or DDoS is of course inconvenient or annoying for clients, but often still surmountable and has a temporary character. Customers can often understand this, because you have less control over it yourself. I would rather have the source code of our applications become public than client data.
Is there anything that hasn't been discussed you would like to share?
Sometimes I come across customers who ask: "Can you 100% guarantee that your database can't be hacked?". When I tell them that we can't guarantee that, they respond surprised with "but that competitor can", because the marketer or sales representative of such an organization says so.
But we simply can't guarantee 100% security. In any piece of software that is considered 100% secure today, a vulnerability can be discovered tomorrow. It just takes time to resolve it. As long as that hasn't happened, you are more or less vulnerable. IT departments understand that, but managers and purchasers in organizations find that message hard to swallow.
It's simply not possible to guarantee 100% security.
At least, you can do your best to make the attack vectors and surface areas as small as possible, so that the chances of something happening and its impact are as small as possible. In the end, the only thing that IXON can guarantee is that we do everything in our power to design the processes around our products in such a way that we try to prevent vulnerabilities as much as possible and resolve issues as quickly as possible. But in practice it remains a game where you try to use the latest defense techniques, while hackers try to use the latest attack techniques to get through it.