Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

9/10/2010
07:54 AM
Gadi Evron
Gadi Evron
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

'Virus Crashes Plane' And Poor Safety Protocols

Now that people are done making noise about how a "virus crashes a plane," the subject can be discussed reasonably.

Now that people are done making noise about how a "virus crashes a plane," the subject can be discussed reasonably.The original story I saw on MSNBC stated:

Authorities investigating the 2008 crash of Spanair flight 5022 have discovered a central computer system used to monitor technical problems in the aircraft was infected with malware.
And the secondary headline then states:
Computer monitoring system was infected with Trojan horse, authorities say.

The system in question was on the ground, and could have prevented the plane from taking off if it worked correctly. If we removed all the hops from preventing to crash, it can be said that the virus crashes the plane, theoretically. But it effectively caused a system to prevent it from flying.

It crashed for other reasons.

So what's the fault here? Not taking the monitoring systems seriously enough to secure them, not taking the monitoring systems seriously enough to prevent the malware from getting on them, and not taking the monitoring systems seriously enough to create backups and a trust environment that doesn't fall with a single-point of failure.

Security is serious and should be a consideration. But it is not a virus that crashed the plane, as much as that headline is cool and I would have used it, too, if while being more clear.

I can't wait for every presentation on security in the coming year to name the "virus crashed plane" as a fact, rather than a series of failures.

Follow Gadi Evron on Twitter: http://twitter.com/gadievron.

Gadi Evron is an independent security strategist based in Israel. Special to Dark Reading. Gadi is CEO and founder of Cymmetria, a cyber deception startup and chairman of the Israeli CERT. Previously, he was vice president of cybersecurity strategy for Kaspersky Lab and led PwC's Cyber Security Center of Excellence, located in Israel. He is widely recognized for ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-16123
PUBLISHED: 2020-12-04
An Ubuntu-specific patch in PulseAudio created a race condition where the snap policy module would fail to identify a client connection from a snap as coming from a snap if SCM_CREDENTIALS were missing, allowing the snap to connect to PulseAudio without proper confinement. This could be exploited by...
CVE-2018-21270
PUBLISHED: 2020-12-03
Versions less than 0.0.6 of the Node.js stringstream module are vulnerable to an out-of-bounds read because of allocation of uninitialized buffers when a number is passed in the input stream (when using Node.js 4.x).
CVE-2020-26248
PUBLISHED: 2020-12-03
In the PrestaShop module "productcomments" before version 4.2.1, an attacker can use a Blind SQL injection to retrieve data or stop the MySQL service. The problem is fixed in 4.2.1 of the module.
CVE-2020-29529
PUBLISHED: 2020-12-03
HashiCorp go-slug before 0.5.0 does not address attempts at directory traversal involving ../ and symlinks.
CVE-2020-29534
PUBLISHED: 2020-12-03
An issue was discovered in the Linux kernel before 5.9.3. io_uring takes a non-refcounted reference to the files_struct of the process that submitted a request, causing execve() to incorrectly optimize unshare_fd(), aka CID-0f2122045b94.