The Internet of Things is a wave of connected opportunities that brings in a broad range of data to enterprises. Being able to turn the data into actionable data quickly is a target objective driving enterprise of IoT. Artificial intelligence, interjected to take over menial and complex tasks that tend to introduce latency, will further reduce the time needed for processing, interpretation, and action.
This connected world will comprise middleware solutions, too -- not all of which will be security conscious, but rather designed on-the-fly for the sake of convenience or solving an intermediate problem. While large enterprises are accustomed to vetting solutions, SMBs are more prone to adopt fixes based on immediate need and pain points. Risks exist in security, as they do in installation practice (how the IoT devices are powered, connected, and maintained) and their dependence on other systems.
Applying Best Practices
One example is the use of fiber for laying out a security camera network. Fiber conquers distance easily, but in a recent case I came across, the organization had terminated fiber in a pull box, with one AC receptacle inside, added to the infrastructure. The design featured an adapter with a fiber input, power output (to the AC), and two cable outputs: one coaxial and one power to the camera.
The design intention was to overcome the distance from the camera controller to the camera itself. Well done! But the flaw in the design is the power, and since all cameras do not have any battery backup or UPS behind them, you can imagine the chaos ensuing this installation -- rebooting cameras, loss of picture and footage, and then troubleshooting.
Another example I find on many sites is use of the wrong material, whether that be cable, cable type, or fire stopping or substitute, such as plumbers foam, for the environment. These problems exist in too many locations. Best installation practices but not be compromised for IoT devices; network managers and administrators must insist on best practices and actively engage in the installation process.
Automated Response
The second area of concern is that networks require layers of security, and that security solutions themselves cannot remain static. I will use the word "elastic," with elasticity decreasing in times of known or perceived security risks (automated or manual actions taken) or increasing during business as usual. Of course, this is a plug to the security folks, in that new signature files and updates are reactions to known and analyzed threats -- tested and then reacted to by the way of updates to firewalls, client software, and patching to close holes and fix newly exploited vulnerabilities.
As I mentioned in a previous post, "Internet Security: Use Wisely," Avast lets administrators change security policy to "hardened mode" from their cloud-based antivirus console. This particular action is an example of elasticity, and a potential area for automation, to reduce the response time to a known security issue.
In other words, would you rather have AI respond, or someone in IT making the decision to put client AV software into the hardened mode? This is hot area in IoT deployments, with enterprises making demands for faster data collection and processing of that data and then immediacy on the actions.
More Elasticity
IoT devices that connect to the home or business, locally or externally, must not be overlooked when it comes to security. For example, mobile device management cannot just be a policy and procedures line item, but requires an embedded solution to meet the security challenges.
I will use Google G Suite as an example, recalling the example I shared recently of a company that took the extreme security step of ordering all employees to stop connecting smartphones to their network. At the very least MDM solutions such as Google provides are faster, but still not automated in the response. Below is a shot of Google's MDM -- note that administrators can block, wipe device, or wipe account, as well as disable the user account through another setting in Google's Admin console.
According to Google, when you find the device, view its Status column at the far right. You can see if the device is being remotely wiped, blocked, unblocked, approved, or is not in use. A blocked device still shows up on the Mobile devices page, but the user can't access his or her G Suite data (mail, calendar, and contacts) from that device. If you block a device, the user can still access mail, calendar, and contacts from a desktop computer or mobile browser. To disable a user's access to their G Suite data from any device (mobile or desktop computer) see Suspend users. Google goes on to note what happens to suspended user accounts.
The elasticity of embedded security systems needs improvement, necessary to reduce the time to respond. Introducing the billions of IoT devices and sensors will require more automation to respond and to protect IoT's value. The argument for AI will remain constant in the effort to reduce latency, not just in security but in processing, interpreting, and acting on IoT triggers that enterprises seek.
Follow Matt Brunk on Twitter!
@telecomworx
