As a security professional, you are part of the change management board, right? Because if not, how are you making sure that the change management items are also linked to the asset inventory, access is properly managed, and all the appropriate hardening guides and security tools are installed/configured/understood? What? You say you don’t have a change management board. This could be problematic…
Change management is one of the first ways information security learns about new systems and applications coming down the pike from other areas of the business. It’s one of the “canaries in the coal mine.” To stay sane you, as a security professional, must know what new system(s) someone in marketing, IT, or accounting bought from a vendor last week and rolled out to their team for use. Things don’t always work this way, though, do they? How many times have you seen a third-party system being used in production, but about which you were never consulted, that shows indication of compromise? Or maybe you’ve discovered a tool that is being used improperly, and is spewing information out into the world? Never? Wow! You’re a bad liar!!!
If that system had gone through change management, you would have had the opportunity to object, to mandate a security review, to ask questions, at least. And if the system isn’t brought through a change management review, it’s not your fault when it breaks, when it spews sensitive information, or when its default admin password stays at “Password1”. Not your fault. But are you held responsible? You are the security professional, tasked with securing the company’s data and systems, after all. If the right processes and policies aren’t in place—or if departments aren’t aware of these policies and procedures—than I am sorry to say, it is your fault.
Change management, patch management, asset inventory, ticketing system, access management. They should all be linked. Any access change, any addition to the asset inventory, these are all changes. Some of them don’t need to go in front of the change management board, but some of them do. When a server is patched, it’s a change management ticket. It needs to receive sign-off, be scheduled, and all application owners on that server need to be notified. If they don’t complain, delay, or stop the process, they’ve given agreement. When a new piece of shadow IT equipment shows up in your asset discovery scans and a change management ticket can’t be found, it gets unplugged. Immediately. What if it’s a senior exec that needs that piece of equipment? No problem; call someone on the compliance team (who is also on the change management board), along with IT (somebody’s got to support it), accounting (somebody’s got to pay for support), and we’ll get this sorted in no time! Three weeks at most! If this sounds like a career-limiting move, this is why the change management board needs to be established in the first place: So security isn’t the “bad guy,” delaying or denying systems and usage. When someone in the organization goes rogue, adding systems that introduce vulnerabilities that can’t be accounted for by the change management board, then, truly, it’s not your fault when something goes wrong.
If all you do is fight fires, you never have time to look ahead. Building the relationships to get those warnings early into each and every department takes time and effort. Lots of it! Being part of the change management board and system allows you to not only know when new systems, applications, and hardware are being brought in officially, but it gives you the clout to stop anything that hasn’t gone through the change management board.
Change management is the canary for security and IT. It’s your early warning system and your big stick all in one. Amazing how useful those compliance tools are, yes?
Oh, just wait. Next week, we’ll be talking about how policies will get your budget raised, and headcounts increased!
Josh will be co-leading an interactive roundtable discussion on The Automation and Commoditization of Information Security, at InfoSec World 2018 in Orlando, FL.