KN: Good evening. Katarzyna Nawrocka: „On loyalty schemes at night”. In today’s episode of our programme, we’re tackling a very important and highly topical subject – cybersecurity. And today’s guest, Paweł Wałuszko, is an expert in this very field.
PW: Good evening. My name is Paweł Wałuszko. I am a graduate of the University of California, Berkeley, and Stanford University. I am currently working with TestArmy Cyberforces. I specialise in educating end users in the field of cybersecurity.
KN: Mr Pawel, we’ll be talking primarily about how to protect loyalty programme databases. So, as my first question, I’d like to ask you: what are the main types of attacks on IT systems, and how can we protect ourselves against them?
PW: The subject is actually very complex, because there are two types of attack for which we need to be prepared right from the start. The first type of attack is, for example, ransomware. These are attacks that attempt, for instance, to encrypt our data or disrupt our operational services. The second type of attack is a denial-of-service (DoS) attack. These are attacks in which, for example, hackers generate a massive volume of traffic directed at our IT systems, overloading them and causing so-called ‘downtime’ – in other words, a complete loss of functionality of those systems.
KN: You mentioned data breaches caused by ransomware. What happens to that data?
PW: I mean, traditionally, ransomware didn’t actually cause that many data breaches; it simply encrypted the data. Ransomware is a type of malware that usually finds its way into our IT systems through human error. It can arrive, for example, in the form of an unpaid invoice. A hacker sends us such an invoice. Of course, this invoice isn’t addressed to us, but someone will open it. We then receive a tiny file which begins to encrypt all the data on our computer without us noticing. Whilst it’s encrypting this data, we naturally won’t realise what’s happening. This ransomware encrypts every file and automatically spreads across network drives to encrypt and attack further systems, with the aim of forcing us to pay a ransom, usually specified in Bitcoin. As for the ransom, it can actually vary. The amount can be very small or very large, because the ransomware is programmed to recognise the environment it is in. So, if it is a corporate environment, or a production environment, the ransomware will certainly recognise this and increase the ransom amount. Up until around 2020, this was the traditional way ransomware operated, but not everyone is actually motivated enough to pay the ransom to the hackers. Let’s remember that these are cybercriminals, so paying the ransom does not guarantee that we will get our data back. So the hackers came up with a second idea: the moment this ransomware infiltrates our IT systems, it automatically contacts the hacker and sends copies of the data to them, so that the hacker can blackmail us with that data. And there are many ways in which we can be blackmailed. Firstly, if we do not pay the ransom to decrypt the data, the hacker may send us a message threatening, for example, to make all our confidential documents or the contents of our contracts public. Firstly, this could damage our company’s reputation and could result in customers simply losing trust in us. And, of course, let’s not forget about the GDPR, because if a data breach occurs, we are now legally obliged to inform the relevant authorities of this fact.
KN: First and foremost, we are obliged to protect data, as you mentioned the GDPR. But I wanted to move on smoothly to the next point, because we already know how vulnerable we are to this malicious, sophisticated virus encrypting our data – but is there any way we can protect ourselves against it?
PW: We can. But in reality, protecting ourselves against these viruses depends on a great many factors. Firstly, let’s consider the so-called human factor. According to all the statistics – if we look at the figures published by Canon in 2019, which are released annually – Roughly 52 to 59% of all data breaches are caused by the so-called human factor. What is the human factor? The human factor refers to configuration errors and simple mistakes that happen to everyone. We are not robots, so naturally we sometimes send an email to the wrong person. It also includes so-called ‘insiders’ – people who sometimes aren’t even aware that they’re interacting with a hacker who, for example, is using social engineering – a form of psychological manipulation – to try to contact them and gain their cooperation. Such collaboration might involve, for example, someone temporarily disabling their antivirus software. Someone might, for instance, open a file they shouldn’t have opened. They might accidentally share a password without even realising it, thinking they are carrying out their tasks correctly. So, in reality, this human factor is a major problem, and the only way, so to speak, to protect against such data breaches is through social engineering tests and audits of the company’s resilience to such attacks. And, of course, security awareness training. Please bear in mind that IT security systems cannot guarantee 100 per cent security. Even if we find a solution that claims to guarantee security 100%, believe me, that is not a realistic claim. In cybersecurity, there is no such thing as a 100 per cent guarantee of data retention or security. But we can certainly get closer to it. So if we train our staff – the people who work with us every day – and explain to them what cyber-attacks involve, what to look out for, what phishing looks like, and what methods are used to extract data from us, We immediately improve the effectiveness of these systems, in which we have already invested a great deal of money. The second aspect, of course, is various types of security audits. We’re also talking here about automated tests, manual tests, and services such as Rettim, where real hackers, of course with our consent and under appropriate contracts, actually attempt to break into these systems and try to bypass all the defences we have in place. With our permission, of course.
KN: Should data security be monitored continuously, and how should this be done? Is there a way to automate this?
PW: Monitoring data security is, in fact, in our own best interests. Let’s not forget that this is data for which we could face quite a hefty fine. If a data breach occurs – any kind, really – we must expect to face GDPR penalties. We could lose our customers’ trust, and we certainly do not want our own or our employees’ personal data to be floating around the internet, so this monitoring is absolutely essential. When it comes to monitoring, we can talk here about behavioural monitoring – that is, how employees behave and whether they might, even unwittingly, be collaborating with a hacker. Various systems are used for this, ranging from IPS to IDS. These are Intrusion Prevention Systems and Intrusion Detection Systems, which can alert us that something is amiss within our company; however, there are also more complex systems such as Siem. These are alert and monitoring systems, so they are capable of detecting that something is amiss and generating an alert – that is, informing the IT specialist that something is happening that shouldn’t be happening. Let me give you an example. For instance, a login at two o’clock in the morning – a valid login. What might such a login indicate? Firstly, it could mean that someone is simply working remotely, perhaps in a different time zone, so they’ve simply connected to our network and are now using it – which is perfectly normal behaviour. The second possibility is that someone is simply working from home; perhaps they’ve had three cups of coffee and can’t sleep at this hour, so at two in the morning, it’s perfectly possible that someone is still working. However, the third possibility is, unfortunately, that there may have been a password leak, so even if someone logs into our network correctly at two in the morning, we should take note of it in some way. And these Siem systems can, at this point – particularly as they’re equipped with artificial intelligence – make certain decisions. We’re talking here about alert systems. An alert is simply sending someone a notification – a message, which could be, for example, a text message, an email, or a ticket in a helpdesk system such as Gira – informing us that something has happened and the system has detected it. But let’s add to this the proactive aspect offered by artificial intelligence, which, for example, can make certain decisions. So if it detects an unusual login – even with the correct username and password, but at an unusual time – the artificial intelligence might, as a precaution, block that account, for example. Of course, this may result in us actually disrupting someone’s work, but from a cybersecurity perspective, it is better to interrupt such an employee whilst they are working and simply speak to them a few hours later, rather than simply leaving such a loophole in our systems, only for it to later transpire that a password leak has indeed occurred and that a hacker may well have been using our systems for several hours, doing whatever they pleased with them.
KN: But what if we don’t want to invest in artificial intelligence?
PW: That’s a very pertinent question, because artificial intelligence – and AI-based solutions – are still quite expensive, and let’s be honest – not everyone can afford them. But I recently gave a lecture on how to create your own SIEM system – not necessarily based on artificial intelligence, but on certain principles. So, as I was saying, SIEM systems have this alerting component, but various monitoring systems, such as NMS – Network Monitoring Software – the moment they spot something, or Lock Parcere – that is, those solutions which read the logs to see what’s happening on our servers and computers – they’ll spot something unusual. They often have the option to notify us. So a script can be, to put it colloquially, triggered. There’s nothing stopping us from integrating these alerting systems, for example, with our own custom script written in Bash or PowerShell, which, for instance, will lock an account if it detects a specific type of behaviour. So here it really depends on the administrator. How much effort the administrator is willing to put into defining such rules and policies, defining what constitutes normal behaviour and what does not. Let me give another example. Let’s say we have several logins and several attempts to log in to a single system at the same time. Let’s say, for example, that someone entered an incorrect username and password three times within a minute. What does this mean? It could simply mean that someone’s finger slipped on the keyboard – it often happens to me – and I then simply get a „login failed” message, meaning I couldn’t log in. But, for example, if we see three login attempts within a single second – I don’t believe anyone can type that fast – so we’re probably already dealing with scripted behaviour here. So, as administrators, we can actually define what we consider to be normal behaviour and what we consider to be automated behaviour. We can then configure these monitoring and alert systems so that if they detect this discrepancy – for example, if we notice three logins within a single second – it’s likely a bot. This is unnatural behaviour. In that case, we block the account. The same applies to the example of a valid login at two o’clock in the morning. If remote working takes place at that time in our organisation – it is perfectly normal, whereas in other companies which, for example, operate daily from 9 am to 5 pm and know they have no users connecting from home via VPN, or working in a different time zone at all. It’s clear that even a valid login after 5 pm could indicate something amiss. So these scripts can be configured so that, rather than simply alerting us – by sending us an email or a text message – they immediately block such accounts. However, this again requires a certain amount of work on the part of the administrator to set up such a monitoring and alert system in-house.
KN: Mr Pawel, what security aspects should we bear in mind when planning loyalty schemes?
PW: As far as loyalty schemes are concerned, please bear in mind that, by their very nature, these schemes process a very large amount of sensitive data. We do not know exactly where these points – to put it colloquially – are actually credited, or at what point these transactions take place, so it may turn out that these loyalty programmes are, for example, completed via a form on a website. That is one security issue, but let’s say, for example, that we can also redeem some points at a payment terminal. These involve completely different levels of security, so there are a few things we need to consider. Firstly, what type of software shall we choose? Because not all software can be easily integrated. Will this data exchange be sent via an API, or will it be implemented in some other way? That is one thing; another is whether the necessary integration or compatibility with our existing systems is already in place. Secondly, we must bear in mind that some software may not meet certain security requirements. If we install software, for example, on a computer – that is, on a POS (Point of Sale) terminal, i.e. the devices where sales actually take place – such as cash registers. This is software that should meet certain requirements. For example, in the United States, the PC ITSS standard applies, meaning that any software installed on such a device must meet specific data security requirements relating to credit card data – so this is a completely different level of security. When choosing the right software, we must first and foremost pay attention to security – not only of the data being transmitted, but also how that data is archived. We should look at the policy – in the sense that, God forbid, if a data breach were to occur, who would be held responsible. Do we receive any guarantees that this data is stored and processed correctly? And, of course, there is the issue of compatibility, which I mentioned earlier. Every company has its own systems, so we must consider how these systems will, first and foremost, securely exchange this data.
KN: Mr Pawel, what exactly are penetration tests?
PW: Penetration testing is, in essence, a permitted attack on the infrastructure. So it starts with the client simply choosing a company to test their software or solution. An NDA is always signed in advance, along with a number of other agreements. We set out the terms and conditions under which we will carry out the test. And this is how it works. Firstly, there are automated tests, where we check for things such as exploits and known vulnerabilities. We also try to assess the software’s stability and security. We check for any configuration flaws and whether the programme has been properly designed and built from the ground up. We check whether it is possible to automatically bypass the security measures the programme already has in place. This is generally known as ‘Yap Box Testing’, which is a test where we already possess some knowledge from the manufacturer about the solution. There is also something known as Black Box Testing, in which we actually engage certified hackers who attempt to breach these systems from a hacker’s perspective. Because it’s one thing to scan these systems and automatically check whether they’re vulnerable to any kind of exploit – that is, scripts which, so to speak, find a way round these security measures. It’s a completely different matter to look at it through the lens of a hacker, who draws on their knowledge, experience and, quite often, abstract thinking to try to break into these systems and see how far they can go. As I mentioned, these penetration tests naturally take place with the manufacturer’s consent and are very specific, as we do not want to cause any damage; we simply want to see how vulnerable a given product is to an external attack.
KN: They are a sort of simulation designed to teach us how to act in a way that makes us feel safe.
PW: In fact, this should lead to some recommendations as to how this hacker actually gained access to the system and what we can do, for example, to secure it.
KN: Does implementing a penetration test mean we’ll be secure forever?
PW: Not exactly. Please bear in mind that carrying out any audit or test essentially certifies that, at that particular moment, the software is reasonably secure. But that’s not really the end of the story, as I’ll illustrate using the example of a car. We buy a car, don’t we? And when we take delivery of that car, the manufacturer guarantees that, more or less, it will work. Because that car is made up of many components manufactured by many different manufacturers, isn’t it? One manufacturer supplies the clutch, another some small screws and other components. It should all work perfectly. When such a car is manufactured, the manufacturer checks that everything is working, and if so, it simply passes through quality assurance – that is, the quality test. The car is then sold. But what might actually happen in practice, down the line? It may turn out that one of these components is faulty. The same thing happens with software. Software is actually built from various libraries. Let me give the example of OpenSSL. This was an encryption library used by a great many companies for many years. What happened? Despite the fact that it was considered very secure software, someone nevertheless found a vulnerability. And exploited that library. So, even if a software developer had created a programme using that library and it had successfully passed a penetration test, and it appeared it was secure, this does not at all mean that, a year later, one of the libraries used to create that programme won’t turn out to have been full of holes, faulty, and with its security measures easily bypassed. So, well-secured software is tested repeatedly. The developer should undergo regular audits and security tests to ensure that nothing has actually changed. All the components used to create the software are still considered secure, and it is not possible to ‘break’ the software, so to speak, in an automated manner. And this is the number one method hackers use to try and find vulnerabilities: automated testing. Only when these automated tests fail to find any vulnerabilities do hackers actually attempt to breach the security systems using manual methods.
KN: Mr Pawel, what role do ISO standards play in a safety management system?
PW: There is something called ISO 27001, which is essentially a standard certification that confirms that the manufacturer has, first and foremost, raised its employees’ awareness of cybersecurity, the various types of attacks they may face, and the need to alert the relevant people in the event of a data breach. It confirms that the manufacturer has established appropriate data protection and security policies, and that it also updates all systems to the latest configurations and versions in accordance with a specific policy. So it simply guarantees that the software produced by a given manufacturer is developed in a more secure environment than, for example, its equivalent.
KN: As we’re coming to the end of our conversation, I’d like to return briefly to your professional work and ask: what does TestArmy do?
PW: TestArmy is, in fact, probably the largest testing company in Poland. We have our own laboratory in Wrocław. We actually test a wide range of things, from stability to WCAG, right through to quality assurance. We specialise in automated, penetration and social engineering testing. We also run training courses for VIPs and on cybersecurity. So, in essence, we are a one-stop shop – a place that can test not only software functionality but also all aspects of software security. We also have over 10 years’ experience in the Polish market. We serve clients ranging from small businesses to truly large corporations, and we train a very large number of testers.
KN: So how do you become a tester like that?
PW: I mean, apart from formal education, you can also have a look at our website, testuj.pl, which offers a huge range of training courses for beginner testers. We’re always open to working with any qualified individual. Of course, you can start with basic certifications and work your way up to, for example, CEH (Certified Ethical Hacker) certifications – we also employ people with these qualifications. And here, a good place to start, alongside formal education, is always to aim for the relevant certifications.
KN: Mr Pawel, thank you very much for being my guest today and for sharing your invaluable knowledge with us.
PW: Thank you very much.
KN: I hope to see you there.
PW: See you later.
KN: And we look forward to seeing you for the next episode.
