Near the bleeding edge of technology, there’s a lot of talk (and work) around DevOps and the use of containers for delivering services. This is a fast-paced environment where services are spun up and down to meet demand in an elastic cloud and code is shipped to production multiple times a day. It’s also an area where security is far from ‘figured out,’ but there’s a lot of opportunity and an awful lot of discussion. I witnessed this discussion at the recent RSA conference in San Francisco.
At the other end of the spectrum, there are companies that actually make physical objects, and when they need to make a lot of them, they might use a number of technological tools to do so. One would think that the relatively “old school” market of discrete manufacturing would be a far cry from DevOps, but a close analysis of the two finds parallels that are particularly relevant to both information security and manufacturing. Discrete manufacturing, for those of you who are more familiar with Docker than an actual shipping dock, is any manufacturing process that produces things that can be easily touched, seen, or counted. Think about toys, or cereal packaging, or any product that benefits from being mass-produced in a repeatable assembly line. This is there where we find the strong parallel, with the assembly line. In many ways, the DevOps movement is aiming to solve the same problems that discrete manufacturing solves if only for a completely different audience. By instantiating infrastructure that allows for the repeatable production and deployment of code (containers), DevOps effectively aims to create an assembly line for the cloud. Instead of handcrafting servers and their applications, the requisite templates are created and then fed into the assembly line. Errors in a manufactured output aren’t handled by repairing that individual object but by disposing of the flawed product and adjusting the process to avoid reproducing the problem. In other words, DevOps doesn’t troubleshoot and repair a container the way we might with a bare metal server; instead we just remove it, correct the error in the production process that created it, and replace it with a known good container instead. The core principles largely overlap with the way a discrete manufacturing plant runs. With this clear parallel, we can examine how information security can learn lessons across markets to develop more effective controls for both IT and OT assets. Just as manufacturing addresses quality as a process improvement, so should DevOps address security as a process improvement. After all, security is ultimately a quality problem and can be addressed at the process layer of DevOps. Deployed containers that use a vulnerable library or have a misconfiguration or any other error shouldn’t be directly addressed outside of removing them from production as quickly as possible. Instead, the foundational controls around configuration management, vulnerability management, and policy compliance should be applied and managed on the assembly line. It’s not that the core principles of security hygiene need to be changed but that the application needs to be appropriate to the problem. While that lesson, carried from manufacturing to DevOps, may be clear, there are also lessons that go the other way, from DevOps to manufacturing. For those of you who are more familiar with Python than PLCs, it’s safe to say that discrete manufacturing is undergoing a transition to a more network-connected world. While there’s no shortage of technology on the plant floor, the network, especially IP networks, have been slower to penetrate this area of most organizations, and in many cases, information security is just starting to become genuinely interested in the tech that effectively makes the widgets. Along with that transition in the plant comes the adoption of more network-centric tools by vendors. DevOps as a whole is about adopting technology that can make an impact quickly while minimizing risk through resiliency. While it might have been possible to achieve security and productivity through isolation of the plant floor in the past, the rise of connected devices is going to undermine that strategy more and more in the future. Very simply, the assembly line will be pulled into the network. The lesson from DevOps is that all of that technology doesn’t need to mean the end of consistent delivery. By focusing on resiliency in the face of inevitable errors, DevOps teams have achieved unprecedented levels of consistent delivery with hyper-fast technological change rates. Discrete manufacturing should strive for that same level of resiliency when adopting new technology. This type of shift won’t happen overnight, however, and it certainly won’t happen without demanding that vendors supply it. If you’d like to read more about how Tripwire can help secure Industrial environments, check out our Solution Brief.
