Why Cars Are Increasingly Vulnerable to Cyber Attack

Adrian Davis, Managing Director, EMEA at (ISC)² explains how we can stop the ongoing proliferation of vulnerabilities in connected cars

It’s clear that we are rapidly moving towards turning cars into rolling internet browsers, connecting to everything from traffic lights to household appliances. Future vehicles will get remote updates on traffic jams or weather, automatically alert emergency services to accidents as they happen, allow drivers to get over-the-air ‘upgrades’ without visiting a dealership and even warm up their kettles from their cars. Software updates can now give cars self-driving features, turn them into rolling Wi-Fi hotspots or even allow them to interact with traffic lights.

All of these features mean that cars are becoming mobile data hotspots, receiving and sending information that can be exploited by automotive firms to sell or create more people-centric products or services. This data can also be sold to other companies to target location-based advertising at drivers, or help insurance companies set their rates. It is predicted that connected cars will soon send up to 25 gigabytes of data to the cloud every hour.

Yet all the indications are that cybersecurity has failed to keep pace with increasing automotive connectivity. This was starkly illustrated earlier this year when a team of hackers remotely took control of a Tesla from 12 miles away. Many basic software vulnerabilities have been found in cars, including a failure to apply basic encryption to remote car-locking.

The problem is that manufacturers are treating cybersecurity as an afterthought to the design process, with flaws only being found and fixed after the car is already on the road. This ‘fire brigade approach’ to cybersecurity was exemplified by Fiat Chrysler’s recall of 1.4 million vehicles after security researchers exposed a software flaw which should have been found at the design stage. It is as if car manufacturers were to build cars and forget to put door locks on them until someone managed to break into the vehicle.

This problem extends far beyond the automotive industry; (ISC)² has found that software applications are often not scanned for vulnerabilities during software development. This means that application vulnerabilities still top the list of security concerns among information security professionals worldwide.

The current automotive design model sees software developers and security researchers as two separate silos of expertise that rarely meet. This produces a disjointed approach to security, leading to panicked vehicle recalls and emergency software updates.

We need to see security as a core aspect of the automotive software development profession, just as vehicle safety is a central aspect of the automotive engineering profession. Car companies should be building cybersecurity into every piece of software from the beginning, just as they incorporate car locks, airbags and seatbelts into the car at the design stage.

Instead of the software developers outsourcing the task of cybersecurity to security researchers, security should become a core part of coding, integral to every part of the software development lifecycle.

This will require a change in the way that coding is taught, with cybersecurity turned into a core component of all school, college and degree courses in computing and software development. The UK is pioneering this approach.

BCS – The Chartered Institute for IT, which accredits most University computing courses in Britain, recently incorporated cybersecurity guidelines and learning outcomes in its official accreditation criteria for its computing degrees for the first time. This means that cybersecurity will no longer be taught as a stand-alone subject, but will soon be part of every computing degree. Everyone from software engineers to game developers will have a common base of cybersecurity knowledge. The first General Certificate of Secondary Education (GCSE) questions on cybersecurity were recently launched, and schools have also been receiving cybersecurity lesson packs as part of school computing classes. Meanwhile, the UK Engineering Council now includes cybersecurity in its UK-SPEC competence requirements for engineering professionals.

But there cannot simply be a supply-side solution to this. The automotive industry needs to further incentivise the new approach by including cybersecurity as one of the key criteria in their hiring checklists for coders. Cybersecurity knowledge needs to be considered a requirement for entry-level software developers, just as we would expect all automotive engineers to understand safety features and requirements. The only way to ensure the safety and security of all road-users in the age of connected cars is to is ensure all future software is designed with an electronic version of locks and seatbelts.

[(ISC)² Blog]

Tech Docs: Introducing the New Palo Alto Networks Compatibility Matrix

The Tech Docs team just rolled out the new Palo Alto Networks Compatibility Matrix (PDF). We produced this document to address feedback about the “findability” of compatibility and support information for our various next-generation security devices.

The new central Compatibility Matrix covers different compatibility and interoperability considerations for Palo Alto Networks devices. For example, it covers supported operating systems for each version of the GlobalProtect app, supported endpoint operating systems for User-ID and TS agents, PAN-OS version support by model (including WF-500, M-100 and M-500 appliances), Traps and ESM operating system support, and VM-Series hypervisor support.

All content in this new guide is fully vetted by Engineering and Product Management. The Tech Docs team will continue to keep this content up to date and add new sections as necessary.

Make a pit stop at Technical Documentation to find our content.

Happy reading!

Your friendly Technical Documentation team

Have a question? Email us at: documentation@paloaltonetworks.com

[Palo Alto Networks Research Center]

CSA’s Big Data Working Group seeking new Co-chairs to develop and maintain Research Portfolio

The Cloud Security Alliance’s Big Data Working Group is seeking new co-chairs to develop and maintain a research portfolio providing capabilities to lead the crystallization of best practices for security and privacy in big data, help industry and government on adoption of best practices, establish liaisons with other organizations in order to coordinate the development of big data security and privacy standards, and accelerate the adoption of novel research aimed to address security and privacy issues. These volunteer positions will have a one-year term commitment at minimum. The co-chair works in collaboration with the CSA Research Team and work group volunteers. The work group co-chair positions include the following duties which are shared and typically alternated between co-chairs:

  • Lead the research team that defines the vision and concept of the Big Data Working Group
  • Plan out the roadmap for deliverables related to the Working Group
  • Represent CSA as the SME in the areas of data-centric security and related privacy issues
  • Assist with work group administrative duties (i.e. Running Working Group Calls, Promoting Involvement of WG Members, etc)
  • Assist with organizing events, deliverables, and initiatives related to the Big Data working group
  • Other duties should be defined by the reconstituted working group.

The co-chair positions for this work group will be a rotating position. Being a co-chair of the work group presents great opportunities such as networking and interacting closely with volunteers representing some of the top minds in information security and cloud computing. If you have questions or are interested in becoming the co-chair for the Big Data Working Group, or if you would like to nominate someone for the position, please please email Frank Guanco.

For your convenience, here is the Big Data Working Group Charter to be updated with new leadership and the other documents the working group has produced.

[Cloud Security Alliance Research News]

Call for Participation: Contribute to CSA Security Guidance V.4 Peer Review

Closing Date: Jan 13th, 2017

The Cloud Security Alliance would like to invite you to review and comment on 12 Domains of the CSA’s Security Guidance for Critical Areas of Focus in Cloud Computing. This document acts as a practical, actionable roadmap to individuals looking to safely and securely adopt the cloud paradigm. This is your opportunity to provide feedback and identify any critical areas that we might be missing in the document’s focus.

The Domains that are going for peer review are:

To participate, please identify specific Domains which you have expertise in and follow the link to the Google Docs. You should be able to provide your comments in the document. Please do not provide editorial comments (i.e. grammar, formatting, etc), rather focus instead on the content of the document.

The peer review for the 12 Domains start today and ends one month from now, on the 13th of January. We appreciate your assistance. Thank you in advance for your time and contribution.

CSA Research Team

research@cloudsecurityalliance.org

[Cloud Security Alliance Research News]

Three Lessons From the San Francisco Muni Ransomware Attack

On Black Friday, a hacker hit San Francisco’s light rail agency with a ransomware attack. Fortunately, this story has a happy ending: the attack ended in failure. So why did it raise the hairs on the back of our collective neck? Because we fear that next time a critical infrastructure system is attacked, it could just as easily end in tragedy. But it doesn’t have to if organizations with Industrial Control Systems (ICS)  heed three key lessons from San Francisco’s ordeal.

First, let’s look at what happened: On Friday, Nov. 25, a hacker infected the San Francisco Municipal Transportation Agency’s (SMFTA) network with ransomware that encrypted data on 900 office computers, spreading through the system’s Windows operating system. As a precautionary measure, the third party that operates SMFTA’s ticketing system shut down payment kiosks to prevent the malware from spreading. Rather than stop service, SMFTA opened the gates and offered free rides for much of the weekend. The attacker demanded a 100 Bitcoin ransom, or around $73,000, to unlock the affected files. SFMTA refused to pay since it has a backup system. By Monday, most of the agency’s computers and systems were back up and running.

Here are three key lessons other ICS organizations should learn from the event, so they’re prepared to derail similar ransomware attacks as deftly:

  1. Recognize you are increasingly in cybercriminals’ cross hairs. Cyberattacks on ICS systems, which control public and private infrastructure such as electrical grids, oil pipelines and water systems, are on the rise. In 2015, the U.S. Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) responded to 20% more cyber incidents than in 2014. And for the first time since the agency started tracking reported incidents in 2009, the critical manufacturing sector experienced more incidents than the energy sector. Critical manufacturing organizations produce products like turbines, generators, primary metals, commercial ships and rail equipment that are essential to other critical infrastructure sectors.
  1. Keep your IT and OT separate. Thankfully, the San Fran Muni ransomware attack never went beyond SFMTA’s front-office systems. But, increasingly, cyber criminals are penetrating control systems through enterprise networks. An ICS-CERT report noted that while the 2015 penetration of OT systems via IT systems was low at 12 percent of reported incidents, it represented a 33 percent increase from 2014. Experts say the solution is to adopt the Purdue Model, a segmented network architecture with separate zones for enterprise, manufacturing and control systems.
  1. Invest in off-site, real-time backup. SFMTA was able to recover the encrypted data without paying the ransom because it had a good backup system. That wasn’t the case with the Lansing (Michigan) Board of Water & Light. When its corporate network suffered a ransomware attack in April, the municipal utility agency paid $25,000 in ransom to unlock its accounting system, email service and phone lines.

If San Francisco’s example isn’t enough to motivate ICS organizations to take cybersecurity seriously, then Booz Allen Hamilton’s 2016 Industrial CyberSecurity Threat Briefing should do the trick. It includes dozens of cyber threats to ICS organizations.

By Laurie Kumerow, Consultant, Code42

[Cloud Security Alliance Blog]

English
Exit mobile version