Don't Wait Until It's Too Late: How to Build Security into IoT Apps from the Beginning
Jane Porter
As we continue building cybersecurity into IoT deployments, the next area we want to consider are the challenges of creating your own applications. Let’s consider the approach most of us take when creating an application. The excitement of developing new applications that can address a customer’s problem is very motivating in the design process. Typically, the first items a developer will focus on are those related to the user experience:
- What is the purpose of the application? What will we allow the user to accomplish?
- What are the key functionalities for the application?
- Where is the application going to be run—on a PC or a mobile device? What does this mean for the architecture?
- How should the UI be designed? What can make it simpler and more intuitive?
These are all important, but do you see what’s missing? Security concerns need to be considered from the beginning of the development process. Incorporating cybersecurity into the Design, Develop & Test, and Maintenance phases of application development will make product lifecycle management much easier.
Design
As you start to design your application, think about the potential threats associated with your application. For instance:
How sensitive is the information shared within the application?
You may be providing some very generic information and interaction—you may decide in this instance that security is of no concern and can allow anonymous access to the app and the data. Job done, you can now move on to the sparkly bit of designing the UI and the behaviour. But if it is more sensitive, then you need to give it some more thought.
Standard authentication and authorization
If some of the information you are providing requires some level of interaction that should be kept private, you will need to have a degree of authentication. A typical example of this are music streaming platforms; you can access and use the platform anonymously but if you want to get rid of the adverts and build content for off-line playing you have to log in. You also provide payment details which you most definitely do not want to be shared with the general public.
For this approach you will want to use standard authentication and authorization techniques as discussed in our previous blogs on these subjects. The important thing to keep in mind is that even though you only need parts of the application to be secure, that security needs to be taken seriously. A typical error in this area is where users can erroneously gain access to data from unauthenticated areas of the app—this is where the design has not correctly componentised the secure areas.
Highly regulated industries
When you are providing access to and interaction with highly confidential information, such as a mobile banking app, you will need to provide the highest level of security it is currently possible to utilize. In this instance your organisation is likely to have detailed guidelines on what your app needs to meet, a good example of this is the Security Technical Implementation Guide (STIG). This type of guide can be very long and very difficult to understand when you first read it. Our suggestion is that you seek out somebody in your organisation who has already written an app using the guidelines and who can provide you with some ideas on the security controls you need to design into your application to meet the security requirements. An example is the standard banking app that uses adaptive authentication to correctly identify the user.
Development & Test
Let’s start with standard guidelines—I hear you groan but once you have used them a couple of times much of this will become second nature. Depending on the language you are using there will be different guidelines. A good initial guide comes from the OWASP Foundation Secure Coding Practices Guide and is linked below1. It will at least help point you in the right direction on what you need to be thinking of as you write your code.
Now you need to decide how much you want to focus on security testing. As with all other decisions this will depend on how security conscious you need to be for your particular application. For instance, if you have made the decision not to worry about security you can pretty much ignore this section. However, you might like to double check that an application with little security does not allow a user access to more secure areas of your application infrastructure by accident.
Having written your code thinking of security from the start and using some guidelines to make it as secure as possible the next step is to conduct Static Application Security Testing, or for most of us referred to as source code scanning. Depending on the size of the application this might be a component or the entire application. The scan should be run over the source tree that includes all libraries, that is your code as well as the 3rd party libraries. There are a number of well-known source code scanners ranging from open source to commercial offerings. Irrespective of which one you choose, for the source code the output will be a list of ‘findings’ which will highlight the severity and location of security vulnerabilities; these are scored from critical through to low. For the 3rd party libraries, you will get a common vulnerabilities and exposures list for any library with a vulnerability, the CVE list has a numeric scoring from 1 to 10 with 10 being critical, this is called the CVSS system.
It is up to you on how many of these highlighted vulnerabilities you choose to mitigate, but we would suggest that as a minimum you address the critical and high severity for your own source code and get updated libraries for any with a CVSS of 7 to 10.
Having run the scans over the source code we now want to do some dynamic application security testing. This is done on the compiled, built, and deployed application and will provide you with another list of vulnerabilities that can be exploited. The major difference between this and the source code scanning is that the dynamic application security testing will include the configuration and other components included in the runtime environment. This should be done for all applications, irrespective of the decision you have made for an individual application as discussed above.
Last, but not least, you will want to run a penetration test to ensure that you have not missed anything. This can be as low key as a colleague trying to get past your security defences or in the case of major IoT platforms hiring a 3rd party organisation who specialize in this type of ethical hacking. A good starting point for penetration testing is to use this web site, OWASP Top Ten | OWASP Foundation. They keep the site up to date with the latest known vulnerabilities, attack patterns and other useful information.
Maintenance & Support
As we all know, security is always evolving in reaction to the n’er do wells continually trying to find new ways of getting access to data they should not have. This means we must always assume that our applications need to be constantly looked after; you cannot deploy and forget. Again, depending on the size of the owning organisation (after all it may be just one person) you need to ensure that on a regular basis you check the following:
- Check your 3rd party libraries and keep them up to date
- The environment for running the application is kept up to date with patches and latest versions
Larger organizations will have a team, or more, that look after this and will also have processes in place as part of their audit compliance for standards such as ISO 27001 and/or SOC2.