Skills develop with practice and repetition. It’s true of anything, from playing the piano to driving a car. In any endeavor, the way to get better is to practice. Attempt the activity again and again, learning from mistakes made along the way.
“Practice makes perfect” — that’s not a way we usually think about information security; instead, we usually approach security tasks with a “measure twice, cut once” mindset. That’s not to say we wouldn’t get better at security activities with practice — it’s just that when deploying critical security controls or securing areas of our infrastructure, we usually get just one chance to get it right.
However, second chances can and do come. Every once in a while, we get an opportunity to revisit mistakes we’ve made in the past, to improve on what we’ve done already, and generally just hit the “reset button” on things we thought were a “done deal.”
The migration to the cloud happening across much of IT is one of those areas of opportunity. If your organization is like most, chances are that it either has or soon will have a migration to cloud-based technology infrastructure underway. Sure, specifics of the migration will vary. Every organization has its own business drivers and types of services/components to migrate. But from a generic security point of view, the specifics don’t matter all that much. What matters are two concrete facts: 1) Resources have been made available for the transition, and 2) One of the most important aspects of any cloud transition is information security.
Quick and Dirty Risk Profiling
From our business partner’s point of view, the “bare minimum” for the security organization during a cloud migration is to ensure that moving to a cloud model doesn’t introduce additional risk over and above what there was prior to the migration; this is likely to be their primary expectation of us during the migration process.
But consistency represents its own challenge, because keeping a consistent risk profile requires a level of internal awareness that we might not necessarily already have. For example, do we have a full understanding of all of the controls across all of the infrastructure components that are being migrated? Do we have consistent policies, procedures, and processes across all of the services in scope? In many cases, no. So right off the bat, there’s some housekeeping that we need to do.
The best case scenario (though unlikely to be the case) is that we have a full understanding of our current risk environment, something along the lines of a traditional risk analysis: threats, controls in place, as well as residual risk after control deployment. If we don’t have this, we’ll need to do a “quick and dirty” inventory of risk; a narrow (but easy to get in a hurry) picture of our risk profile comes from understanding the currently deployed controls we have fielded, including administrative, physical and logical/technical controls. It’s not a full risk picture by any means, but a record of what our protection measures used to be before the world started changing gives us something to go by and approximate to once change starts coming rapidly. And the earlier we have it, the more we can use it to guide planning discussions as migration planning progresses.
We also need to understand the controls that our selected vendor(s) have in place so that we can find weak areas when compared to what we have and plan accordingly. Asking your vendor for documentation that they have is a good first step; many will have already prepared documentation such as a “SIG” (Standardized Information Gathering) questionnaire under the SharedAssessments program. Even if they don’t have something that comprehensive, they may be able to point you to evidence about controls in place such as appearance on the PCI certified service provider list, an ISO/IEC 27001:2005 certification, or (at the very least) a SAS 70 audit.
Once you have both your controls and your vendors’, align them. Compare yours to theirs and look for problem areas — areas where you have a control your vendor is missing or where your control is significantly stronger. Best case: You’ll have time to do this before a vendor is selected, giving you leverage to work with the vendor to map out planned controls and areas of responsibility. Worst case: You’ll be involved late, after vendor selection, meaning you have less ability to push back on the vendor to enhance controls (in this case, you’ll need to come up with compensating strategies for situations where the vendor’s controls are not up to snuff).
But either way, knowing where the weak areas are is a useful step, and a side-by-side comparison will get you there in a repeatable way.
From Tactical to Strategic
Understanding the risk profile — even when painted with broad strokes — is a good first step. However, the focus of that approach is on maintaining the status quo by making sure that the security of the environment isn’t compromised through migration to a cloud-oriented model. Really, a security organization with vision is looking beyond just the status quo — looking to leverage funding from cloud efforts to forward security in a strategic way.
There are numerous opportunities to do this, provided we are alert during the migration process. We can align legacy platforms/applications/components to current security policy, we can revisit variances/exceptions granted to individual initiatives, and we can selectively redress decisions made in the past — decisions made before we came on board, or just plain old mistakes that we’ve made. The point is that we have an area of opportunity for improvement that we don’t ordinarily have.
The key to taking advantage of this state of affairs is twofold: active participation in the migration process itself and understanding of in scope areas that would benefit from change. Just like you did when you inventoried the control areas for systems in scope of the migration, start with an inventory and documentation of security problem areas that you’d like to see improved. Then get as involved as you can in the migration process itself: Stay involved from planning to implementation to maintenance. When discussions turn to an application, component, process or technology on your improvement “bucket list,” raise the concern and ask the migration stakeholders if the issue is one that can be addressed during the transition. You’ll be surprised how often the answer is “yes.”
The transition to the cloud puts the enterprise into a state of flux, and that state means we have much more leverage to effect change than we ordinarily would. Planning ahead, being involved, and having a voice in the cloud migration isn’t just important to maintaining the security status quo — it’s also a second chance to close out problem areas we know about but ordinarily would have to live with.
Ed Moyle is a senior security strategist with Savvis, providing strategy, consulting and solutions to clients worldwide, as well as a founding partner of Security Curve. His extensive background in computer security includes experience in forensics, application penetration testing, information security audit and secure solutions development.
Loading ...
