Matthias Attard
May 21, 2024
Matthias Attard
May 21, 2024
We'd like to take this opportunity to thank all of you who attended The Cybersecurity Imperative conference. Throughout the event we received a good number of insightful questions and we're pleased to be able to provide you with the detailed answers below!
Q. A recently the court sentence found that a customer that fell for a fraud attack had the company impersonated responsable as well. Please elaborate.
A. While I cannot answer without the details and specifics of the case in point, in cases of online fraud, courts sometimes find both the deceived customer and the impersonated company responsible.
Q. How to start a career in your unit?
A. To join the Online Fraud Office, candidates must be sworn police officers and apply for vacancies as they arise. The Malta Police issue calls for applications based on need. While having a special interest, relevant education, and experience are advantageous, they are not mandatory. Individuals without these qualifications can still apply and will be considered through an interview process.
Q. Hi, I would love to hear more details about investigating ransomware attacks
A. These cases are considered cyber-dependent crime and such investigations are conducted by the Cyber-Crime Unit at the Police General Headquarters. My focus is on financial crime and cyber-enabled crime, where technology is used to deceive victims, resulting in financial losses to individuals or organisations. In the cases I handle, victims are deceived and subsequently, they voluntarily transfer funds to the perpetrators.
Q. What are the top 3 typologies related to business that are reported specifically in Malta and what is your practical advice from experience to mitigate them?
A. 1. BEC (Business Email Compromise)
2. Invoice Fraud
3. Investment Fraud
Practical advice: 1. Continuous education and awareness; 2. Strengthen internal controls; 3. Collaboration with authorities
Q. How many cyber crimes were solved/tracked ?
A. This question needs to be more specific for various reasons. The most powerful tool to combat online fraud is the prevention and the security measures. Currently there are yet undecided court cases which are available in the public domain and in the media. However, one needs to consider the issue of technical complexity, foreign jurisdictions, anonymity and lack of evidence, unreported cases, and legal and regulatory gaps. It is worth noting that global trends indicate a rise in cybercrime incidents, with many law enforcement agencies improving their capabilities to address these challenges.
Q. How come with all the AML enforced on Banks they are not able to recover funds from their accounts or at least arrest the scammer who has access to their acc?
A. It is common for scammers to operate from abroad, placing them in foreign jurisdictions and complicating enforcement efforts. However, in Malta, we are encountering a high number of money mules who, either knowingly or not, transfer, accept, and withdraw funds obtained from victims. This method is typically used by scammers to bypass bank security measures and obscure the money trail.
Q. Are there any increases in crypto related scams?
A. Yes, there has been a noticeable increase in crypto-related scams, both globally and in Malta.
Q. In case of a security breach, we are instructed to contact the Cybercrime office. Should we update our procedures to contact the Online Fraud office?
A. There is no need as such, as the Cyber Crime unit would inform this office accordingly and it does depend on the case in question. If in this instance there is financial loss, for sure this office would be communicated. Thus, if the victim should feel the need to speak with the Online Fraud Office, we would be happy to assist.
Q. To Malta police: From the amount of cases which are received and investigated, how much of the amounts lost are retrieved? Maybe a percentage?
A. Unfortunately the percentage of retrieved funds is low compared with the total of funds being lost. However, this fact is attributed to two main issues:
1. Difficulty in tracing funds - Online fraudsters employ intricate techniques to hide stolen funds, complicating efforts by authorities and banks to trace and reclaim them. Money is passed and quickly transferred through multiple accounts in different jurisdictions.
2. Jurisdictional challenges - Cross-border online fraud complicates recovery due to jurisdictional hurdles, legal disparities, and lack of international cooperation among law enforcement agencies.
Q. Would DORA apply if a company does not have any virtual cards or physical cards and transfers are on an EMI application which only allows internal transfers?
A. As far as I know, DORA also applies for Electronic Money Institutions. The regulation allows for Proportionality in Art.4, so even if you are a licensed Electronic Money Institution, based on the volume and type of operation you may not be required to carry out the full implementation. Proportionality is ultimately to be decided by the Regulator (competent authority), so do make sure to clarify this with them.
Q. A compliance approach may not be best as it can leave gaps. If we take a security approach, we may miss certain parts of compliance. How do we balance this?
A. The parts we don’t like still need to be done but at least let us let the compliance standard teach us something, starting from (i) thinking about the problem that this compliance requirement is intended to solve. (ii) thinking about the risk of the problem affecting our business, and (iii) choosing the most effective and efficient way to deal with it. Even PCI-DSS which is one of the most prescriptive standards, still allows for a variety of ways that you can tackle these requirements. If the risk is low and such risk is the consensus of the organisation, then we may indeed adopt an approach that is less painful while still complying to the standard while getting something out of it.
For instance, for one small organisation I worked for in the past the compliance standard specified that encryption keys needed to be rotated without specifying the frequency. Most simply adhere to NIST SP 800-57’s part on ‘recommendation for key management’ religiously (being a cryptoperiod of two years max). I first looked into the ‘why’ of this requirement and found that it’s to limit exposure in case a key were to be divulged to an attacker. In my case these DEK (data encryption keys) were being decrypted via an HSM in a well-isolated environment whose access was split between two key personnel. It simply made no sense to have a key rotation process every two years considering that the data volume was also low and the custodians were still going to be the same guys. The key rotation exercise of re-encrypting everything, taking extra backups in case the process goes wrong etc was going to create a higher risk of leaving data around than having the DEK stolen.
In this case we discussed and documented the risk, including notes about the strength of encryption algorithm itself. That provided justification to extend the cryptoperiod to at least 5 years, and put a special policy provision to carry out the key rotation when a key personnel such as the DB Admin were to leave the company. All in all the discussion (essentially a risk assessment exercise), also allowed us to learn something more about the strength of the encryption that was used, and reliance we had on these key personnel. This was well documented, reasoned with references, and accepted by the auditor.
Cannot say that all experiences had a ‘happy’ ending like this one (and that all auditors are reasonable). But at least we strive to reduce security theatre as much as possible. Doing things just because they are mandated by a compliance standard without addressing an underlying risk becomes very demotivating to whoever is tasked with implementing it.
Q. We have talked about security procedures, policies and explored related case scenarios. Can we discuss security threats trends expected for the upcoming years ?
A. From an organised crime perspective, supply chain attacks are a very lucrative target for organised bad actors. I don’t think that the XZ Utils package will be the last time we hear about such attack methods and who knows how many compromised packages are running on our systems.
In the phishing world, Voice AI will undoubtedly become the tool of choice where many will be receiving robocalls with voices of persons they recognise.
Complexity in itself is also a threat. Products are increasingly becoming secure, more accessible and more featureful, but more complex. Cloud systems in particular are accessible to anyone and lead one to think that they are inherently secure since your emails, your files and your web application is running on a big-name cloud service provider. Due to the complexity involved engineers may set things up insecurely resulting in common situations such as open S3 buckets. We are also seeing cases where very useful features such as connecting OAuth applications are being exploited by actors such as Midnight Blizzard. These attacks are proven to be successful due to secure defaults which were once adequate but are no longer aligning to new attack vectors fast enough.
Finally, the Quantum computing threat to cryptography is something to keep on the radar, however I personally don’t think that SMEs and the public should be overly concerned as yet.
Q. How secure is using AI like ChatGTP, Gemini, Copilot ? Are we unknowingly giving away our data ?
A. The old adage that if “You are getting something for free, you are the product” also applies here. Short answer; definitely, yes. ChatGPT does collect data and up to a few months ago it was on by default to help improve the model. Meta uses public Instagram pictures to train their models. Some are trying to take different approaches such as Microsoft’s Copilot for business where the data of an organisation lives compartmentalised to that account. My opinion is that as AI progresses towards being more human-like in the way of ‘thinking’ and reasoning, guard rails are going to become more and more difficult to implement effectively. Therefore, just like it’s difficult for us to keep secrets when placed in certain situations, AI will still be cajoled into divulging sensitive information it learns along the way.
Q. How can small companies address all the legislation and directives, without investing thousands of euro? Does it need a specific employee to address each role?
A. Ideally one reviews the operative ambit and seeks advice of either specialised lawyers or people to guide the respective outfit to adopt the most appropriate compliance models.
Q. What about the NIS2 legislation which is coming soon but has not yet been transcripted in Malta? How to get a large company with multiple suppliers prepared?
A. The departure line is NIS1 which is already in place, NIS2 will increase its capture with new sectors as well as more regulatory capture. It will be transposed October 2024 and like in the previous reply would advise them to either assess themselves the potential capture and start preparing for the compliance or else seek some counsel. For the case at hand I would also recommend building up an inventory of all the contractual relationships with pertinent providers or suppliers, review of these and gap analyses with new obligations which might stem from NIS2 and plan a smooth transition to get all in line by the required date.
Q. How are RTO, RPO, MTPD different? How should these be measured?
A. RTO = Recovery Time Objective: the amount of time it takes for an application to become fully operational again
Measuring RTO can be accomplished in a few ways: amount of time a ticket spends in status (assuming there is a ticketing system in place), or a more exact measurement would be the timestamp delta in the monitoring logs (assuming there is monitoring in place). If considering the logs method (preferred), best to wait for a threshold of repeated status before declaring a change; you will want to wait for the “200 OK” (for example) 3 times in a row before declaring the system to be back online.
RPO = Recovery Point Objective: the amount of data that can be afforded to be lose in terms of time elapsed during a system outage
Almost exclusively related to data, this one should be measured by the latest timestamp found in the relevant data stores; sort by “modified_at” in descending order, limit 1. How long ago was that? There is your actual recovery point.
MTPD = Maximum Tolerable Period of Disruption: the maximum amount of time of an outage that is considered acceptable
This one is not really meant to be measured like the other two. It is a business level target metric set by the relevant stakeholders. The MTPD is often driven by business factors and closely related to SLAs that have been agreed upon by your customers. Even then, MTPD can be larger than your SLA commitment, but how long until customers really start making a fuss? Measuring MTPD is the same as RTO. Whether or not MTPD has been breached is a calculation of RTO > MTPD?
Q. You mentioned a 5 minute (or less) RTO, but what about the associated costs, especially with SMEs?
A. Costs will vary from stack to stack. Cloud-born server less stacks are much easier to implement sub 5-minute RTOs, however, even server’d stacks can achieve with the right investment in automation. There is, of course, the added cost of additional infrastructure, but this is a workload-by-workload consideration; not all applications need to be < 5 minute RTO. In fact, a good practice is tiering applications by criticality (business critical, mission critical, operational, administrative—in that order). Only a subset of applications will be business critical, and I would argue that the cost of the additional infrastructure (if required) is more than justifiable. In that case, it comes down to the discipline of an automation-first approach where anything being built—even once—should be built in a way which is repeatable. With the added capacity and the automation for reconstitution, recovery should be entirely automatic in the first place. All that is left to do is test it, then test it again, and again! I said during my presentation: “you won’t fear leg day when every day is leg day”.
Q. So quantum encryption requires physical point to point link? Ie it is not an OTN function.
A. Yes. Quantum key distribution is something that happens at the physical (i.e., hardware / optical) level and therefore requires the use of a physical connection. One cannot emulate this in software, although in PRISM we are deploying such links over the existing telecoms network.
