Two’s a company, three’s a cloud.
Does your organization have a cloud policy yet?
By that, I mean: does your organization have a policy about who’s allowed to use third-party hosted services, and under what circumstances?
One of the banes of a CISO’s existence is the rogue IT group that a department has built up on its own. They make their own procurement, architecture and implementation decisions—they just go out and do whatever they think is best for them. You’ll find infrastructure you didn’t even know had been installed; you’ll find software, of course, that magically appeared; and you’ll sometimes even find that their administrators had taken over control of the infra you thought you were running.
Back in the day, to do that you actually had to hire IT people. But now, thanks to services, anyone with a checkbook can buy them.
What’s your answer when a department head asks you why they can’t ditch the lousy Exchange server and just use Gmail? It’s free, everyone knows how to use it, and it’s a lot more reliable with no support costs. How about Survey Monkey? How about a hosted service of any kind where you upload data to them for some kind of processing?
I’ll give you a hint: you can’t just say “It’s not secure.” Nobody will believe that. Remember, if they see everyone else taking the risk, they’ll think it’s an acceptable one. Luckily, there are other business issues to contend with besides security, and if you can get the right people at the table, they will answer them FOR you.
Which services require contracts (and presumably money), and which don’t? Do you care whether departments use free services?
Where contracting is needed, can the departments all set up their own, or should there be a coordinated or centralized contracting process?
Are there availability issues that need to be highlighted? (Yes, even Google has been known to FAIL.)
Will the service involve data that might be needed for litigation? If so, how do you get it back? (This might be a terrible disadvantage to your legal staff—“We’re sorry, we can’t provide IM logs, go talk to AOL”—or it might be a great advantage—“We’re sorry, we can’t provide IM logs, go talk to AOL.”)
Are the service-level agreements with the provider aligned with your own service-level agreements to your customers? If not, how do you pass along liability?
If the service provider goes under, or the department decides to terminate the contract, do they have a place to come back to in your infrastructure?
Once your executives hash through these questions and are sufficiently open to listening, you can start bringing up questions like this:
How are we going to look in the papers if this provider has a breach with our data?
Remember, most of the time the name of the OWNER of the data goes above the fold, and the name of the contractor goes below the fold (if it’s mentioned at all).
At this point, if you’re lucky, the CEO will frown and ask you to start looking into the reliability and security of the proposed service provider, and then you can do what you had been planning to do in the first place: a real risk analysis. Hopefully you will have written down the answers to the earlier business questions, and you can start referring to that list as a Policy. Tack your security risk decisions at the bottom, et voilà!
