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.

http://www.automatedbuildings.com/news/may14/articles/llnl/140425010101llnl.html

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

Advertisements

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.

SSO, SAML, OAuth, JWT, OpenID

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 – http://stackoverflow.com/questions/26739167/jwt-json-web-token-automatic-prolongation-of-expiration

Update. Here’s another discussion which points to some tradeoffs – https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens , basically that this is more useful for SSO and API implementations not simple websites.

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.

OS X Malware and Connected homes

Here is a talk from Synack on OS X malware. iOS is locked down but OS X is much more open – obviously one can download applications outside the appstore and load and run apps and dylibs that are unsigned. This impacts security for a connected home with many devices with hubs that may be OSX based.

For example here’s a description of remote control of a baby monitor – http://www.zdnet.com/article/iot-security-under-scrutiny-as-apple-looks-at-smart-home-system/ .

RSA World 2015 San Francisco Internet of Things

Several interesting companies I talked to in the mobile and enterprise space

  • BlueBox Security – automatic containerization of mobile apps
  • SkyCure – identified some DoS attacks that can occur against iOS devices
  • Okta – allows integrations with some 4000 different applications from a single identity console.
  • BlueCoat Systems – network traffic analysis for malware detection
  • Microsoft – integration of admin and user policies for Office365 with Email.
  • Shape Security – changes the shape of the traffic by detecting the large fraction of traffic that is not coming from real users and blocking it from hitting the webservers
  • German pavilion with several technologies including database encryption and controls

On the IOT side of things there were hacking demos of Nest thermostats, Vera home automation systems, remotely connected storage devices. Read more about the “Internet of Crappy Things” at the Kaspersky blog – https://blog.kaspersky.com/internet-of-crappy-things-2/8518/

Simple Crypto Operations

In a pure transposition cipher, the text “AAAAAA” is transformed to “AAAAAA”.

In a pure, static substitution cipher, the text “AAAAAA” is transformed to (say) “ZZZZZZ”.

In a vignere pad, the string “AAAAAA” input  is transformed to an output which is equal to the keyword (or an offset of all its letters, making it easy to guess).

If the keyword were completely random and not used again, but still shared between two parties, one would arrive at the one-time pad, which has perfect secrecy.  Is this possible ? Wikipedia says information-theoretic secrecy is used in top secret communications.

The Enigma cipher was a dynamic substitution cipher where the substitution maps changes as the rotors rotate before each letter is entered. This machine and its code-breaking machine is the subject of the movie The Imitation Game, discussed in my previous blog post.