OpenDNS and Cisco

Cisco recently acquired OpenDNS and its security offerings.

The Domain Name Service is a hierarchical lookup service that converts human readable names to IP addresses that are used for routing. As such the DNS lookup servers can see the names being accessed, their access trends, web security attack patterns such as phishing redirects and so on.

But how did OpenDNS come to focus on security ? It was preceded by a free DNS service called EveryDNS started by David Ulevitch in his college dorm in 2001. The free nature of it attracted an interesting clientele– a number of malicious services, sites and agents.  This gave EveryDNS visibility into this part of the internet – both the customer view and a real-time view. David realized the potential and started a new company OpenDNS with both a free+paid dns offering and a growing number of security services.

In 2012 OpenDNS offered an Umbrella service to blacklist malicious sites. The most interesting offering is its OpenDNS Security Graph. The Umbrella Security Graph maintains and automatically updates malware, botnet, phishing domain and IP blacklists. This is then sold to enterprises – a higher margin business than providing DNS lookup alone.

Verisign is also in the DNS security business after it sold its certificate business to Symantec.


Tesla Model S hacked by researchers

Tesla is an advanced computer on wheels. How is security for such systems designed ? Snippets from below are insightful.

“Two researchers have found that they could plug their laptop into a network cable behind a Model S’ driver’s-side dashboard, start the car with a software command, and drive it. They could also plant a remote-access Trojan on the Model S’ network while they had physical access, then later remotely cut its engine while someone else was driving.”

“Tesla distributed a patch to every Model S on the road on Wednesday. Unlike Fiat Chrysler, which recently had to issue a recall for 1.4 million cars and mail updates to users on a USB stick to fix vulnerabilities found in its cars, Tesla has the ability to quickly and remotely deliver software updates to its vehicles. Car owners only have to click “yes” when they see a prompt asking if they want to install the upgrade.”

“The Model S has a 17-inch touchscreen that has two critical computer systems. One is an Ubuntu server responsible for driving the screen and running the browser; the other is a gateway system that talks to the car. The Tesla gateway and car interact through a vehicle API so that when a driver uses the touchscreen to change the car’s suspension, lock the doors, or engage its parking brake, the touchscreen communicates with the gateway through an API, and the gateway communicates with the car. The touchscreen never communicates directly with the car. “At least so our research has found so far,” Mahaffey says.”

“The Model S has an Ethernet cable for diagnostic purposes and by connecting to this they were able to get access to the car’s LAN. This allowed them to uncover information about the firmware update process, such as the configuration of the VPN the car used to obtain updates as well as the URLs from where the updates were downloaded. They also found four SD cards inside the car that contained keys for the VPN structure, and they found unsecured passwords in an update file that allowed them to gain access to the Tesla firmware update server. “By using the VPN credentials we got from the SD card, we were able to configure and open VPN clients to go and talk to Tesla’s infrastructure and mimic the car.”

Even though Tesla provided the update quickly, having unsecured passwords in a file that allowed access to go to the firmware update server should alert one to the risks of connected cars.

Zigbee Scanning from a Flying Drone


Security researchers have developed a Flying Drone with a custom-made tracking tool capable of sniffing out data from the devices connected to the Internet – better known as the Internet-of-things.

Under its Internet of Things Map Project, a team of security researchers at the Texas-based firm Praetorian wanted to create a searchable database that will be the Shodan search engine for SCADA devices.


The researchers located all ZigBee-enabled smart devices and networks and then started expanding their research.
“When [IoT devices] communicated over a wireless protocol called ZigBee, this protocol is open at a network level. So when the devices start connecting, they send out beacon requests. We capture data based on this,” says Paul West Jauregui, from Praetorian.
ZigBee is a popular smart-home wireless communication standard used by the majority of Internet of Things (IoT) devices today.
ZigBee protocol, which lets IoT devices talk to each other, is implemented by major vendors including Toshiba, Philips, Huawei, Sony, Siemens, Samsung, Motorola, and many more.

Building Automation Security Plan (Target, HVAC)

The Target data breach in 2013 affected 40million credit cards. It was traced back to an onsite HVAC (that was remotely accessible for billing) being on the same network as the rest of the system . The credentials for the HVAC were breached and used to attack the internal computers.

The link below discusses a comprehensive security plan for a building automation system. The connected components are identified and the network and systems are designed for authorized access.

One can see such a plan being useful for a number of sensor/IOT systems – e.g. energy, temperature and and video sensors.

On Software Requirements

There are a couple high level tradeoffs in the requirements specification process. Each tradeoff can be thought as an axis: Specificity (detailed vs vague), Audacity (visionary vs trivial/checkmark), Customer-driven (needs vs wants; with timelines).

It is possible for them to be too detailed – the more detailed and specific the requirements are, the less understandable they are and the less flexible they are in a rapidly changing context. But if the requirements are too vague, then they are likely to be misunderstood or ignored by a development team. This is a case where directly talking to the end users and clear communication between team members to flesh out use cases will help.

Also if the requirements are too visionary then they may appear infeasible to the team.  Showing they are achievable by looking at related products is one solution. Decomposing the target into achievable modules is another. If they are too near-term, then they may appear trivial and fail to excite the team.

Finally the requirements should be well grounded in customer use cases and narrowly stated, rather than inherited as a long list from past successful technical products. This is probably the most important and hardest thing in practice.

Specifying the right amount of detail for development targets that are grounded, challenging and achievable is an important skill.

Another take on this topic is Joel Spolsky’s series on writing painless functional specifications.


Web authentication and SSO typically imply that state is maintained on the server to indicate whether the user is logged in or not. The identity provider maintains this state and the identity consumers check this state with the identity provider. The protocol and message format differ in different implementations – SAML, OAuth, OpenID and several others.

SAML is the richest, most flexible auth protocol, but also most complex to implement. It covers the most number of use cases. The security assertions about an identity are captured in an xml format which can be exchanged between providers and consumers over the web.

OAuth is simpler and requires fewer things from the implementer. OAuth 2 has become a vehicle for enterprise use cases like SAML. SDKs for OAuth are available.

OAuth 2 and OpenID both use Json WebToken (JWT) which is a JSON format specification for interoperability.

OpenID Connect is the most open and newest of the three. It reduces  reliance on checking auth state with the identity provider by embedding more information in the JWT and standardizing things like scope to increase interoperability.

A key consideration when deciding on an implementation is the scalability requirement. Ideally the system is structured to keep the least amount of state (zero) on the server. This is not true of most SSO implementations.

Like a stateless NFS server, based on leases for lock state that can be refreshed, a stateless implementation for SSO is possible (classic NFS has no open, only lookup). The tradeoff is that revocation is not as easy and reporting may need to be handled differently than with a stateful implementation. Here’s a discussion –


iOS TouchID Enterprise Use Cases

When implementing TouchID for an enterprise authentication solution there are some interesting attack vectors to consider, that are not obvious.

There are differences in requirements between COPE and BYOD deployments for instance.

Depending on the type of deployment and the type of data accessed, the security required may call for a simple TouchId check without password stored/retrieved, or for a password to be stored in the enclave to be retrieved, or for TouchId to be combined with another factor for a multi-factor authentication solution.

Some drawbacks to the initial TouchID implementation discussed here are still relevant . There is now a developer API available however which allows flexibility in implementing a solution for the enterprise.