Monday, November 5, 2018

Why Do I Write...

Recently, I was presented with a question: Why Do I Write? As a writer, I thought I would share my response.

Words offer the means to meaning, 

and for those who will listen, 
the enunciation of truth. 

- V, V For Vendetta

Everyone writes for the same reason – to communicate a thought, feeling or idea. It can be as simple as a text message, as complicated as a technical whitepaper or as elegant as Shakespearean verse. Yet all are used to communicate. Why do I write? At the most basic level, I write to communicate, and because I generally have things to say.
  • Writing is hard: Using the written word to express an idea is a difficult task. There is an aptitude for it, and it takes a certain amount of skill to convey an idea or emotion. I have never underestimated the skill of writing – it certainly does not come easy to most, and has not always come easy to me. You can always tell the skill level of a writer – how engaging it is, how it includes the reader, how it expresses the idea. None of these things are easy, but the best writers seem to have a way of producing words so that they flow onto the paper, and equally flow to the mind of the reader. 
  • Writing is challenging: Using words to express an emotion or to deliver a message is a challenge. It is a particular challenge that I enjoy, as it can be a powerful method of self-expression. Finding the right tone, finding the right words, narrowing your audience, and crafting a dialogue between the writer and the audience is as difficult as it is rewarding. I think we can all remember a time when we read something – maybe as simple as an article in the news – that was particularly moving or pertinent. Those that can accept the challenge of using words to communicate have a power that no one can take from them.
  • Writing is powerful: So many in the world do not have a voice. It is not because they do not have ideas, or have opinions to share. But they do not have a way to communicate those ideas in a way that is meaningful. I write because it is an outlet for me to express my thoughts and ideas, and – even occasionally – my emotions. I personally enjoy public speaking as well, but it is difficult to find an audience that is constantly available. Whereas writing is always – always available, always refreshing, always influencing. It becomes part of the record, regardless of how insignificant it may seem. Writing allows me to create a historical legacy.
I am privileged to have a profession where writing is an integrated part of the role. I spend hours every week sharing my thoughts about the latest in technical innovations, using words to describe the qualities or value of a particular technical solution. I get to shape my messages to specific audiences. And I know that my writing has an impact – literally tens of thousands of people read my written words every month.

Simply, I write because it is an extension of my abilities, my intellect and my soul.

Friday, January 12, 2018

CyberSecurity Predictions for 2018: Threat Analytic Services On-Demand Has Arrived

Happy New Year! 

I recently penned a piece for general distribution about cybersecurity predictions for 2018, this one on threat analytics.  the folks at Verdict (as well as several other media outlets) picked it up and published it.

You can find the original post here.

Move Over Netflix:
Threat Analytic Services On-Demand Has Arrived 

We are a world at war – and most people don’t even know it. It is not a traditional war with bombers, battleships and bazookas. Rather, it is being fought everyday by cyber soldiers, protecting governments and organisations from state-sponsored hackers and organised crime.

Unfortunately, most private enterprises and organisations do not have the resources to effectively combat coordinated cyberattacks – it isn’t their core business and information security resources are expensive and hard to come by.  But the picture isn’t as bleak as it sounds.

2018 will see cybersecurity-related services dramatically increase, especially around threat analytics. In the past, only the largest companies could afford to invest in the procurement, management and maintenance of threat analytics services (TAS), but now they are becoming readily available to customers on demand for whatever purpose needed. Maybe it’s a point-in-time situation, like incident response or strategic advisory to evaluate existing infrastructure, determine regulatory compliance, or confirm the veracity of a particular security architecture.

Cyberattacks will continue to increase. But organisations are no longer defenceless in the fight. TAS are not just for the big boys any more – every size company can take advantage of on-demand specialised services to improve their overall cybersecurity.

Monday, December 11, 2017

Podcast with RackN on Cloud Security...

Recently, I created podcast with the folks at RackN on cloud security, GDPR and a whole list of other cybersecurity related topics.  Rob Hirschfeld and Stephen Spector are part of the leadership at RackN and experts at data center automation. 

From the RackN website:

RackN allows Enterprises to quickly transform their current physical data centers from basic workflows to cloud-like integrated processes.  We turned decades of infrastructure experience into data center provisioning software so simple it only takes 5 minutes to install and provides a progressive path to full autonomy.  Our critical insight was to deliver automation in a layered way that allows operations teams to quickly adopt the platform into their current processes and incrementally add autonomous and self-service features.
You can find the podcast here:

Tuesday, November 21, 2017

Good Bye Meg Whitman...

Nothing to see here - just a green rectangle
In a move that should surprise no one, Meg Whitman is resigning as the CEO of Hewlett Packard Enterprise (HPE). You can find the official HPE press release here.

I know MANY in the tech industry that will not be sad to see her leave as the head of what's left of HPE. When HP announced the split of the company into two different technology companies, I was optimistic: The old HP (dubbed HP, Inc) was going to have a more consumer focus, while the newly formed HPE was to have a business focus, selling services, consulting and the servers that would fuel the constantly growing cloud market.

Seems reasonable on paper. But the devil is in the details...

While HP, Inc seems to have a steady compass - innovating new technologies and improving their consumer hardware - HPE never had a solid direction. As a former HPE employee, I was excited about the "more agile" company, one that was able to "meet the rapidly changing demands and directions" of the technology market. Yet, this never came to be.

There were the initial cuts, and then the spinoffs, and then some more cuts, and some more spinoffs. I left HPE in the midst of one of these employee cuts, luckily landing at the company I am currently at. EVERY SINGLE PERSON I worked with at HPE has left the company - either by choice or by layoff.   The innovators, the technology leaders, the people who are literally the world's experts in some of the hottest tech on the market - all gone. 

So, I am not marginally surprised that Meg is leaving. Maybe she accomplished what she set out to do - the elimination of so many employees, real estate, divisions, and products that it makes it easier to chop up and sell whatever is left to some third party in 2018 (yes, I am starting my 2018 prognostications early this year). Hopefully Antonio Neri (who is completely awesome, BTW) can do something to salvage the mess Meg is leaving. 

Good luck to Antonio and best of luck to any of the HPEers that might be left!

And - mainly because I will not have another chance between now and then:


Friday, November 10, 2017

IoT Security: Understanding my Connected Thermostat

Today, I wanted to share a post from a guest author. My friend Jason Garbis (@jasongarbis) created this piece about IoT and your home thermostat. It is a great read and the research is really interesting! I know many folks that are adopting IoT devices in their homes, and likely will not put the level of effort that Jason went through to understand their security. Good news in this case - he did it for you!

I’m a technical guy, and I like understanding how things work. Because I’m employed at a network security company, I’ve been doing a lot of reading and writing about network security, the (in)security of connected devices, and attacks such as the Mirai botnet.

Which brings me to my connected home Thermostat, a Trane model which uses the Nexia home automation platform. I wanted to understand the network model for this device. I can use the Nexia app on my phone to control the thermostat from anywhere, but how does this work? Does my device have an open connection to a service in the cloud? Or is there (shudder) an inbound connection to it?

I’ve been able to answer these questions with some research, but this was harder than it should be, and there’s little hope for less-technical people to be able to figure these kinds of things out for their home automation systems.

So let’s get started!

One note: For privacy purposes, I have redacted my home IP address throughout this document.

The thermostat is on my home wireless network, with an IP address assigned to it from my wireless router:

I performed a quick port scan with two different tools – nmap running on a local machine, and fing running on my phone – and they both showed no open ports on the device. This is a good first result from a security perspective! (Note that I’ve also configured my wireless router to not have any open ports, or to allow any incoming network connections, so even if the thermostat had an open port, it would only have been accessible on the wireless network, and not from the Internet. And yes, UPnP is also disabled on the router!).

Let’s take a look at the device itself – it’s a Trane XL824, which shows up on the network as a Murata Manufacturing device. This device displays a local weather forecast, and is controllable from a smartphone app.

It’s clear that the thermostat is making an outbound connection to a server, and obtaining data such as the weather forecast, and commands such as temperature setting changes from the phone app over this connection [note that while some systems might use a peer-to-peer connection over the local wifi, that’s not how this system operates]. In particular, I’m very interested in understanding the command model, and the security around this. How are changes to my thermostat settings performed? What’s the data flow from the phone app to my thermostat?

My standard-issue home wireless router offers very little in terms of actual network monitoring features. If you dig through the painfully slow admin UI, it does offer a crude security log with a shockingly small capacity of 16KB. This corresponds to only a few seconds of traffic, apparently, before we see:

Fortuitously, in this brief snippet of log I discovered an outbound connection from the thermostat’s private IP address ( out to a remote system, at IP address on port 80.

This IP address is operated by Akamai – it’s not surprising that the Nexia folks, with probably hundreds of thousands of thermostats running 24x7, would make use of a CDN to farm out content to nearby nodes. But, I still have a few questions about this.

Why is it using port 80 rather than 443? A simple port scan shows that the target IP address has both ports 80 and 443 open. Should I be concerned about this traffic being unencrypted?

Trying this IP address in my browser results in a web server error –

So, let’s try HTTPS:

 Aha! Look at the domain associated with the certificate. This is a site providing the weather forecast data to the thermostat. Presumably it makes regular outbound calls to the Akamai-hosted CDN site to obtain this data.

I happened to catch an outbound call to this service in that brief log snippet. I’m guessing that it was preceded by a DNS lookup, which returned this nearby Akamai IP address based on my geolocation. Obtaining weather data over HTTP rather than HTTPS may seem fairly benign, but does introduce a potential vulnerability. A man-in-the-middle or DNS hijacking attack could pretty easily serve up bogus or malformed weather data, and this malformed data could be used to perform an attack and obtain a foothold on the thermostat, for example via a buffer overflow. So I need to give Nexia a small demerit for this. Ideally they’d use HTTPS to preserve the integrity of the data, and also perform a certificate revocation check.

Back to the task at hand, it’s clear that I need more comprehensive logging of my home network. Despite my wireless router’s limitations, it does support the ability to log to a remote system:

I have an old laptop at home on which I’ve installed Linux, so I got this fired up and configured to listen for SYSLOG data coming from the router.

Ok…lots of data to parse. Let’s filter it a bit…

And (reformatted for clarity) a basic pattern emerges:

Looks like the thermostat is calling out to the Weather service every 5 minutes. This pattern is quite regular:
  • Generally the outbound connections are going to either or These are both Akamai IP addresses, so I’m guessing that DNS is returning these as part of a load-balanced set.
  • These calls are all preceded by a DNS call using UDP port 53. The log shows these going first to the router (, which then sends them along to the external DNS server. 
But wait – there’s an odd set of outbound connections going to port 443!

These are not only off-cycle from the other connections, they’re also the only ones going out from the thermostat to port 443.

Based on a reverse DNS lookup, these servers are running in AWS – and map to an EC2 instance and an S3 bucket. These are presumably the control mechanisms for the thermostat.

Let’s see what these services are: has ports 80 and 443 open, so loading this in a browser leads us to…

the Nexia site (properly redirecting to HTTPS).

The other two destinations for port 443 correspond to S3 buckets, which don’t offer a Web interface without authentication, and without permission I’m not going to poke around them in any case.

Just for kicks, let’s do a DNS lookup on the domain:

And there it is, Hosted in AWS and assigned to This is clearly the connection we’ve been looking for! Let’s think about the system behavior for a moment – I can use the Nexia iPhone app to adjust my thermostat, and these changes take place essentially immediately – within ~5 seconds based on my handful of tests.

This implies near-real time communications over an existing network connection, not something that’s polling-based. And because we’ve established that there are no inbound connections to the thermostat, this outbound connection to the Nexia system must be long-lived.

Let’s take a look at the log files to see what else we can discover. We can see several connections outbound to port 443 on the Nexia server.

And looking at a DNS log I set up – I used BIND and configured my router to use my Linux laptop as its DNS server -- we can see the domain resolution request:

Some of these connections are only open for a few seconds – for example the one outbound on port 44318 is opened at 15:57:09, and closed at 15:57:12. But the connection on port 50216 – opened at 15:27:41 – remains open for a long period (beyond the horizon of when I turned off the logging server that day).

This is exactly what we’d expect from the observed behavior! A long-lived outbound connection from the thermostat to the Nexia server, used to communicate commands in near real-time.

Is this secure? Let’s asses – it’s using HTTPS for the connection, which is clearly a good foundation. I can’t tell whether it’s doing any certificate validation on the domain. Doing so would require deploying a firewall and performing HTTPS inspection, which is beyond the scope of this article.

So let’s summarize what we learned here, and assess its security. The thermostat is only making outbound connections, and doesn’t require either an open port or (the horror of) UPnP. It’s making an HTTPS connection to its command & control system, hosted at a recognizable domain. These are all sound security approaches.

My only criticism is that it’s making an unsecured call to a server over HTTP. This is a small but real vulnerability, since it’s subject to an MITM attack that could exploit a buffer overflow of some sort. I’m not terribly worried about upstream attackers at the ISP, but someone could create a rogue wireless access point and capture the outbound calls to the weather forecast server. Or in theory hijack my DNS, redirect the thermostat to a bogus weather forecast server, and deliver malformed data. Again – these are real but unlikely attacks.

Overall, I’m satisfied with the security of this device. I learned a lot doing this research, and I hope that you’ve found this writeup useful. Let me know what you think – I’m reachable on Twitter @JasonGarbis