Why Infrastructure Security Is Key to DevSecOps
- …sleep a little better at night knowing that one possible source of tomfoolery is blocked. Yes, in complex environments like service providers, this is easier said than done, but it is worth the effort if it assures unauthorized changes are caught quickly.
- For public cloud implementations, three words: automate, automate, automate. There are toolsets out there, like VMware’s Secure State, that can help set standards across the variety of cloud services and cloud vendors (Disclosure: The author worked with the Secure State team before they became part of VMware). By automating the process, and monitoring for compliance with standards set by the company, systems like Secure State create consistency in cloud environments. Of course, the rules must be set up and maintained to reflect the newest developments in security, but this is better than searching through cloud subsystem offerings to find just the right switch to flip.
- If you build it, you must store it. For most MSPs, storage also is a big deal. Customers are storing things on your systems, and any attack that might allow a criminal to modify customer files is huge. Some environments are easier to handle in that regard than others — a storage/backup provider can offer encryption on the customer site before transfer, for example, and protect files, while a hosting provider has to protect servers/subnets because web hosts must have executables stored on them. While worthy of mention here, this particular problem is best solved in verticals.
- The big thing is to lock down centralized touches-your-code systems like Git and Jenkins as much as possible in your environment. The potential harm for a service provider is many times larger if one of these apps gets hacked than if a website is hacked. Particularly in Jenkins, remove unused plug-ins. They are doing no good if they are unused, and offer an attack surface that security might not be paying attention to … because they’re unused and security is perennially understaffed.
DevSecOps is a big deal, but locking down the systems that do DevOps and supporting infrastructure before attempting to lock down the product of DevOps is required. Security of output cannot be achieved without security of systems creating the output. Your customers are counting on it — take the extra steps and reward their confidence. You won’t get any thank-you notes, but you likely will avoid the negative effects of not locking things down.
Don MacVittie is the founder of Ingrained Technology, and has worked in every facet of IT from entry-level programmer to CIO, from network operations to storage and database analyst. He currently works in DevOps while running a successful technical evangelism consultancy. Don has contributed to projects his company worked on for organizations in DevOps, DevOps leadership, data protection, network security, global file systems, and non-IP communications spaces, along with several international publications and PR firms. His MSSP background is in both communications and utilities. Follow him on LinkedIn or Twitter @dmacvittie.