Saturday 28 March 2020

Learning from Machiavelli: about foreseeing and forestalling future problems

”[...] The Romans were simply doing what all wise rulers must: not restricting themselves to dealing with present threats but using every means at their disposal to foresee and forestall future problems as well. Seen in advance, trouble is easily dealt with; wait until it’s on top of you and your reaction will come too late, the malaise is already irreversible. 
”Remember what doctors tell us about tuberculosis: in its early stages it’s easy to cure and difficult to diagnose, but if you don’t spot it and treat it, as the time goes by it gets easy to diagnose and hard to cure. So it is with affairs of state. See the trouble in advance (but you have to be shrewd) and you can clear it up quickly. Miss it, and by the time it’s big enough for everyone to see it will be too late to do anything about it.”
(Niccolo Machiavelli: The Prince)

considering environmental change and COVID-19, just to mention a few examples, best damn words to live by for any (and all) political leaders. Wouldn’t be a bad thing if the people would also keep this in mind after the pandemic crisis has been dealt with and populist/opportunistic politicians begin to demand that money must be taken away from scientific research, social support, medical services and generally speaking from various preparations that would strengthen the nation against the next inevitable (maybe unknown) crisis for the benefit of some short term, politically convenient low hanging fruit -project.

Case in point: Trump disbanded the White House’s pandemic response task force in 2018 and cut funding for the Centers of Disease Control and Prevention (among other similar organisations).

Sweden had robust infrastructure, plans and storage facilities to handle nation wide crisis situations, but after Soviet Union collapsed all this was severely reduced (along with their army, which also turned out to be a bit of a mistake) because surely no harm could come to them now that Soviet Union is no more? Right?

Fortunately, for example, Finland had not forgotten the many old, hard learned lessons and maintained national emergency reserves (even when there were voices claiming it all to be a waste of national resources), which has now been opened and medical resources are being redistributed to where they are needed, the first time since the Second World War.

See the problems from afar and they can be dealt with. Take the easy way to political glory and suffer the consequences - along with the rest of the nation. Now, knowing this and with lessons learned from the pandemic, what are we going to do with the impending environmental catastrophe?

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.