M2M Making Buildings for Greener

I read an interesting article the other day about "smart buildings". The concept is not new but recent advances have made it even easier to cost-effectively implement systems that allow more efficient control and even provisioning within these buildings.  The article stated ROI within 2 years.

Being a self-confessed geek I loved this thought.  Think of remote management of building control systems, whether power, water, alarm, heat/cooling, entry, etc. The operational benefits are huge and potential reduction in personnel costs, or automation is great.

Being a security guy the personal alarms were going off since this article did not speak of the need for effective security management. When I think of M2M the first thing that comes to mind is strong identification and authorization of systems and secure channels to protect from alteration of data in transit.  The possibility of abuse without effective controls is significant and dependent on the tenancy of the building the risk will vary greatly.

So yes I love the idea of smart buildings using M2M to improve the operational and cost-effectiveness but please ensure you think about the security implications in the context of the business drivers before you start.

The attack against Cyber-Identity continues

I have many friends who may be considered cynics. Now these are not all people who are running around with foil lining their hats, but there are a couple that may just be in that category as well, but they are people that tend to believe first and maybe look into the verification aspect later.

Now coming from a security guy that opening paragraph may seem odd, especially given the title of this post, but let me explain. I am not one to believe that things that happen are inherently altruistic or inherently exploitative, I instead tend to believe that at any point either may be true and one needs to look at the context around something to see where on that "altruistic-exploitative" spectrum that something may fall. The key point is it rarely is black or white and that often there is some other colour injected into a circumstance that changes the hue. It is this base of idea that I work from when I look at cyber-security as well. when we look at things from a singular context we often lose sight of the environment and as such make decisions that may end up masking the real issues.

When it comes to Cyber-Identity this is often very true as when many people look at term cyber-identity they immediately fall into the "login credential" mindset. yes the login credential may be a cyber-identity but cyber-identity is so much more than that and this is where organizations are missing the big picture and thereby leaving real risks unmitigated. A couple of recent examples of this are in the vulnerability within the Android operating system and a SSH key compromise in Emergency Alert System (EAS) devices.

In the case of the Android vulnerability (documented by Bluebox) this was not a stealing of a credential but an attack that has some similarities to the FLAME attack. The vulnerability that exists has been around a while and effectively allows an attacker to modify signed code without the operating system being able to detect that the code has been altered. What does that have to do with identity you ask? Well the reality is the signature itself is intended to assure you that the code comes from its creator and has not be altered .... in fact to identify who created the code and has control of it. The reality is that with this vulnerability there are circumstances where we can no longer be assured of the identity of who produced the code/application.

In the case of the EAS device someone was able to obtain the SSH key that is embedded in the firmware of a certain set of a vendor's EAS devices. This effectively allowed them to take control of the devices and to create some interesting alerts - "Zombie Apocalypse". Steve Ragan wrote an interesting piece on it. This case highlights the threat of an embedded, permanent identity, that apparently was shared across the devices as it was embedded in the firmware. As soon as this key became know then all devices with those firmware instances became vulnerable. This situation is one where both sides can debate the threat/risk of using a shared identity as it certainly makes manufacturing more efficient but at the same time opens the door to whole scale firmware upgrade when an exposure happens. This is a great case of why the business need and security need have to be looked at together - and when I say security need I am referring to not just that of the vendor but the downstream effect, which in this case could be catastrophic.


What both vulnerabilities have is a totally different view of what identity is in the cyber-world and the very different need to consider when addressing mitigation. Both of these situations were avoidable, from a pure technical perspective. The question becomes when these systems were designed how big was the threat at the time and did that impact the threat-risk equation? We may never know but it does suggest that maybe, just maybe, we need to be more diligent about revisiting our equations when the system cycles through the technological generations.