Deployment Blocker No. 6: Stay in denial–pretend to run managed
I cannot number the times I sit in a kick-off meeting and the IT staff tells me they run a managed environment, yet cannot say with any certainty how many desktop or even server applications were out there. They have no packaging team or process. The inventory lists I am handed are stale.
By the end of these meetings these customers admit they have no true control of large portions of their network. In fact, fiefdoms are multiplying out there. I’ve had customers tell me their responsibility stops at the wall jack, or the internal firewalls they felt obliged to throw up to protect their network, and yet with a straight face declare they are running well (enough) managed systems. Or that the desktops don’t really matter because their servers are secure.
I don’t buy it. If the end points that consume and/or contain the sensitive data are not secure, you are not secure.
It particularly alarms me when the security team at these customers calmly informs me it has never had a successful attack. Such confidence is not helpful in a security team. I prefer security personnel who are nervous, with a haunted look in their eyes, sleep-deprived people who bite their nails.
If you see zero successful attacks in an unmanaged environment, you clearly aren’t monitoring closely enough, and the hackers already own you. My favorite quote came from a member of a security team who made this observation about his environment: “I can’t track attacks if I don’t know what is normal out there, and nothing is normal out there right now”. Tell me about it.
Why does pretending to be managed act as a blocker to deployments? Because there is a false sense of security that arises in this kind of environment, and planning for the unpredictable environment is inevitably shortchanged. Once these customers actually get out in the field and try to deploy, they hit all sorts of unexpected problems. On the security side, it is impossible to determine whether events are just another breakdown in the unmanaged environment (was that traffic spike a Denial of Service attack?)or a serious threat to the enterprise, a sign of real trouble.
The better way: Best to admit where you stand, and deal with it directly. Identify the reasons why users are revolting and why they insist on running with local administrator rights. Often these users have legitimate grievances or concerns, such as XYZ critical application doesn’t run well when logged in as User. Address those problems, remove all their objections. Work to move from unmanaged to more fully and more consistently managed systems, wherever you can. Don’t get too draconian too fast, just take it step by step, group by group, and constantly monitor to make sure newly established standards stay firm.
This is part of a ten part series of blogs “Top Ten Deployment Blockers”