Tuesday 5 November 2019

Let's talk about computers on wheels

Originally published in Intopalo Digital's company blog:
https://www.intopalo.com/blog/2019-12-05-computers-on-wheels/


Would you agree that the term “computer on wheels” is an accurate way to describe a modern automotive vehicle? When you sit inside a car, do you feel that you are sitting inside a computer? Probably not, but it is not very far fetched to make that claim, and it comes with implications. Read on to find out more and to see if you agree or disagree with this claim.

One point of clarification first, however. While this blog talks about automotive vehicles and more specifically about cars, we can apply this to most other modern automotive vehicle types such as motorcycles, trucks, tractors, ships, boats, airplanes, and so on. Having said that, let’s get started.

Coming a Long Way

The automotive industry has come a long way. While Karl Benz built his first Motorwagen, which we generally consider to be the first modern car, in 1885, the automotive industry has existed since the 1860s. This is not to say that the concept of self-powered vehicles was a 19th-century innovation: the first full-scale, steam-powered tricycle was built in 1796 by Nicolas-Joseph Cugnot, while Ferdinand Verbiest is known to have designed a steam-powered toy vehicle for the Chinese Emperor in 1672. The history goes all the way back to 1478 when Leonardo Da Vinci drew plans for a self-propelled, spring-powered car(t).

In other words, cars in various forms and functions have been part of our lives for many generations. Over the many decades, cars have evolved in ways the first generation designers might not even have imagined to be possible (case in point: NASA’s LRV or the Lunar Roving Vehicle), while their essential functions have mainly remained the same.

Cars have many symbolic values and ideals attached to them as much as there are practical considerations, too. Cars embody the freedom of movement. Cars enable the transportation of passengers and goods, and by extension, create great many business opportunities. Cars offer excitement and memorable experiences in many forms, from social settings to a variety of motorsports. And let’s be honest here, for some people, cars also reinforce their sense of self-importance and public image.

With all that, how many people look at their cars and see a computer?

A Computer on Wheels

A modern car is very much a computer on wheels. More than that, it is not just the engine and a set of wheels (and a heavy right foot) that makes a car move, but a network of dozens of highly specialized computers commonly referred to as Electronic Control Units (ECUs). A modern car might have up to a hundred different Electronic Control Units, such as Central Control Module (CCM), Engine Control Module (ECM), Transmission Control Module (TCM), Central and General Electronic Module (GEM). When you press a button and the side window opens? There’s an Electronic Control Unit operating that too. The number of ECUs in a car grows as manufacturers come up with new features and functionalities for their car models.

Electronic Control Units are connected to other ECUs and a multitude of sensors, switches, electric motors, actuators, and dials via a local network, the Controller Area Network, which is commonly referred to as the CAN bus. Conceptually this is very much like the LAN (Local Area Network) that connects a computer with other computers, local network appliances (printers, TVs, and the like) and the Internet in homes and offices.

So we have established that a car can be described as an automotive computer network, which has the potential to get from zero to 100 km/h pretty darn fast.

For the most part, Electronic Control Units communicate only locally with other units connected to the same CAN bus (there can be other local networks as well, but let’s not go there now). Computers and networks have interfaces to enable communication and interaction, and the same holds true with cars: an ECU is essentially a highly specialized computer that communicates with other similar units over the local Controller Area Network. This network can be physically interfaced with via an On-Board Diagnostics (OBD) port, which is the primary means for mechanics to find out about the state of the car. It is also how the various Electronic Control Units in cars can be programmed.

While OBD can be seen as the primary interface to the car’s network of Electronic Control Units and other related components, there is an increasing number of additional interfaces that enable both physical and wireless communication with the car. For example, a car navigator receives positional data wirelessly from a Global Navigation Satellite System (GNSS) such as GPS, Galileo, GLONASS, or BeiDou. Many cars have a USB-port for people to connect their mobile devices while also offering Bluetooth connections for the same purpose. 4G and 5G connection will become increasingly common as cars are linked up with cloud services to upload car statistics as well as to download apps and updates. Through all this, cars are being transformed from merely providing means of transportation to also contain repositories of personally identifiable data, among other things.

Hackable Interfaces

The thing with computers is that they all can be hacked. From this follows that a modern car can be hacked as well. Sounds a bit dodgy? As it happens, mechanics, motorsports teams and car enthusiasts have been doing this for a long time by programming and tweaking their engine settings and other performance influencing parameters — nothing wrong with that (though it very likely will void the warranty of your car). However, as cars become more sophisticated and easier to interact with, they are also becoming increasingly attractive targets for other kinds of hackers as well — the kind that thinks in terms of attack vectors and exploitable opportunities for various reasons and motivations.

For example, having a “keyless” car is pretty handy, but an RFID-based keys could be cloned. Sharing the car data in an unsecure cloud service could enable outside parties to track the movements of the car or to learn details about its usage. The worst case scenario could be, if the car’s internal network can be accessed from outside, an intruder could be enabled to manipulate some of the car’s subsystems. As potential attack vectors and exploits go, the development of modern cars is opening up opportunities.

This, by itself, does not need to be a problem. Other computers such as Windows, OS/X, and Linux desktops and laptops, smart-phones, and networked home appliances face similar issues. Instead, what can be seen as a problem is the lack of awareness: with ordinary computers, the users are already familiar with concepts such as computer viruses, password safety, data encryption, and having backups. Smart-phone users are learning to be wary of third-party apps, microtransactions, excessive use of network bandwidth, and suspicious calls from international numbers. There are active discussions about information security issues related to the Internet of Things, and so on. However, when it comes to cars, it is probably safe to say that information security concerns are not very high in a list of consumer concerns. The idea of having to install a virus scanner to a car might seem laughable now, but in the not-too-distant future this might actually be a responsible thing to do. While you are at it, you might as well check the firewall of your car and install the latest security patches.

The point is that vehicle information systems continue to become more sophisticated, and various means of interfacing with a car, both physically and remotely, are also increasing. All parties, and especially consumers, need to take the information security issues seriously or, at least, become more aware of the matter. Safety and reliability are very high in the automotive industry’s list of priorities, so there should be no doubt that the same attention will be given to information security concerns as well. It is just that we do not commonly associate with cars topics such as authentication and authorization (beyond having the car keys), network firewalls and encrypted connections, Secure Development Lifecycle (SDL) and other secure programming practices, penetration testing (without using a crowbar), data protection and cloud service issues. At least not yet, in the minds of ordinary people.

Conclusion

In the near future, as driverless cars become more common, people are going to become more aware of the reality that it might no longer be a human who is in charge of a moving vehicle. Vehicle-to-vehicle networks will also evolve and become more common as a means for cars to exchange information about their speed, position, heading, and other actions. This will make it easier to manage the flow of traffic, reduce traffic jams, and improve overall road safety, but not without introducing a new set of information security concerns. For some people it may be challenging to give up their sense of control unless they can substitute it with an improved sense of security and trust.

To conclude, as information systems are becoming ever more sophisticated, the automotive industry is facing new challenges that might not be traditionally associated with vehicle manufacturing. The information security and secure software development practices that are the norm in the software industry will, by necessity, be adopted by the automotive industry to build better and safer vehicles. For example, consider the following twelve practices from SDL:

  1. Provide training
  2. Define security requirements
  3. Define (security and privacy) metrics and compliance reporting
  4. Perform threat modeling
  5. Establish design requirements
  6. Define and use cryptographic standards
  7. Manage security risks of using 3rd party components
  8. Use approved tools
  9. Perform Static Analysis Security Testing (SAST)
  10. Perform Dynamic Analysis Security Testing (DAST)
  11. Perform penetration testing
  12. Establish a standard incident response process

With these and other information security related concerns, you are more than welcome to contact us and have our software and security professionals help your project to be successful.

Monday 30 September 2019

Introduction to the OWASP Top 10 - 2017

Originally published in Intopalo Digital's company blog:
https://www.intopalo.com/blog/2019-10-24-owasp-top-10/
 
This blog entry is about the OWASP Top 10 - 2017 and is primarily intended as an introduction for people commonly involved in software development and acquisition projects. 

The high-level topics are:
  1. What is the OWASP Top 10 - 2017
  2. Reasons to Use the OWASP Top 10 - 2017
  3. The Top 10 Issues Overview
tl;dr: the OWASP Top 10 is a list software vulnerabilities that are commonly overlooked or ignored during development and testing, and that have been successfully exploited with various levels of harm to businesses and users. The OWASP Top 10 should be part of most if not all project requirements specifications, architecture design and/or testing plan.

This text is primarily based on OWASP Top 10 - 2017

1 What is the OWASP Top 10 - 2017

While the original goal of the OWASP Top 10 was simply to raise awareness among developers about common software vulnerabilities, it has since become the de facto application security standard. It is, however, merely a starting point: by securing an application against the top 10 threats does not mean that the application is secure; there much more than that when it comes to secure software and information security.
A primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the consequences of the most common and most important web application security weaknesses. The Top 10 provides basic techniques to protect against these high-risk problem areas and provides guidance on where to go from here.
The 2017 release replaces the previous 2013 release. It is primarily based on over 40 submissions from application security-oriented companies, and an industry survey that received responses from over 500 individuals. All and all the data is based on experiences and observations from hundreds of organizations and "over 100,000 real-world applications and APIs".

The survey data has been made publicly available in GitHub.

2 Reasons to Use the OWASP Top 10 - 2017

The two most obvious and important reasons to pay proper attention to these top 10 issues relate to software development and software acquisitions. 

For people involved in software development, it should be a matter of professionalism to be aware of the common vulnerabilities (and by extension, potentially exploitable weaknesses) and to do their best to have these issues covered in their projects.

At very least these issues (as applicable) should be covered in testing and have them fixed before production release, if discovered.

For people involved in software acquisitions, it literally pays to require suppliers to prove that their software has been tested against these known issues. This should be stipulated either in contract or in project requirement specification. Alternatively, a risk assessment or code review could be performed for an on-going project to discover if these issues are present.

All and all by taking note of these issues as early as possible in a project significant time and resources (= money) can be saved instead of trying to patch the project later down the road. More importantly, if these vulnerabilities find their way to production and then get exploited, potential damages for a business can be severe depending on what kind of information was exposed.

Why take the risk?

3 The Top 10 Issues Overview

A1:2017 - Injection

Injection flaws typically occur when untrusted data is accepted without being properly validated and/or encoded before being passed on to an interpreter as part of command or query. As a result the injected code change the intended functionality into something harmful that can access or process in unintended ways.

A2:2017 - Broken Authentication

Incorrectly implemented authentication and session management can make it possible to compromise user credentials, assume different user's identity, elevate access rights without authorization or exploit the system in many other ways resulting in unauthorized access to data and functionalities.

A3:2017 - Sensitive Data Exposure

It is all too common that a web application or API does not properly protect access to sensitive data. Data can be stolen or modified unless properly protected e,g, by applying authentication or at very least having it encrypted (encryption at rest or in transit).

A4:2017 - XML External Entities (XXE)

Many XML processors evaluate external entity references in an XML file, which can cause all kinds of unexpected grief especially when XML (or the referred entities!) are received from untrusted sources: they can be used to disclose internal files and file shares, scan internal ports, execute remote code or denial of service attacks. 

A5:2017 - Broken Access Control

Even when authenticating users is handled properly, the authorization of users often leaves much to be desired. By not implementing (preferably a robust role based) access policy or by failing to enforce the access restrictions one may enable an attacker to access unauthorized user data or system resources, or even to change the system's access rights etc.

A6:2017 - Security Misconfiguration

This is arguably the most common security mishap, which can be caused by variety of mistakes, omissions and overlooks. For example, the system might be using unsecure default configuration (e.g. the default admin password has not been changed), overly helpful error / debug messages reveal exploitable details about the system's behaviour and configuration, some ad hoc configuration change might have unintended consequences and so on. The security misconfiguration may take place at any level ranging from operating system, third party libraries and frameworks and/or application's business logic or settings. This topic also includes all security patches that were never installed...

A7:2017 - Cross-Site Scripting (XSS)

Application that accepts untrusted data from external source without proper validation and escaping is vulnerable against cross-site scripting. This allows an attacker to execute unintended scripts in the user's browsers, which may result in redirection to a malicious site, having the session hijacked or having the site's page content changed in some more or less subtle ways.

A8:2017 - Insecure Deserialization

Application that fail to deserialize objects securely may end up executing unintended remote code with various harmful consequences. Alternatively (or additionally) the application might be open to replay attacks, injection attacks and privilege escalation attacks.

A9:2017 - Using Components with Known Vulnerabilities

It is a common practice to utilise third party libraries, frameworks and other software components or services when developing a new application. It makes perfect sense: why re-invent the wheel when there is a perfectly good solution that already gets the job done? However, all these third-party solutions are subject to same security threats and software vulnerabilities as your application is and using an external solution with known vulnerabilities may end up compromising the application in question in various unexpected ways.

A10:2017 - Insufficient Logging & Monitoring

No one should consider logging as something developers do to debug the application. Logging is the primary method of keeping a record of application's various activities. Proper logging combined with active monitoring is how various misconducts can be detected, identified and ultimately reacted to. Logs are also the primary source of information after a breach has been detected and the response team is trying to figure out what exactly happened.


Tuesday 24 September 2019

Introduction to the OWASP Application Security Verification Standard (ASVS)

Originally published in Intopalo Digital's company blog:
https://www.intopalo.com/blog/2019-10-17-owasp/

This blog entry is about the OWASP Application Security Verification Standard (ASVS), and primarily intended as an introduction for people commonly involved in software acquisition and development projects. There are four high-level topics:
  1. What is the ASVS
  2.    Security levels of the ASVS
  3. Reasons to use the ASVS
  4. The ASVS structure
tl;dr: the ASVS is informative and authorative, which is to say, it is very useful, and most projects would do well to utilise it.

1 What is the ASVS

“The ASVS is a community-driven effort to establish a framework of security requirements and controls that focus on defining the functional and non-functional security controls required when designing, developing and testing modern web applications and web services.”
The ASVS version 4.0 was released in March 2019. It was developed in the open and is hosted in GitHub (https://github.com/OWASP/ASVS). As an open project anyone interested is invited to follow and participate in the development of future versions of the standard, for example, by submitting issues, pull requests and translations.

While there are other standards and practices covering software and information security issues, the ASVS 4.0 strives to become "the leading web applications and services standard, covering traditional and modern application architecture, and agile security practices and DevSecOps culture". With this goal in mind the ASVS 4.0 is aligned with other well-known projects and standards, such as Common Weakness Enumeration, NIST 80-63-3 Digital Identity Guidelines, and PCI DSS 3.2.1 Requirement 6.5.x for application design, coding, testing, secure code reviews and penetration tests.

As of version 4.0 the ASVS is intended to become the baseline ASVS for all other related projects, such as the Mobile Application Security Verification Standard (MASVS) and the Internet of Things Application Security Verification Standard (IoT ASVS), which is currently included in the ASVS 4.0 as Appendix C as an early preview.

2 Security levels of the ASVS

The ASVS has two stated primary goals:
  1. to help organisations develop and maintain secure applications
  2. to allow security service vendors, security tools vendors, and consumers to align their requirements and offerings.
To accomplish these the ASVS defines three security verification levels starting from basic and progressing to increasingly more demanding requirements. 

2.1 ASVS Level 1 - Basic

This is the bare-bones level for low assurance levels and should be considered as the minimum that (most if not) all applications should strive for. Level 1 is the only level that is completely penetration testable without having access to documentation, source code, configuration and/or the development team. However, while "black box" approach is possible it is by no means recommended as it is completely unable to cope with the harsh realities and security threats of running an application "in production".

In order achieve Level 1the application must "adequately defend against application security vulnerabilities that are easy to discover and included in the OWASP Top 10 and other similar check lists". As such this level is mainly intended for applications that do not handle sensitive data.

2.2 ASVS Level 2 - Standard

This is the recommended level for most applications. At very least it should be considered when the application handles significant business-to-business transactions or process sensitive (e.g. health care) information, implement business sensitive / critical functions, or is used in industries where integrity is a critical facet to protect business.

In order to achieve Level 2, the application must "adequately defend against most of the risks associated with software today" by having security controls in place, effective and used within the application. 

2.3 ASVS Level 3 - Advanced

This is the advanced level intended for applications that are used in areas such as military, government, health and safety or critical infrastructure - generally speaking Level 3 should be applied whenever significant levels of security verification is required.

In order to achieve Level 3, the application must "adequately defend against advanced application [of] security vulnerabilities and also demonstrate principles of good security design".

A Level 3 application should be meaningfully modularized with multiple layers of security and controls to ensure confidentiality, integrity, availability, authentication, authorisation, non-repudiation and auditing. In practice we are talking about topics such as proper use of data encryption, input validation, transactions, system scalability and logging. It should go without saying that proper documentation is also expected.

3 Reasons to use the ASVS

3.1 As Secure Coding Checklist

According to the OWASP, "one of the best ways to use the Application Security Verification Standard is to use it as a blueprint to create a Secure Coding Checklist specific to your application, platform or organization".

While using automated DAST (Dynamic Application Security Testing), SAST (Static AST) or IAST (Interactive AST) tools are recommended as part of the development process, it should be noted that no more than about half of the ASVS can be completed without human assistance. For example, finding flaws in business logic and access control are (at least in the foreseeable future) beyond the capabilities of automated tools.

3.2 As a framework for Guiding the Procurement of Secure Software

Any person who is about to buy an application or make an order development project would benefit from relying on the ASVS by specifying that the application must meet the requirements for the ASVS Level X. This should ensure that the delivery will meet certain level of expectations.

This works even better when combined with the OWASP Secure Software Contract Annex.

3.3 As detailed security architecture guide

Even if the ASVS is not directly used in a project, it is a great resource for security / software architects. It lists a wide variety of problems and risks while helping to come up with reasonable solutions.

3.4 As a guide for automated unit and integration tests

By turning the ASVS checks into automated unit and integration tests the quality assurance work can be improved greatly - especially when running these tests as part of the project's Continuous Integration / Delivery setup.

3.5 As support for secure development training

In many ways the ASVS defines what "secure software" in practical terms. It will help the developers to focus on proactive controls and reliable solution methods.

3.6 As a driver for Agile Application Security

The ASVS can be included in an agile development process to define specific tasks that need to be implemented in order to have a secure product. These tasks can be included the Product Backlog and discussed with stakeholders as much as they can be used to guide agile design work.

4 ASVS structure

The ASVS 4.0 is divided into 14 chapters.

V1: Architecture, Design and Threat Modelling Requirements

“Security architecture has almost become a lost art in many organisations. [...] Architecture is not an implementation, but a way of thinking about a problem that has potentially many different answers, and no one single ‘correct’ answer.”
This chapter covers the primary aspects of any sound security architecture: availability, confidentiality, processing integrity, non-repudiation, and privacy. All these aspects must be built in to the application, and usually cannot be meaningfully added as an afterthought at the end of the project.

V2: Authentication Verification Requirements

“Authentication is the act of establishing, or confirming, someone (or something) as authentic and that claims made by a person or about a device are correct, resistant to impersonation, and prevent recovery or interception of passwords.”
The classic combination of username and password is no longer enough, when security is considered. For example, NIST 800-63 considers these to be public information. A modern application requires much more robust approach to authentication.

V3: Session Management Verification Requirements

“One of the core components of any web-based application or stateful API is the mechanism by which it controls and maintains the state for a user or a device interacting with it.”
This chapter aims to ensure that an application satisfies the following high-level session management requirements:
  • Sessions are unique to each individual and cannot be guessed or shared.
  • Sessions are invalid when no longer required and timed out during periods of inactivity.

V4: Access Control Verification Requirements

“Authorization is the concept of allowing access to resources only to those permitted to use them.”
 This chapter aims to ensure that an application satisfies the following high-level requirements:
  • Persons accessing resources hold valid credentials to do so.
  • Users are associated with a well-defined set of roles and privileges.
  • Role and permission metadata are protected from replay or tampering.

V5: Validation, Sanitation and Encoding Verification Requirements

“The most common web application security weakness is the failure to properly validate input coming from the client or the environment before directly using it without any output encoding.”
This chapter aims to ensure that an application satisfies the following high-level requirements:
  • Input validation and output encoding architecture have an agreed pipeline to prevent injection attacks.
  • Input data is strongly typed, validated, range or length checked, or at worst, sanitised or filtered.
  • Output data is encoded or escaped as per the context of the data as close to the interpreter as possible.

V6: Stored Cryptography Verification Requirements

 This chapter aims to ensure that an application satisfies the following high-level requirements:
  • All cryptographic modules fail in a secure manner and that errors are handled correctly.
  • A suitable random number generator is used.
  • Access to keys is securely managed. 

V7: Error Handling and Logging Verification Requirements

“The primary objective of error handling and logging is to provide useful information for the user, administrators and incident response teams. The objective is not to create massive amounts of logs, but high-quality logs, with more signal than discarded noise.”
This chapter aims to ensure that an application satisfies the following high-level requirements:
  • No collecting or logging [of] sensitive information unless specifically required.
  • Ensure all logged information is handled securely and protected as per its data classification.
  • Ensure that logs are not stored forever, but have an absolute lifetime that is as short as possible.

V8: Data Protection Verification Requirements

There are three key elements to sound data protection: Confidentiality, Integrity and Availability (CIA).
This chapter aims to ensure that an application satisfies the following high-level requirements:
  • Confidentiality: data should be protected from unauthorized observation or disclosure both in transit and when stored.
  • Integrity: data should be protected from being maliciously created, altered or deleted by unauthorized attackers.
  • Availability: data should be available to authorized users as required. 

V9: Communication Verification Requirements

This chapter aims to ensure that an application satisfies the following high-level requirements:
  • TLS (Transport Layer Security) or strong encryption is always used, regardless of the sensitivity of the data being transmitted.
  • The most recent, leading configuration advice is used to enable and order preferred algorithms and ciphers.
  • Weak or soon to be deprecated algorithms and ciphers are ordered as a last resort.
  • Deprecated or known insecure algorithms and ciphers are disabled.

V10: Malicious Code Verification Requirements

“Finding malicious code is proof of the negative, which is impossible to completely validate. Best efforts should be undertaken to ensure that the code has no inherent malicious code or unwanted functionality.”
This chapter aims to ensure that an application satisfies the following high-level requirements:
  • Malicious activity is handled securely and properly to not affect the rest of the application.
  • [Application] does not have time bombs or other time-based attacks.
  • [Application] does not "phone home" to malicious or unauthorized destinations.
  • [Application] does not have back doors, Easter eggs, salami attacks, rootkits, or unauthorized code that can be controlled by an attacker.

V11: Business Logic Verification Requirements

This chapter aims to ensure that an application satisfies the following high-level requirements:
  • The business logic flow is sequential, processed in order, and cannot be bypassed.
  • Business logic includes limits to detect and prevent automated attacks, such as continuous small funds transfers, or adding a million friends one at a time, and so on.
  • High value business logic flows have considered abuse cases malicious actors, and have protections against spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks. 

V12: File and Resources Verification Requirements

This chapter aims to ensure that an application satisfies the following high-level requirements:
  • Untrusted file data should be handled accordingly and in a secure manner. 
  • Untrusted file data obtained from untrusted sources are stored outside the web root and with limited permissions.

V13: API and Web Service Verification Requirements

This chapter aims to ensure that an application that uses trusted service layer APIs (commonly using JSON, XML or GraphQL) has:
  • Adequate authentication, session management and authorization of all web services. 
  • Input validation of all parameters that transit from a lower to higher trust level.
  • Effective security controls for all API types, including cloud and Serverless API.

V14: Configuration Verification Requirements

This chapter aims to ensure that an application has:
  •  A secure, repeatable, automatable build environment.
  • Hardened third party library, dependency and configuration management such that out of date or insecure components are not included by the application.
  • A secure-by-default configuration, such that administrators and users have to weaken the default security posture.