techponder

IoT (Internet of Things) devices have – and in many cases have earned! – a rather poor reputation for security. It is easy to find numerous examples of security issues in various IoT gateways and devices.

So I was expecting the worst when I had the opportunity to talk to a number of IoT vendors and to attend the IoT Day at EclipseCon. Instead, I was pleasantly surprised to discover that considerable attention is being paid to security!

• Frameworks, infrastructure, and lessons from the mobile phone space are being applied to IoT. The mobile environment isn’t perfect, but has made considerable progress over the last few years. This is actually a pretty good starting point.
• Code signing is being emphasized. This means that the vendor has purchased a code signing certificate from a known Certificate Authority and used it to sign their application. This ensures that the code has not been corrupted or tampered with and provides some assurance that it is coming from a known source. Not an absolute guarantee, as the Certificate Authorities aren’t perfect, but a good step.
• Certificate based identity management, based on X.509 certificates, is increasingly popular. This provides a strong mechanism to identify systems and encrypt their communications.
• Oauth based authentication and authorization is becoming more widely used.
• Encrypted communications are strongly recommended. The Internet of Things should run on https!
• Encrypted storage is recommended.

Julian Vermillard of Sierra Wireless gave a presentation at EclipseCon on 5 Elements of IoT Security. His points included:

• Secure your hardware. Use secure storage and secure communications. Firmware and application updates should be signed.
• “You can’t secure what you can’t update.”
  • Upgrades must be absolutely bulletproof – you can never “brick” a device!
  • Need rollback capabilities for all updates. An update may fail for many reasons, and you may need to revert to an earlier version of the code. For example, an update might not work with other software in your system.
• Secure your communications
  • Recommends using Perfect Forward Secrecy.
  • Use public key cryptography:
    • X.509 certificates (see above discussions on X.509). Make sure you address certificate revocation.
    • Pre-Shared Keys. This is often easier to implement but weaker than a full Public Key X.509 infrastructure.
    • Whatever approach you take, make sure you can handle regular secret rotation or key rotation.
  • For low end devices look at TLS Minimal. I’m not familiar with this; it appears to be an IETF Draft.

Julian also recommended keeping server security in mind – the security of the backend service the IoT device or gateway is talking to is as important as device level security!

The challenge now is to get actual IoT manufacturers and software developers to build robust security into their devices. For industrial devices, where there is a high cost for security failures, we may be able to do this.

For consumer IoT devices you will have to vote with your wallet. If secure IoT devices sell better than insecure ones, manufacturers will provide security. If cost and time to market are everything, we will get insecure devices.

Perhaps the greatest question about Superfish is what can we do about it. The first response is to throw technology at it.

The challenge here is that the technology used by Superfish has legitimate uses:

• The core Superfish application is interesting – using image analysis to deconstruct a product image and search for similar products is actually quite ingenious! I have no reservations about this if it is an application a user consciously selects and installs and deliberately uses.
• Changing the html data returned by a web site has many uses – for example, ad blocking and script blocking tools change the web site. Even deleting tracking cookies can be considered changing the web site! Having said that, changing the contents of a web site is a very slippery slope. And I have real problems with inserting ads in a web site or changing the content of the web site without making it extremely clear this is occurring.
• Reading the data being exchanged with other sites is needed for firewalls and other security products.
• Creating your own certificates is a part of many applications. However, I can’t think of many cases where it is appropriate to install a root certificate – this is powerful and dangerous.
• Even decrypting and re-encrypting web traffic has its place in proxies, especially in corporate environments.

The real problem with Superfish is how the combination of things comes together and is used. And quality of implementation – many reports indicate poor implementation practices, such as a single insecure password for the entire root certificate infrastructure. It doesn’t matter what encryption algorithm you are using if your master password is the name of your company!

Attempting a straight technology fix will lead to “throwing the baby out with the bath water” for several valuable technologies. And a technical fix for this specific case won’t stop the next one.

The underlying issue is how these technologies are implemented and used. Attempting to fix this through technology is doomed to failure and will likely make things worse.

Yes, there is a place for technology improvements. We should be using dnssec to make sure dns information is valid. Stronger ways of validating certificate authenticity would be valuable – someone suggested DANE in one of the comments. DANE involves including the SSL certificate in the dns records for a domain. In combination with dnssec it gives you higher confidence that you are talking to the site you think you are, using the right SSL certificate. The issue here is that it requires companies to include this information in their dns records.

The underlying questions involve trust and law as well as technology. To function, you need to be able to trust people – in this case Lenovo – to do the right thing. It is clear that many people feel that Lenovo has violated their trust. It is appropriate to hold Lenovo responsible for this.

The other avenue is legal. We have laws regulate behavior and to hold people and companies responsible for their actions. Violating these regulations, regardless of the technology used, can and should be addressed through the legal system.

At the end of the day, the key issues are trust, transparency, choice, and following the law. When someone violates these they should expect to be held accountable and to pay a price in the market.

Superfish has been getting a lot of attention – the Forbes article is one of the better overviews.

Instead of jumping in and covering the details of Superfish, let’s look at how it might work in the real world.

Let’s say that you are looking for a watch and you visit Fred’s Fine Watches. Every time you want to look at a watch, someone grabs the key to the cabinet from Fred, uses a magic key creator to create a new key, opens the cabinet, grabs the watch from Fred, studies the watch, looks for “similar” watches, and jams advertising fliers for these other watches in your face – right in the middle of Fred’s Fine Watches! Even worse, they leave the key in the lock, raising the possibility that others could use it. Further, if you decide to buy a watch from Fred, they grab your credit card, read it, and then hand it to Fred.

After leaving Fred’s Fine Watches you visit your bank. You stop by your doctor’s office. You visit the DMV for a drivers license renewal. And, since this article is written in February, you visit your accountant about taxes. Someone now has all this information. They claim they aren’t doing anything with it, but there is no particular reason to trust them.

How does all this work? Superfish is a man-in-the-middle attack that destroys the protection offered by SSL (Secure Sockets Layer). It consists of three basic components: the Superfish adware program, a new SSL Root Certificate inserted into the Windows Certificate Store, and a Certificate Authority program that can issue new certificates.

SSL serves two purposes: encryption and authentication. SSL works by using a certificate that includes a public encryption key that is used to negotiate a unique encryption key for each session. This encryption key is then use to uniquely encrypt all traffic for that session. There are two types of SSL certificates: public and private.

Public certificates are signed. This means that they can be verified by your browser as having been created from another certificate – you have at least some assurance of where the certificate came from. That certificate can then be verified as having been created from another certificate. This can continue indefinitely until you reach the top of the certificate tree, where you have a master or root certificate. These root certificates can’t be directly verified and must be trusted.

Root certificates are connected to Internet domains. For example, Google has the google.com root certificate, and is the only one who can create a signed certificate for mail.google.com, maps.google.com, etc.

Bills Browser Certificates, Inc., can only create signed certificates for billsbrowsercertificates.com. The details are a bit more complex, but this is the general idea – signed certificates can be traced back to a root certificate. If the owner of that root certificate is cautious, you can have a reasonable level of trust that the certificate is what it claims to be.

Your browser or OS comes with a (relatively small) list of root certificates that are considered trusted. Considerable effort goes into managing these root certificates and ensuring that they are good. Creation of new signed certificates based on these root certificates is tightly controlled by whoever owns the root certificate.

Certificate signing is a rather advanced topic. Let’s summarize it by saying that the mathematics behind certificate signing is sound, that implementations may be strong or weak, and that there are ways of over-riding the implementations.

Private certificates are unsigned. They are the same as public certificates, work in exactly the same way, but can’t be verified like public certificates can. Private certificates are widely used and are a vital part of communications infrastructure.

According to reports, Lenovo added a new Superfish root certificate to the Microsoft Certificate Store on certain systems. This means that Superfish is trusted by the system. Since Superfish created this certificate, they had all the information that they needed to create new signed certificates. Which they did by including a certificate authority program which creates new certificates signed by the Superfish root certificate – on your system while you are browsing. These certificates are completely normal, and there is nothing unusual about them – except the way they were created.

Again, according to reports, Superfish hijacked web sessions. Marc Rogers shows an example where Superfish has created a new SSL certificate for Bank of America. The way it works is that Superfish uses this certificate to communicate with the browser and the user. The user sees an https connection to Bank of America, with no warnings – there is, in fact, a secure encrypted session in place. Unfortunately, this connection is to Superfish. Superfish then uses the real Bank of America SSL certificate to communicate with Bank of America. This is a perfectly normal session, and BOA has no idea that anything is going on.

To recap, the user enters their bank id and password to login to the BOA site. This information is encrypted – and sent to Superfish. Superfish decrypts the information and then re-encypts it to send to BOA using the real BOA SSL certificate. Going the other way, Superfish receives information from BOA, decrypts it, reads it, re-encrypts it with the Superfish BOA certificate, and sends it back to you.

Superfish apparently creates a new SSL certificate for each site you visit. The only reason that all this works is that they were able to add a new root certificate to the certificate store – without this master certificate in the trusted certificate store they would not be able to create new trusted certificates.

Superfish can also change the web page you receive – this is the real purpose of of Superfish. In normal operation Superfish will modify the web page coming back from the web site you are visiting by inserting new ads. Think about it – you have no idea of what the original web site sent, only what Superfish has decided to show you!

Superfish is sitting in the middle of all your web sessions. It reads everything you send, sends arbitrary information to an external server (necessary for the image analysis it claims to perform, but can be used for anything), forges encryption, and changes the results you get back.

The real threat of Superfish is that it contains multiple attack vectors and, by virtue of the root certificate, has been granted high privileges. Further, the private key Superfish is using for their root certificate has been discovered, meaning that other third parties can create new signed certificates using the Superfish root certificate. There is no way to do secure browsing on a system with Superfish installed. And no way to trust the results of any browsing you do, secure or not.

The previous article introduced SCAP technologies.

While the SCAP technologies are interesting, they have limited value without security content – the actual set of security tests run by SCAP. Fortunately there is a good set of content available that can be used as a starting point.

The US Government has released a set of SCAP content that covers the baseline security required – the United States Government Configuration Baseline (USGCB), which contains the security configuration baselines for a variety of computer products which are widely deployed across federal agencies. USGCB content covers Internet Explorer, Windows, and Red Hat Enterprise Linux Desktop 5.

Also from the US Government is the Department of Defense STIG or Security Technical Implementation Guides. A specific example of this would be downloadable SCAP Content for RHEL 6, the Red Hat 6 STIG Benchmark, Version 1, Release 4.

A number of vendors include SCAP content in their products. This is often a sample or an example – it is enough to get you started, but does not provide a comprehensive security scan.

While the available SCAP content is a good start, most organizations will have additional needs. This can be addressed in two ways: by tailoring existing SCAP content and by writing new SCAP content.

Tailoring SCAP content involves choosing which SCAP rules will be evaluated and changing parameters.

An example of changing parameters is minimum password length. The default value might be 12 characters. You can change this in a tailoring file, perhaps to 8 characters or to 16 characters for a highly secure environment.

A common way to use SCAP is to have a large SCAP benchmark (content) which is used on all systems, and to select which rules will be used for each scan. This can be changed for each system and each run. You do this by providing the SCAP benchmark, an SCAP Tailoring file, and running the SCAP scanner.

Writing new SCAP content can be a daunting task. SCAP is a rich enterprise framework – in other words, it is complex and convoluted… If you are going to be writing SCAP content (and you really should), I suggest starting with Security Automation Essentials, getting very familiar with the various websites we’ve mentioned, studying the existing SCAP content, and being prepared for a significant learning curve.

Next: Running SCAP Scans

The previous article introduced the concept of security guides as executable content and introduced SCAP.

We’re going to dig into SCAP in a fair amount of detail. So, let’s start by covering the various technologies that make up SCAP:

• XCCDF – the Extensible Configuration Checklist Description Format. An XML based language for creating machine parsable security checklists.
• OVAL – the Open Vulnerability and Assessment Language. Standardizes how to assess and report on the machine state of computer systems.
• OCIL – the Open Checklist Interactive Language. Ask users questions. For example, “do you know who to report security breaches to?” and allowing the user to respond with yes or no – or perhaps the name and contact information of where to report security breaches.
• CCE – Common Configuration and Enumeration. Uniquely identify configuration characteristics. For example, how do you identify minimum password length across Windows, Unix, Linux and Mac?
• CPE – Common Platform Enumeration. A structured naming scheme for IT systems, software and packaging.
• CVE – Common Vulnerability Enumeration. A standard way to uniquely identify computer vulnerabilities, for example HeartBleed – CVE-2014-0160.
• CEE – Common Event Expression. A common way to record events – i.e. a standard logging format.
• CRE – Common Remediation Enumeration. Describes how to remediate or mitigate security vulnerabilities.
• CVSS – Common Vulnerability Scoring System. A consistent methodology for measuring and quantifying the impact and risk of vulnerabilities identified through CVE.

Some of these are widely used. For example, the CVE Database maintained by Mitre is the common resource used for sharing information on security vulnerabilities. It has been used by security professionals around the world for over 15 years.

Others are new, such as the use of XCCDF and OVAL to create standardized security content that can be shared across organizations and industries and be used by automated scanners.

Next: Security Tests – SCAP Content

The last article introduced the US National Checklist Program.

Security automation can be defined as the use of standardized specifications and protocols to perform specific common security functions.

Which leads us to SCAP – the Security Content Automation Protocol, an industry and government initiative to automate security audits and compliance.

The basic concept of SCAP is that security guides should be executable content, not paper documents. You should be able to define your security requirements (or security content) in a form that can be run on a computer with no human intervention, and which produces an audit report that can be understood by both computers and people. You should be able to run these reports – effectively, to perform a complete security audit on a system – as frequently as you want.

Further, these security guides should be dynamic, extensible, customizable, and actionable.

• Dynamic – as new security threats are discovered, the threat and how to respond to the threat should be added to the security guide.
• Extensible – you should be able to get security content from multiple sources, as well as create your own specialized security content.
• Customizable – you should be able to choose which security rules apply to which systems. For example, a web server in a DMZ, a database server and a development system will all have different security requirements.
• Actionable – the security guide should not only identify security issues, it should also give you assistance in resolving these security issues. Specifically, it should help you understand what the issue is, what the risk is, and what the exposure is, as well as what steps can be taken to resolve or mitigate it.

And, of course, consistent. You may recall the discussion of password rules from a few posts back. You need to apply the same security rules across Windows, Solaris, AIX, HP-UX, Linux, Mac, and all other computers you have.

For people who want to jump ahead, good resources for SCAP include:

• The NIST SCAP Website. NIST is the lead organization coordinating the development of SCAP.
• Security Automation Essentials by Witte, Cook, Kerr and Shaffer is a book I highly recommend for understanding all of the pieces of SCAP.

Next: SCAP Component Technologies

The last article introduced the need to automate security.

If you are going to perform a security audit you need a checklist.

Let’s spend a minute on this. If you want a predictable outcome, you need a standard process – a standard set of steps to go through to reach that outcome. Basic stuff. But here is the tricky part: people are bad about remembering things and doing things the same way every time. If the results are important, you need a checklist.

Rather than spending a lot of time here, I’m going to hand out a reading assignment: The Checklist Manifesto: How to Get Things Right by Atul Gawande. This is one of the books I strongly recommend everyone should read. Go ahead, I’ll wait until you come back.

OK, welcome back.

Let’s take a look at applying checklists to security. The first suggestion I will make is don’t write checklists from scratch. Find one that is close to what you need and modify it. It takes several iterations and considerable experience to develop a solid process that works – the more you can build on other peoples experience, the less work you have to do. And the better your chances of getting it right!

A good resource for checklists on computer security is the US National Checklist Program. This is a repository of publicly available security checklists to provide detailed guidance on setting the security configuration of operating systems and applications.

Let’s start out with a written checklist – how about the HPLaserJet 4345 MFP Security Checklist. This is a 49 page document detailing how to secure a printer. Yes, a printer. Modern printers are actually servers with a print engine hanging off the side. They can be a major security risk. They have an internal disk drive that stores the documents being printed. Did you securely remove classified documents from the last printer you got rid of?

The document covers threat models, network security, printer settings, and ramifications of the various settings. It includes many screenshots of how to use the Web-based management interface to access and change the many settings.

The good news is that this security guide exists. The bad news is that it is a time consuming manual process to apply it. Speaking of which – who configured your printer when it was installed six years ago? Did they do it right? What has happened in the intervening time? Did someone disable security on the printer so that they could get their job done?

It looks like it is time to print out the security guide and start pointing your browser at all the printers in your organization!

There has got to be a better way to do this. And no, ignoring security until you show up on the front page of the newspaper or in front of a congressional committee isn’t a better way!…

Next: Security Audit Automation Made Easy with SCAP