Searching for a path to IoT security

My conversation with an informed skeptic.

1 2 3 4 Page 2
Page 2 of 4

SN: So you are not saying the right balance of security design to criticality of the application doesn’t exist.  Rather, it’s the companies developing these applications that are not as diligent as necessary to reach that balance. You referenced a life critical application as an example where the security and safety failed to make your point.  Deepwater Horizon is a very complex system with many participants.  What about the design of less critical applications like operational convenience?

TC: I recently read a couple of articles about companies who created products to maximize their own value, i.e. rushed to get product to market.  In one example, a security system is flawed in ways that no competent systems engineer or architect should tolerate.  This company produced, and sold, a system that can't be updated.  A basic, well-understood tenant of networked design is that you must design your systems with the ability to update them.  Nobody is asking for a perfectly secure system.  But the industry agrees that you have to be able to reach out and update your system if a flaw makes it through to the field or if the enemy adapts.  Burglars can now get plans to build a device to remotely turn off this particular home security system at will. I fear that kits to break into  this system will be available online soon.

Now in this particular case I hope the company will fix the issue and ship, for free, new units to all individuals who have the flawed unit.  But who is going to pay the cost of any real compromises that occur? Will this company reimburse the victims who have their homes broken into via this exploit to restore their valuables?  I doubt it.  More likely the victim’s homeowner’s insurance, i.e. all of us, will pick up the tab to replace the valuables and the home-owners will lose time from work so they can re-secure their homes and get their valuables back.  The company that created this situation of unwarranted consumer trust is not accountable for the full impact of the risk they delivered to market.

SN: Okay, so we have our first point of agreement: brand accountability to customers in the IoT as it relates to security is not yet an “efficient market.”  Indeed, that was a key take away from the panelists in Steve Bush’s “10 years to security” article – companies today have very little motivation to pay for security because consumers are not holding them accountable.  I see three forces that can make companies more accountable to security.  The first is the somewhat altruistic self-regulation, something in which I believe but upon which I would not depend. The second is government regulation, something in which I do not believe but upon which we often depend because of the tort, and finally the customer and efficient market in which I believe and will depend because it makes or breaks brands.

Good requirements definition AND Checks & Balances

SN: I believe that there are companies who care enough about their brand to follow good security practices to protect their customers and their customers will create the efficient market.  I think this can happen faster than regulation but it is not certain.  But I also agree that good systems designers and product managers should be accountable to market expectations for security – at the appropriate level of risk.  Unfortunately, I think that enthusiasm with the technology is overriding fundamental practice in many cases today.  But I have read, and even heard you say, that the problem with IoT security is not one of technology, but rather this process and diligence.  How should the CIO of an IoT focused company implement checks and balances to mitigate poor security in design?  What are the fundamentals?

TC: Go back to engineering process and requirements.  Establish policy to refresh requirements as the threats evolve and recommendations change.  Security is not a static -- do it once and forget it.  Instead, you need to monitor the field for abnormal situations and undesirable trends, identify flaws, and issue patches.  As a CIO, you should be held responsible for establishing basic risk management requirements. The CTO should be held responsible for identifying solutions.  You or your CFO should provide the audit to make sure the solutions satisfy the requirements – checks and balances.  Solutions and audit should definitely be in separate parts of your organization.

If you are a tiny company, and need a place to start, start with the Center for Internet Security Controls. The California Attorney General’s Office recently stated not doing so would be indicative of an organization’s failure to provide reasonable security.  Also check out the IEEE article, "Avoiding the top 10 software security design flaws."  If you have a web interface as part of your solution (whether on your device or at your company), address the OWASP Top 10.

Keep in mind that these are "top" lists.  Dealing with those top items doesn't mean you are done with security, it merely means you're starting in the right direction.  Resist the temptation to use proprietary, closed security solutions, whether they are your own or ones you are buying them from someone else.  If you come up with something clever, by all means patent protect it.  But the effective security solutions tend to be ones that have had many smart eyes on it.  Whatever you do, don't build in a product back door.  If you can get into it, chances are so can attackers. 

1 2 3 4 Page 2
Page 2 of 4
7 secrets of successful remote IT teams