“Smart” Doesn’t Mean “Secure”

Prior to 1975, there was no such thing as a smart home. Prior to 1985, all radio systems were analog. Prior to 1990, all phone systems were analog. Prior to 1974, all utility metering was analog. But all of that has changed; we now live in a digital world. 1’s and 0’s “run” our lives, and picking up an analog landline phone (POTS) is virtually a thing of the past. The new “hotness” is smart everything. Smart cars, smart phones, smart TVs, smart homes, and now smart grids.

When considering automotive IoT, it’s logical to focus on the supply chain that makes the car possible. In reviewing the application of key management to the automotive IoT landscape, it becomes apparent that the provenance of car components, from tires to telematics, is absolutely critical. Any poorly-built component can cause a systemic failure of the vehicle delivered to the consumer. When one typically thinks of applying encryption, it is focused on protecting the confidentiality of data at rest, in motion, or even while being processed. However, what about measuring whether the data should be trusted instead how whether it needs to be protected?

Starting in late December, the Linux kernel development lists started buzzing about some commits going into the kernel without the usual documentation that adjoins such code changes. When an AMD developer added some code on December 26^th with the following comment, security researchers started zeroing in on the problem:

How Auto Makers Are Working to Secure Connected Cars

Last week, I attended the inaugural Auto-ISAC summit. "ISAC" stands for Information Sharing and Analysis Center. There are several long-standing ISACs for other industries including aviation, electricity, natural gas, and financial services. You can find the full list here if you are curious.

In a digital world, everything is a 1 or a 0. Those 1’s and 0’s can range from the lifeblood of an organization down to a simple message from one person to another. In most cases, those 1’s and 0’s can be jostled around: enter encryption. Tight encryption standards can make even the most significant, sensitive data appear to be indecipherable to the naked eye. Multiple firewalls, strong antivirus software, enterprise-wide encryption… these are all techniques utilized to strengthen our security posture to prevent bad actors from accessing sensitive data. Bolstering a strong perimeter security defense, coupled with constantly rotating encryption keys inside and outside of the perimeter, and always having the latest antivirus definitions will lead to a stronger aggregate security posture.

Thank you to Cyphre for contributing this guest post to our blog as we focus on GDPR compliance!

Now that European Union’s General Data Protection Regulation (GDPR) is set to become law, companies must establish policies and technology controls to securely store and transfer personal data of any person residing in the EU. Data that can be used to identify a person, such as physical address, IP address, and more, as well as genetic data, information about religious and political views, sexual orientation, and more must be encrypted or made anonymous. Individuals have the right to erase their personal data by withdrawing consent or when it is no longer being used for its original purpose.

Back in June, Kevin Mooney wrote an excellent piece on The Strong Case for Interoperability. Getting back to that subject matter, in perhaps not the most ideal of circumstances, we are going to talk about standards, interoperability, and transition as it pertains to resolving systemic issues. This is being driven by faults in 802.11 as described in Mathy Vanhoef’s and Frank Piessens’ paper on key reinstallation attacks released today.

In April 2016, the General Data Protection Regulation was signed into law by the European Parliament and was enforceable as of May 25^th 2018. This EU regulation lays out a wide number of policies that require businesses to protect personal data. Companies must have policies and technology controls to securely store or transfer personal data of any person residing in the EU. The way the various articles of the regulation read, this means at a minimum that data needs to be encrypted or made anonymous.

Adobe's Product Security Incident Response Team (PSIRT) accidentally posted their private key to the internet allowing anyone with access to either side of a conversation with the PSIRT to be able to decrypt the messages.  The Adobe security team was quick to revoke the PGP key, but it has left people with encrypted messages to Adobe in the clear.  How did it happen?

Equifax made news recently for being the victim of a hack; their systems were compromised and data was accessed by person(s) that weren’t authorized to have it. Unfortunately, this is not an uncommon occurrence these days. Hacks happen all the time, to companies both large and small. Individual hacks aren’t really noteworthy any more. But what is particularly noteworthy about this incident is the data that was accessed: the personal (and supposed-to-be private) information of roughly half of the US population.