Varsha Saraogi (VS): Why are airports and airline companies becoming more vulnerable to cyber attack?

Paul Farrington (PF): The consequence of a cyberattack affects an airline and has a knock-on effect on passengers. When there is a cybersecurity incident it’s going to get media attention and rise to the top in the news agenda.

In our State of Software Security Report published at the end of 2018, there is an excerpt for industries in infrastructure which includes the aviation industry. It found that airports did a good job in closing out the flaws or potential vulnerabilities that are found in software within the first hundred days and, they actually beat the global averages across many different industries. So in that respect, evidence suggests that aviation companies do take their responsibility seriously in addressing the potential security risk.

However, what we do see with industries relating to infrastructure is that after a period of time things remained unfixed. After 125 days they start to deteriorate and become more delinquent. Complacency does set in and that’s where greater attention should actually be paid to ensure that across the software development lifecycle, developers are not just fixing the complex and sophisticated risks but actually addressing things like cross-site scripting, and preventing issues which could allow an attacker to penetrate a system.

VS: Why are airlines and airports so unprepared?

PF: Over the last 20 years an awful lot of attention – and quite rightly – has been paid to physical security, and ensuring that we have the tech in place to prevent a physical attack. Now, we need to ensure that we’re giving due attention and focus to preventing cybersecurity attacks. The Department of Transport has a five-year plan and a cybersecurity strategy which talks about all the measures that need to be in place.

The government along with the regulatory bodies – in the UK, CAA and in the US, FAA – are taking the responsibility seriously. But I think we also need to ensure that across the board, not just for the physical security but in software, we’re getting systems up to scratch. In our State of Software Security Report, [we found that] in the aviation industry, unfortunately, most software applications failed common security standards. Sorry, there are no polls available at the moment.

There is a security standard called the open web application security project and it provides a checklist of vulnerabilities – the security bugs we really don’t want to see in your software application. Only one in four applications that were tested against the standard passed the first inspection. The majority of those applications failed. Whether they’re on the ground or in flight, it’s crucial that we do a better job of ensuring that the systems which people rely on are safe and secure and the attackers don’t have any bail to breach.

VS: How does Veracode’s Greenlight software work?

PF: [Chris Wysopal and Christien Rioux created] a security tool, which – when they co-founded Veracode – became known as static analysis. Think of this as an MRI scanner, where you’re looking deep into the tissue that makes up the software for the potential weaknesses that an attacker could actually exploit to damage the system. But in the early days, static analysis was looking at the entire application which can take time to address the different potential weaknesses.

In the culture now, with the DevOps sentiment analysis in the last decade, developers are demanding faster analysis techniques because they’re under pressure to ensure that they’re producing software at a higher velocity. Greenlight actually uses the static analysis techniques, but rather than just looking at the entire application, it is able to look at the ‘incremental’ and analyse the things that have just been changed in a file. Greenlight is able to give developers feedback on the code they’ve created within seconds. The reason why we call it Greenlight actually is when they write a secure code, they get a green light, as an affirmation that what they’ve just done is correct.

Where security vulnerabilities have been spotted in the code, the software will actually highlight it and say ‘this is a potential security vulnerability,’ or ‘a flaw has been found and this needs to be addressed in the following ways.’ Developers can then make the changes when they get the results in seconds. If you compare that to receiving results an hour or a week later, the focus is lost and the incentive for the software engineer to actually address the issues are less.

VS: How can technology help airports combat cyberattacks?

PF: There is indeed too much emphasis on using clever human beings to find issues that automation would do ten times faster. So we need to make sure we’re getting that balance correct.

Trying to tackle the security problem with human beings won’t scale because there are only so many security experts in the world. In fact in 2019 today, there are more than two million vacancies across the world for cybersecurity experts and manual penetration testers are a part of that deficit of people who are qualified to perform analysis.

VS: Do you think human decision making can be balanced with automation?

PF: Market pressures will move more towards automation whether you’re an airport or an airline company. There needs to be sufficient emphasis from the government and from the regulators to address this issue.

In practical terms, with a combination of using automation and the right tools, we need to ensure that we have security experts in DevOps teams in companies for embedding security across the organisation. As we call them – DevSecOps, which is an evolution of DevOps, and they ensure that security is part of the entire conversation.

In terms of automation, when software gets committed back to the repository, what we can do is automate the scanning of that software. So without a developer needing to press a button, the software is scanned for vulnerabilities and those results are sent to the development team. In case of a functional defect, a ticket gets created and added to the system’s backlog which is a list of security issues that need to be addressed.

By doing so, it becomes just part of the normal hygiene of how software gets created and maintained. Having that as part of a company of creating code using automation and having a blinking light on the developer’s desktop when there’s a security issue means that without any undue coercing or disincentives to the developer, the software engineers address issues as they crop up as part of just the everyday working and this ensures that the software becomes more secure.

VS: How is technology like this likely to progress in the future?

PF: If you can leverage automation it gives you greater time to think about things like threat modelling.

Through the process of threat modelling, one can pre-empt the kind of potential attack and could subvert the application even before code is being written, ensuring that the software is designed in such a way that makes it really extremely hard for an attacker to take control.

Additionally, the way software gets created today is quite different from 20 years ago as the majority of it is comprised of open source components – code written outside your organisation. The problem with using open source software is that – just like your own – there is a tendency for it to be insecure. If it hasn’t been tested then there is a significant chance that vulnerabilities will exist in that software, so ensuring that we’re using open source components that are secure is really important. Critically, around 80 to 90% of companies use open-source software – many of which up until now have been unaware of how software is being created.

Going forward, the emphasis needs to be placed on how software is being brought in. What we’re talking about is a software supply chain because that’s of crucial importance to aviation.