In the first part of this series, we have learned about the imminent risks with the IoT / IoE world and that we need to do something about it; introduced the typical C-I-A triple; as well as the concept of “openness.” Now, we continue to add several key points for the secure system design and development concepts:
Secure System | Software Development Life Cycle
For each (new) system, follow the secure coding principles (Input Validation, Output Sanitization, Secure Error Handling, Authentication and Authorization, Secure Session Management, Secure Communication, Secure Resource Management, Secure Storage, Secure Logging, Security Monitoring), use defined and widely accepted standards and don’t re-invent the wheel. You should follow a clear and defined model / framework to ensure that you’re addressing the requirements specification, the development, the implementation, and the testing, etc. all by the proven methodology and follow the process to prevent errors, failure and shortcuts. For the security by design approach, see also my book where I am going into a bit more detail.
Access
Despite all the years and generations of access control cards, there is still a lack of true integration between physical and logical secure access. For the IoT / IoE world, I really would like to see a fully integrated, smart and proactively designed access control system that will allow for one-time authentication with full-time authorization. Example: Let’s assume I have created a mutual trust relationship between my car and my mobile device (I, of course, want this to be as secure as possible). When I have authenticated against my phone, my “car app” should automatically authenticate against the car, and unlock the doors. This integrated two-factor / single-sign-on approach is very user-friendly. The issues with this are the intrinsic risks with a hacker of my phone being able to access my car, too (and vice-versa). So, please have a voice recognition or other biometric factor added before one can start the engine and drive away (for those that argue this is riskier than today – just imagine someone steals / clones your car keys instead of your phone... same issue). My main point here is access shall be integrated and not a hurdle for the (true) owner / user – but make very sure that the control is strong against hacking / misuse. If the mobile device is put on a lost device list (that process must be tamper proof, as well) – then no longer should the trust relationship between the mobile and the car work. It’s similar to a CRL (Certificate Revocation List) with certificates in PKI (Public Key Infrastructure) scenarios.
Authentication
As described with the (car) access example above, it is key to have very strong authentication due to the intrinsic risks of the integrated IoT world. Multifactor authentication should entail at least one of each of the main categories:
- something you know, like a PIN code or complex passphrase;
- something you have, like a mobile device, token, or car with mutually created (authorized) trust relationships;
- something you are, like a voice, iris, hand geometry, and the like (also referred to as “inherence”)
Important is to prevent easy wrong doing / attacks, so that only the authorized owner should be able to create (with a secure process to be followed) the mutual trust relationships (“learning process”). So, I should be able to record / authorize the voice of my partner (etc.), too – and their mobile devices (etc.). However, the owner must be the one who does and authorizes this kind of “trust allowance.” When doing so, a special additional authentication key phrase that is only to be used for this special task should be used before the trust is granted in each entangled device.
Authorization
Since the empowerment of IoE devices will be endless, it is key to have a strong authorization (and authentication, see above) scheme. Therefore, a clearly defined owner (system owner) shall be the one who grants authorizations and trust relationships. Important is to implement the principles of “need to know,” “least privileges,” and “unique IDs.” To stay in the above car example, only the true owner has a need to know the super user PIN (for trust granting / learning process) – that is “need to know.” But when the owner just wants to drive his or her car, s/he shall never be able to use the super user PIN code for that authorization & authentication pair – but instead just the “authorized driver PIN code” – that is “least privileges.” Finally, those IDs are distinct, and also each authorized driver shall have his / her own unique ID to drive the car. One should never need to share the PIN code with another person – that is the “unique IDs” principle. Also, consider the manufacturer and their ability to change / override authorizations… in the wrong hands, there can be a lot of misuse. So, have strong processes, 6-eyes authentication with concatenated keys (so no single person has the full keys / PINs to prevent theft etc.), and strong audits / oversight regime in place for such situations. There may be a need for a “guest” user – there should be zero default PINs for this, not the previously false assumptions or open systems – let’s learn from our mistakes in the past. The guest driver (like a friend who drives you home when you got sick / drunk / etc. or a mechanic from the auto-shop for a repair) should be very limited in use, location and time horizon.
Accounting
It would be a good idea to be held accountable for the actions one takes. So, if these IoT / IoE devices can track and monitor, it could be used for fair usage cost allocation, and to stay in the car analogy above, it should be possible to charge the car usage (like mileage or toll roads) without building those payment booths everywhere. It’s also important to have strong change management controls (think similar to ITIL processes in IT) in place – so whenever parameters are being changed (by the mechanics, the owner, others) this should clearly be accounted for and kept temper-proof.
Non-repudiation
Another important feature for all IoT / IoE devices should be a clearly defined non-repudiation approach that could leverage certificates with private keys, just as they are being used today for digital signatures – it would become an automatic and transparently integrated process that creates a clear track of actions taken. Not only the device’s IP address gets logged and (maybe) monitored, but also enough digitally-proven evidence that non-repudiation of taken actions is accomplished. This could very well include times / time zones, locations, and potentially additional devices that were close by in proximity (for instance in accident cases). It should be clear that what was known previously as a “hit-and-run accident” that won’t work anymore (maybe you can run, but you will get attributed to it). A nice little improvement on physical security and law enforcement. Don’t overplay this, though – a surveillance state regime is not intended, so keep this in balance with privacy requirements (see below). Important is that the processes to create, assign, store, invalidate, renew, etc. of the required certificates must be tamper proof, robust, automated, and transparent (but, of course, accessible and verifiable) for the users. So far, so good. In the next and last part of this little series, we will address the important concepts of privacy, no-dual-use, testing, defaults, and human override and end with an important outlook statement that we must address as a global community to become more secure and safer overall.
About the Author: Michael Oberlaender has a broad, global, diversified background in various industries and markets, 27 years of IT including 17+ years full time security experience, and a strong focus on IT & security strategy. Michael is a globally recognized thought leader, book author (“C(I)SO – And Now What?”), publisher, and has written numerous articles for security magazines, and also has been frequent speaker, panelist and moderator at security conferences. He holds a master of science (physics) from the University of Heidelberg, Germany. He is member of (ISC)², ISACA, ISSA, and InfraGard (FBI).
Michael is currently serving as the Chief Information Security Officer of a larger corporation across the US, Canada and the UK. His expressed statements and opinions are that of his own and do not reflect on any current or prior employer or customer. To find out more about Michael´s book, “C(I)SO – And Now What?”, click here. You can also follow Michael on Twitter here, and connect with him on LinkedIn here. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
