Hardening the IoT development environment, from IDE to Security Keys

Hardening the IoT development environment, from IDE to Security Keys

Introduction; The starting point for this paper is that you are already using best practices, and anti-virus etc.

Military Approach to Information Security. When I served in the Royal Corps of Signals our approach was that the enemy will de-code this, sooner or later. Our AIM was to change our position before the enemy knew where we were. Else they directed fire on to us. It’s similar in civilian life. Just know that the bad guys can de-code anything. Just make sure that whatever they get access to is of zero value by the time they de-code it. That means regular changing of passwords, and other security measures. See next paragraph re Quantum Computing.

Quantum Computing. The emerging “Quantum” computer technology, being developed by IBM, AWS and certain Government Agencies will significantly reduce the amount of time needed to break encryption/security keys.

CPU Instruction Restriction. One of my patented inventions (oops I failed to defend this successfully - never mind the technology is still relevant) it restricts the execution of; individual instructions, or sequences of instructions, or any series of instructions, no matter how they are separated, from executing. This uses hardware breakpoints, and external logic. It can be implemented easily on ARM CPU’s, by access to their I.P. or in other cases, by access to pins on the PCB, where the relevant bus details are available. The ARM solution is more elegant. 

No alt text provided for this image

Application Development

Google Copy/Paste. How often do developers search that big library in the sky called Google? It’s a brilliant resource? It is so easy to copy/paste code, into your new app? You want something working – quickly? They want, and need to meet deadlines, and stage boundaries? What’s faster, and easier than copy/paste? (read on)

IDE Security Plug-Ins. Security at the IDE. There are security plug-ins for most IDE’s, and they cover most languages. If you secure the code as you develop your application, you help to avoid an Ethical Hack/Penetration failure, later.

Ad-Hoc Changes. No matter how small the changes the developer makes (post production), the application should still be processed through the IDE (again), and the security plug-ins given the opportunity to identify any vulnerabilities.

Exception Logging. How are you going to identify security threats? How are you going to identify any attempts at changes? E.g. system admin, attempts to change something? You should identify and log as much as is practical. Set some alerts to high priority, and write a method to raise an alert. 

Safe Mode. Just like a Windows PC, is it worthwhile considering a safe mode for your bespoke application? E.g. if your exception logging identifies anomalies, is it practical to consider changing mode, to one that is more safe?

Security in Work Packages. Agree a set of security tests with your quality team. These should start at the Work Package, and then be repeated in the Specialist Products, i.e. multiple WP’s may be used to deliver a single Specialist Product.

Security at Stage Boundaries. As above, repeat at the stage boundary.

Security at Interlocks or Integrations. An awkward one here? Another team has developed something, and you need to integrate with them? How secure is their application? Are you just going to open your doors to their application? You need to understand what and how they have secured their application. This can totally destroy your security, so, unfortunately you need to invest time, and resources in anything you connect to.

Penetration or Ethical Hack. I would suggest you give them internal access to your network. Let them install network/application monitoring tools. Give them user credentials. This is a fair test, it mirrors what could happen if a user’s credentials are compromised.

Database Choice

Database Design. As part of your overall design, what database architecture do you want? Is that based on “speeds and feeds”, or the skills you have, or your existing database partner’s technology? If your application server, or almost anything in your solution stack is broken, it’s replaceable. But your data is really precious. 

Database Security. I have used (been involved with) SQL, MySQL and MongoDB. Up until recently, I had not done any research on database security. I always “went with” whatever everyone had decided to use. The choice was usually based on available skills, or the existing database vendor.

As a starting point for security, I use the CVE site. It is sponsored by USA Govt Security organizations. I find it easy to use. The CVE website identified 7,861 vulnerabilities for SQL, 799 for MySQL, but only 18 for MongoDB. 

SQL, MySQL Database. On 24th March 2018, I searched the CVE site for SQL, and MySQL vulnerabilities. There are 7,861 vulnerabilities identified with SQL and 799 with MySQL. Far too many for this short paper. 

No alt text provided for this image

This is such a large, and wide area, I suggest you need to ask your database developers to check their database design, against the known vulnerabilities at; https://cve.mitre.org/ 

MongoDB. There are (only) 18 entries with regard to MongoDB.

No alt text provided for this image

IoT/M2M End Points

IDE’s are abstracted too far from the Underlying Platform. Not all IDE’s give you full access to all commands/instructions, that can be used if you directly access the device directly (for example) via a UART connection, using a terminal emulator. What does that mean? It means that your IDE is not showing you everything available, or vulnerable, in that device. 

Note. I have found anomalies (for instance) in that Microchip I.C’s, do not perform as per the manufacturer’s instructions, in terms of pin voltages, and pin states. I found this because I can work at pin level. Your IDE is abstracted several layers away. The IDE would never find these anomalies. However, a hacker does the same as me? They operate at pin level? They know what’s going on. They can hack your IoT/M2M end-point, if they find a vulnerability, that you don’t know about?

Vulnerability Monitoring in Real-Time (in circuit)

No alt text provided for this image


How are you monitoring the security of the end-point, as it interacts with other devices? As you add/change things, how do you know if your end-point is secure or not?


Note. I built a real-time, security monitor, for Microchip RN4870’s. It monitors various pins, and I then constructed a truth table/circuit. Certain pin configurations, show that the I.C. is in a secure, or insecure state. My circuit can raise an alarm, or prevent certain processes being input/output when in an insecure state. I can adapt this for any I.C. 

Locking Access. If you think you have locked the device down, have you disabled remote access? How did you do that? Did you do that, programatically via the IDE? If so, see above, and below.

Note. Google for these examples. I have found instances, where developers cannot regain access to a target environment, after they have secured it. They have not understood how to secure the environment from hackers, without shutting themselves out, from further development work? Other instances of, “inadvertent lock-out” happen because they don’t understand what happens when an end-point is using the UART for data, and they don’t know how to switch it to system admin? Or they set it into “low power” mode, which switches off the UART, and they don’t know how to then communicate with the end-point.

OEM Maintenance Back-Door. Have you downloaded the manufacturers maintenance pack? Install that in a mobile environment, e.g. Android, then also install the Windows version. Then try and find your locked down device. I guarantee, you will find information about your device, that you did not know was available? Note. These OEM maintenance packs, are openly, and freely available, to anyone for download. 

Trusted Platform Module/Embedded Security Element, e.g. TPM 2.0. The professional/industrial IoT/M2M I.C. manufacturers (should) include various types of TPM/eSE options. These should be included into your IoT/M2M end-point design.

Client Devices, e.g. phones, tablets, laptops

Lost/Cloned Devices. Remember clever hackers will clone a “lost device” and then, let it be “recovered”. The hacker will not have connected the cloned device to any network, so you never had the opportunity to remotely wipe it. They will extract all the information they can from that device. Then they will let you find it.

You may think that now that the device has been recovered, and that because it has not been connected to anywhere, that nothing was lost? You should forensically analyse that device. Every name, ID, email address, configuration setting should be treated as compromised. 

Time Bomb. You can set up a time-bomb which is always going to wipe the device back to the factory original settings. This is configured so that if it is not connected to the corporate network, within a pre-configured time, then the device automatically does a factory reset. 

Geofencing. If a device leaves a pre-determined area, as above it can be remotely wiped.

Standard Builds. If possible have standard builds, for each device. It’s not practical to limit people too much, but try and agree a manageable list of devices, in each client device area.

Embedded Security.

Trusted Platform Module. Traditionally included with business grade laptops, tablets, and smartphones. Usually used to store crypto keys, passwords and also used to ensure that the boot process. Only uses approved; hardware, firmware and software. i.e. prevents root-kit viruses. 

Embedded Secure Element. Aimed at smartphones. Does all that the TPM does, but also includes; an operating system, applications, and near field communication modem, all contained in a single “tamper proof I.C.”. Can be an excellent choice for mobile financial transactions.

URI’s, URL’s for Data

Digital Asset Tracking. There are applications that restrict access to data, to a URI/URL. You access the URI/URL, using your credentials. Everything you do with that data is tracked. Even if you forward it to someone else, the document, and anything that is attempted on it, is tracked, and controlled. The data never leaves your secure storage. Obviously, this does not prevent someone writing down data, but it makes it much more difficult to steal it. (at least in large quantities). 

Security Training & Regular Testing

Train your staff, and test them? This needs planning and cooperation with HR, and staff. Here’s one way to make security/phishing/email training more targeted and relevant. Use an email marketing solution to send “phishing type” emails to your staff. Track who opens them, and/or click on items, or url’s. You can then devise a training program, and focus on which staff may need more guidance, compared to others. It’s better that they open your “phishing email”, than a hacker’s?

Counterfeit

Counterfeit Items & Firmware. I wrote a separate paper on this. The summary is as follows; some suppliers source counterfeit products, that include pirated firmware, and/or software. They are far less expensive than those sourced through the manufacturers approved sources. The product usually works. 

Vendors are starting to tighten up on I.P. As an example, when a vendor assists an enterprise with a fault, they encrypt diagnosis reports that they then upload to their “back office”. You have no way of knowing, if as part of their diagnosis they are making an inventory of all items they can identify, which could include add-on cards, drives etc. They can then identify any items installed, that do not appear as being sourced through their approved supply chain.

Vendors have tried manufacturing items with non-standard shapes, so that you can only insert one of their proprietary items. However, it only took days until counterfeit items appeared.

Vendors only way of knowing which items have been sourced through their approved sources, is to cross-reference those with the items recorded, as being delivered by an approved distributor.

To be fair to the vendor, they invest heavily in R&D, and then someone counterfeits their technology, and sells it at a fraction of the price. That destroys the ability for the vendor to recover their investment. 

The logical next step, is for technology firms to tighten up on counterfeit. For instance, one obvious strategy could be to refuse to assist in faults, where counterfeit items are present? How long would it then take to replace all counterfeit items, with correctly sourced ones, and how much would that cause, and how much delay would be involved in rectifying a fault?

One way to identify counterfeit items is to seek the manufacturer’s support in the form of an audit. Once identified you should make a plan to replace all counterfeit items. If possible, you may be able to identify where these counterfeit items were sourced from. If you are lucky, then only one IT reseller has been supplying counterfeit parts. 

Moving forwards, one option is to insist that only cards, drives, etc, are sourced 100% through the vendor’s approved sources. 

Counterfeit Items & Ransomware. It’s only a matter of time, until counterfeit; cards, drives etc, include Ransomware within the Pirated Firmware/Software. Imagine what would happen if your servers, or storage included counterfeit items, complete with ransomware, installed directly inside your datacenter?

Seek the vendor’s help, do an audit now, or consider what would happen if Ransomware took control of your SAN? How useful would the past six months of back-ups be, regardless of where they are now? If the hacker requires that you use his security key to unlock your data, or your backups? 

System Administrators

Separation of Duties. List out everything that you need a system administrator to do. Then separate tasks, so that, for instance a system administrator cannot both create a user, or process, and also enable it? If possible use system administrators who work in different locations, to work together, e.g. John in London creates something, and Ahmed, in Egypt, then enables it.

Logging. Part of any new product acceptance, should be; “what is reported”, “is that logged” and so on. It’s pointless having a security process in place, if a system administrator can do things that are not logged? 

Old Scripts. Repeating myself here, but you should run 24/365 reviews, to see what scripts are run? Are they running on recognized schedulers, or are they bespoke scripts? Identify them. Audit them. Consider switching them off?

Feedback is welcomed - honest - always learning

Please message me through linkedin or use my email [email protected]

Note. If you don't correct me, it will take me longer to learn. Or put another way, help me to get better, by giving me some advice. Thanks, Mike


要查看或添加评论,请登录

Mike McKean的更多文章

社区洞察

其他会员也浏览了