If your product fits neatly into a magical chart comprised of 4 equal areas made by dividing a plane by an x and y axis, odds are it is commoditized and indistinguishable from the vendors beside you. As a result to drive differentiation, organizations are beginning to form their own research groups as a vehicle to establish thought leadership, create sales opportunities, and, of course, differentiate the company and its products from the competition.

I’ve worked as a vendor, an industry analyst, and as an end consumer of security products. I’ve seen my share of commoditized products artificially inflated with buzzwords and the latest security breach news in the press. I’ve also sat through more than a few presentations (or panels) where the presenter communicates how hard they thought about a particular problem – and that is the extent of their research.

What continues to impress me, however, is when a vendor (or a presenter writing/speaking on behalf of a vendor) can provide concrete data to reinforce a hypothesis or position on a particular issue or problem. I don’t care how creative you are with your marketing language or how hard you think about a particular problem, it’s not going to mitigate or prevent the problem from reoccurring – unless, of course, you’re Michael Ironside’s character from the movie Scanners.

Types of Research

In the security field, there are really two types of research: Pure and Applied. According to Wikipedia(http://en.wikipedia.org) pure (sometimes called basic) science is the “development and establishment of information to aid understanding of the world, whereas applied science uses portions of basic science to develop technology or technique establishing interventions to alter events or outcomes as desired.” (source – http://en.wikipedia.org/wiki/Basic_science#Versus_applied_science)

Applied science, on the other hand, is a “discipline of science that applies existing scientific knowledge to develop more practical applications, such as technology or inventions.” (source – http://en.wikipedia.org/wiki/Applied_science)

As an alternative, I offer the following differentiation:

• If the purpose of your research is to convey thought leadership, interesting and qualitative takes on previously identified problems, or states your position on one side or the other of an ongoing debate; you’re probably conducting (and conveying) pure research.
• If your research provides a tool or methodology that addresses an industry or community need, provides quantitative data proving a hypothesis, or, once implemented, shows a differentiation of your product; you’re probably conducting (and conveying) applied research.

Now, before people get upset, I’m not saying that pure research isn’t valuable, it is. Without pure research, there would be no applied research. Big ideas influence those who can execute and turn the pure research into applied research.

In my opinion, a vendor should have a research group that operates on a 30/70 split of pure to applied research. This lets researchers be creative and express themselves with a greater emphasis of implementing quantifiable research into portfolio features, tools, or products.

Stay Tuned…

As this series evolves I’ll touch on how to structure your research group, how to staff, how to create a business case to justify its existence, and how marketing, sales, and product teams can utilize the findings of your team. If you have any questions, please put them in the comments section below or reach out to me on Twitter via @andrewsmhay.

You’ve no doubt heard that Google has announced it is buying Nest Labs, maker of smart thermostats and smoke alarms, for $3.2 billion in cash. In a very well written NYTimes blog post, Quentin Hardy notes that “Nest did all of it on Amazon Web Services.”

Hmm…interesting. This is the first I’ve heard about Nest running in AWS, though I admit that I’ve not really followed the home automation craze that closely. With this new knowledge, I decided to poke around and see what I could find about the AWS-based service.

A quick Google search for nest firewall ports (which is what I commonly append to a product/application term when looking for what ports are used) provided 433,000 results. Phew, that’s a lot.

After looking at several pages, the general consensus from Nest users was that port 9543/tcp needed to be allowed through their respective home routers for the product to work.

So AWS + a port 9543/tcp (for those of you keeping track at home)

One page provided the FQDN that the Nest thermostat connects to: XXXX.transport.nest.com

According to research by a couple of the forum members:

The nest does frequent dns lookups for something in XXXX.transport.nest.com, which currently maps to an amazon EC2 instance. Then it makes a TCP connection to port 9543 which it seems to hold open. This probably is so that when you go to the nest website it’s able to instantly communicate with your thermostat and not have to worry about your firewall. I think the traffic is encrypted, but it looked like a self signed SSL certificate. I didn’t dig any deeper at the time.
…
[N]est communicates with the server over 9543. the web client communicates to the same server on port 9443. I would assume port 9543 is just HTTP traffic. The certificate is self signed. attempts at a man in the middle attack to decrypt the ssl packets haven’t worked for me so far.

If you attempt to goto https://XXXXXXXX.transport.nest.com:9543/ in your browser you’ll be presented with the same cert. after that you will be prompted with an authentication window. I haven’t tried using any of the api’s i’ve sniffed from the web client. however i suspect they are probably very similar.

At this point, I decided I had enough information to go on to start my own research. The first thing I did was use nslookup to see what the transport.nest.com provided:

$ nslookup transport.nest.com
Server: 208.67.222.222
Address: 208.67.222.222#53

Non-authoritative answer:
transport.nest.com canonical name = transport.production.nest.com.
transport.production.nest.com canonical name = transport-service-production-909910888.us-east-1.elb.amazonaws.com.
Name: transport-service-production-909910888.us-east-1.elb.amazonaws.com
Address: 107.20.222.81
Name: transport-service-production-909910888.us-east-1.elb.amazonaws.com
Address: 54.243.109.243

What is most interesting is that Amazon’s Elastic Load Balancing (ELB) is being used, likely to help distribute the load across multiple guest instances.

Using brisket, and Robert Graham’s masscan tool, I started scanning for AWS guest instances with open 9543/tcp ports.

Figure 1 – Subnet to IP Address Mapping for 9543/tcp

We really have no way of knowing if all of the Nest-related guest instances are represented in the above chart. In fact, based on a host query, at least 3 guests have FQDN’s associated with a non-default AWS public DNS name. Another 5 guests, based on returned banners, appear to be running other applications (such as SSH) on non-standard ports.

Since Nest is a widely adopted product, we could guess that the subnets with the highest number of discovered IP-to-port mappings represent the “Nest Cloud” – but that really would be a guess.

Figure 2 – Top 10 Subnets With Discovered Port 9543/tcp

Looking at it another way, the Top 10 count of detected servers look something like this:

Figure 3 – Top 10 Subnets With Counts

It’s probably safe to assume that Nest is using VPC given the number of devices it has claimed to have sold to date (~1 million according to a Forbes post). Unfortunately, without getting the device-to-server count directly from Nest, I doubt we’ll ever really know the final number. It’s also probably safe to assume that the IP addresses employed by Nest are load balanced (using ELB) to the servers within its VPC network.

Photo Credit: dailyamazon via Compfight cc

Our CloudPassage team is growing and I’m looking for 3 interns in the Bay Area to come work with me for a semester to help make our award winning product a bit better. This is an excellent, and paid, opportunity to work with the hottest cloud security startup. Here is what I’m looking for:

Internship #1:
We are looking for a Security Integration Developer intern who loves to build tools to enhance our award-winning Halo product. Our product is not only known for its depth of security technology but also for its comprehensive breadth of capabilities that include software vulnerability reporting, software configuration management, file integrity monitoring, server access and dynamic host-based firewall management — each specifically built for cloud computing. The intern would be responsible for developing tools and scripts to help our customers integrate with our flagship product, Halo, build custom tools to help win sales opportunities, and internal tools to automate security policy content creation.

Internship #2:
We are looking for a Security Content Analyst intern who loves to analyze requirements and create security policies (content) for our award-winning Halo product. Our product is not only known for its depth of security technology but also for its comprehensive breadth of capabilities that include software vulnerability reporting, software configuration management, file integrity monitoring, server access and dynamic host-based firewall management — each specifically built for cloud computing. Developing policy templates for these core services will be your focus. We support both Linux and Windows operating systems and their applications, therefore a broad knowledge of best practices and compliance requirements for securing these systems is a must have skill.

Internship #3:
We are looking for a Security Vulnerability Analyst intern who loves to analyze current and past CVEs for various Linux and Windows operating systems that are hosted in private or public cloud infrastructures. The analyst’s results will directly feed into our award-winning Halo product to improve our customers’ ability to manage know vulnerabilities in their cloud-based infrastructure. The analyst will also help QA our Halo Software Vulnerability Assessment (SVA) module as well as other security modules as requested. This is an excellent opportunity to have an impact on the security community in general and to help CloudPassage customers directly.

If you’re interested, are currently a student, and live in the Bay Area, please send an email to: