What has “Shadow IT” Taught the Security Team?
September 11, 2014
“Shadow IT” refers to the practice, typically unsanctioned, of various departments reaching directly to outside IT support providers for services typically rendered and supported by in-house IT teams. The motivations for this practice can vary, but the top reasons are often “My IT department is too unresponsive” or “What I want isn’t in my IT department’s service catalog”. However it happens, the underlying message is clear: users will do what they perceive they need in order to accomplish the tasks they’re given. They will rely on their co-workers, but not to the point where they themselves fail and are held responsible.
Security protocols are the same. Security teams often run the risk of imposing, or at least suggesting, controls that are no doubt effective, but are too cumbersome or restricting in the eyes of the individuals whose access is to be controlled. The result is far too common: controls are bypassed or undermined, resulting in a downward spiral of ever-tightening controls and ever-riskier workarounds.
So, what can we, the security professional community, do in order to ensure we’re working with the business and not at odds with them?
Understand what assets are of real value and where they are. This is the first step to protecting yourself from appearing disconnected from the business. If you know where the valuable datasets are, logically and physically, you also know the assets you shouldn’t worry over. It’s also a matter of cost management. Do you need to protect everything in the environment or just some of it? These costs can include licenses, network bandwidth, storage capacity, or infrastructure management efforts.
Understand the current protocols. Retain focus on the assets of business-critical concern, create a map of all of the security protocols and concerns that protect them. They’re there for a reason. Ask yourself why. Are there “best practices” which were applied with little further thought? Are there best practices missing? Find some source of the history – the original owner/implementer, or some documentation of previous audits – to help you answer these questions.
Understand the options. With your map of controls and protocols in hand, you should have clearly identified the gaps you want to address. For each gap, come up with at least three options – each different in scope and impact. Every protocol at our disposal is some amount of monitor, some amount of control. Each gap in scope for your proposal should have an option that is “strong monitor”, “strong control”, and halfway between.
Understand the corporate culture. How open is the enterprise to change? How will your users react to tightened security? What’s the balance of how much impact an option has on the users against how easy it is to bypass? Understand your users’ perspectives. If a security protocol is both cumbersome and of little perceived enterprise value, it’s ripe to be undermined.
Help your advocates evangelize. Assemble your map of the world as it is, including the valued assets, the current protocols, their gaps and risks, and your options, together into a business-focused proposal. Express empathy and understanding, so everyone can understand you seek to work with the business and not against the users.
Any security plan that doesn’t focus on the critical assets is wasteful. Any security plan that isn’t mindful of the past will be inconsistent and incoherent. Any security plan that fails to take user actions into account will be worthless. Conversely, a security plan that offers options to the business, is respectful of the progression and maturation of the enterprise, and includes user evangelism is a plan that will be streamlined and successful.