YOU ARE NOW READING
Security Impact of Putting it in the Cloud
It seems you can't make it through any IT related article or meeting these days without a discussion of "the cloud." Every CEO wants to know how the cloud can improve innovation and productivity, and every CFO wants to know when we're going to move to the cloud to dramatically cut the costs of doing business. Most CISOs are just scared to think about all that data sitting outside our firewalls.
In the security arena our job is to help identify and quantify the risks associated with such a move. The risks of an internally hosted application are well-understood, and more organizations have an established procedure to handle them. Information security controls such as firewalls, intrusion prevention systems (IPS), data loss protection (DLP), anti-virus, and vulnerability management programs are implemented to protect the organization and keep risk exposure at a certain level. A centralized authentication system (such as LDAP or Active Directory) is used to ensure users have access only to those systems to which they are authorized.
In an outsourced environment, the corporation loses control over the implementation of security controls. The outsourced vendor provides the security controls they deem appropriate, according to their own risk tolerance. Depending on the industry, this may or may not meet the needs of your organization.
While the scope of the security implications change based on the particular project, below is a list of questions to help you start evaluating the risk involved with moving your data outside the organization's boundaries.
What kind of data will your vendor be hosting?
Look very closely at any associated regulation. HIPAA, PCI, GBLA and safe harbor can all be concerns for the data your vendor will store. Ensure not only that the vendor's security is adequate, but that they can prove it for your regulators.
Who will have access to the data at the vendor's facility? Are they renting space from a data center company?
If so that organization's employees may have access to your data as well, requiring yet another level of due diligence.
How are your employees going to connect to the outsourced system?
Leased line VPN? VPN over the internet? Will the system be sitting on the public net? Each of these connection strategies has their own risks.
If a leased line is used for VPN connectivity care must be taken to understand the reliance on the ISP to provide access. If the circuit fails, access to the outsourced system will be unavailable and at the mercy of the ISP's service department.
If a site-to-site VPN is utilized, care will need to be taken to ensure that the scope of access granted to the vendor it understood and accepted. Opening a VPN tunnel allows for the possibility of data and malware moving between the organizations. Restrict the access to the smallest scope possible.
Is the system created with appropriate application security in place? Are proper steps taken to reduce risk of issues like cross-site scripting, SQL injection, and cross-site forgery attempts?
These issues are especially critical if the application will be available over the internet. Factor in the cost of running (or contracting with a third party to run) penetration tests against the vendor's environment if necessary.
How are user accounts created and disabled?
If the organization's central authentication system is not used, how can you ensure that users are not able to access the data once they have been terminated? Many outsourced systems will contain data that would be damaging in the hands of a recently terminated employee.
The cloud offers tangible boosts to productivity, flexibility, and scalability and does so while providing the means to reduce IT spend. Information security must not be the roadblock that prevents the adoption of such technology. By thinking ahead about the kinds of risks that outsourcing our systems will involve, we can be ready to quickly and securely lead our organization into the cloud.
This blog is reposted with permission from Robb Reck. To read Robb's Blog, you can visit: http://www.robbreck.net/blog/