“File-based threats should not be underestimated”

Could you tell us about Content Disarm and Reconstruction technology? What is it used for and how does it work?

Paul Farrington: Content Disarm and Reconstruction (CDR) technology is a proactive solution to file-based threats, with instant protection that goes above and beyond traditional reactive solutions such as antivirus and sandboxing. One of the ways cybercriminals attempt to insert malware into a system is via malicious code hidden in files that on the surface appear to be completely harmless. Once a user opens the file, this enables macros and infects the computer with the malware.

To prevent this, with CDR, files and documents undergo a rapid four-step process in which they are inspected, cleaned, rebuilt, and delivered. First, the file is inspected to confirm that its digital DNA doesn’t vary from the manufacturer’s ‘known good’ specification. Next, the file is cleaned to remove any active high-risk content – such as embedded links or macros – and then is rebuilt to the ‘known good’ specification, with any security blind spots closed off. Finally, once the file is free of any threats, it is delivered to the user with the same appearance as the original file, ready to open and use without fear of malicious content. The process happens quickly and is an effective way of removing file-based threats without impacting users’ productivity.

What should everyone know about file-based threats? Are specific formats more likely to contain malicious code?

Paul Farrington: Malicious files are currently one of the most common cyberattack vectors, and receiving dangerous files through email is becoming all too familiar. One recent study found that 21% of all infected files are sent via email, with 53% of viruses spread by .exe files, or executables. These numbers are concerning, given that another study revealed 46% of hackers attempting to spread malware deliver it almost exclusively through email, with the malicious files typically in Word or Excel formats.

File-based threats should not be underestimated. They remain one of the most popular attack methods for cybercriminals and for users, they are not always easy to spot. Every single employee in an organisation must be vigilant – cybercriminals only need to be successful once. While a file may look harmless at first glance, once you open it you could be risking huge damage to your organisation, not only financially but also in terms of reputation and customer trust.

How can developers determine the safety of a piece of software before using it?

Paul Farrington: Development teams will usually use open-source components or frameworks to help accelerate the speed at which software can be written. The challenge with open-source software, however, is that it is not necessarily scanned for vulnerabilities before it is used.

For developers, a simple but crucial security measure is to turn on automated scanning of third-party components, so that any vulnerable code in their software is flagged immediately. There are plenty of cost-effective software composition analysis (SCA) solutions available for this, and some are free to use so there’s no excuse not to implement this protective measure.

How can security teams better communicate with developers and lay down more effective security rules and restrictions?

Paul Farrington: Where a vulnerability is detected, the developer should be given an immediate solution to address the issue. This may seem obvious, but far too often security solutions are great at identifying problems but don’t always provide adequate help towards a resolution. Security teams should aim to be solution architects, not problem architects. This is one of the main aims behind CDR: by giving users a ready-formed solution that returns files to a known-safe form, rather than just identifying a problem, you can minimise risk whilst providing a solution. The aim should be delivering security as an enabler – rather than development teams seeing security as something that slows them down.

Helping developers to identify better paths for avoiding security issues is a more productive strategy, rather than scanning and scolding. Practically speaking, this means ensuring that engineers have access to security champions, who probably also code but have acquired knowledge about how to write more secure code. There should be incentives for being a security champion, in helping to move the needle without reducing payload delivery velocity.

Is the prevalence of open-source software affecting security concerns?

Paul Farrington: According to research, the number of open-source projects impacted by intentionally malicious vulnerabilities is actually relatively low. In comparison, 115,000 projects have been hit by only a very small handful of accidental vulnerabilities, named Prototype Pollution, which target JavaScript projects – nearly 27% overall. Cybercriminals using malware are typically still targeting organisations with business document-based threats like PDF, Word or Excel. However, this isn’t to say that open-source is completely free from threat – attackers will use any vector they can to breach an organisation.

You’ve worked in IT and the cybersecurity sector for over 20 years. What has changed in that time? Do you think we have become better equipped to handle vulnerabilities?

Paul Farrington: There’s been exponential growth in the amount of software in the world. That’s fueled astonishing amounts of data being created and transferred each year. According to Gartner, IT Security spend has been relatively flat for the last five years at around 5% of total IT expenditure. In contrast, the attack landscape is intensifying. Bad actors can earn a very decent living by trading sensitive data about firms and individuals, and digital assets are in abundance. Only last month Sky Mavis reported that their Axie Infinity online crypto gaming portal had suffered a breach which resulted in $600,000 of funds being lost. So there’s never been more incentive for attackers to benefit from security vulnerabilities or misconfigurations.

When we think about the types of software vulnerabilities that exist in code, we see relatively little change in the types of security flaws which can be expressed in code. The adoption of newer, more secure programming languages and frameworks can make it less easy to make the same old programming mistakes, with some in-built protection for cross site scripting or other injection attacks, for example. So we should be optimistic about how things are getting better in that respect. Software applications tend to use a great deal of open source code, and these components or libraries can all too frequently incorporate vulnerabilities.

Today, developers now have access to excellent tools that can help pinpoint and to fix security vulnerabilities. These can produce results within seconds both in the integrated development environment (IDE) and within a pipeline. Security and development leaders need to ensure that developers are incentivised to use these, which also means providing roadmap time to burn-down security debt.

What tools should every developer have at their disposal for ensuring best security practices?

Paul Farrington: One of the most important aspects of software development when it comes to achieving ‘secure by design,’ is to ensure developers have the tools they need at the time they are writing code. Deploying security tools sometime after, when a developer may have closed their laptop for the day, or even completed the whole project, is far too late. Developers need to receive feedback in a timely manner to ensure the software is safe. It’s about security first and foremost, but it’s also to ensure the performance of the software and its ability to do what it is meant to do.

Developers need access to software composition analysis in their IDEs and in their pipelines. This will help to dramatically reduce the selection and use of vulnerable open source components. Secondly, they need access to a reliable security static analysis and code quality analysis tools, to help eliminate security flaws and unreliable functions from the software being written. Finally, with so many applications relying on cloud-native technologies like containers or Kubernetes, developers need to assess the security of infrastructure as code (IaC) configurations as well. This will help to ensure that software is run with least privilege and with a discrete attack surface. There are solutions on the market today which offer all tools in a single offering.

The post “File-based threats should not be underestimated” appeared first on JAXenter.