Security Technology Executive

SEP-OCT 2018

Issue link:

Contents of this Issue


Page 51 of 59

52 SECURIT Y TECHNOLOGY E XECUTIVE • September/October 2018 • www. INDUSTRY VOICE W e don't have resources to invest in that new server farm, so let 's move it to the Cloud. Have you ever heard that from your C-Suite? N ew a p p l i ca t i o n s o r s i g n i f i ca n t upgrades to existing applications often require additional computing power. Since these expansions can strain existing in-house data centers in terms of power, floor space, and cooling , CIOs may want to shift new operations to outside cloud providers. For organizations who do not have previous experience with the cloud, this can be a high-risk endeavor. An important first step in moving assets to the cloud is to know the common mis- takes that can lead to a data disaster or a breach of sensitive information. 1 Treating the Cloud as an Extension of the Data Center Information technology professionals have historically taken the "M&M" securi- ty approach when designing network and application architectures – by designing a hard outer shell with a soft gooey core. Defending a perimeter is easier because the number of connections and ports is finite, therefore internal security controls have not traditionally needed to be as robust. The use of firewall rules also limits access inside, so less attention is needed. When data and applications are moved into a cloud, IT staff should not attempt to transplant the internal data center archi- tecture as it will be necessary to redesign the architecture with the unique risks the cloud brings. History has exposed a few common mistakes in credential management, addressing , and applica- tion management. The Top 5 Mistakes Made When Apps and Data Move to the Cloud A robust credentialing architecture must balance the complexity of a secure system with the amount of inconvenience that end users will endure. When applications and data are hosted in the same protected network environment as the end users, the lower level of risk will allow developers to leverage the user ID and password for gen- eral users. Administrator accounts should have additional controls, such as longer passwords or even multi-factor authenti- cation (MFA). For access to cloud applica- tions, a user ID and password is probably not appropriate for sensitive data so addi- tional controls such as device credential- ing and/or MFA should be the minimum. Administrator accounts should use MFA plus additional measures including VPN access, edge devices that are geolocation aware, frequent password changes, and of course increased logging and alerting. There have been several breaches of sensitive data because application devel- opers used web shortcuts. A more secure architecture would require a separate login to a web application before data can be accessed. It is never proper to create direct external links to sensitive data. In previously reported breaches, data was accessed because the suffix of the URL contained a record number, which was assigned sequentially. The breaches were reported when a third-party user was sent a direct URL link to access their personal data, then when they changed one char- acter, were able to access another individ- ual's data. There are a few workarounds, including requiring a complete login into a secure environment, then entering spe- cific credentials to access the sensitive data. While less secure, the use of very long and randomly generated unique keys will thwart most accidental disclosures. Finally, any public or private website can limit automated search engine indexing by putting a 'robot.txt' file at the root of every website. While this will stop legiti- mate search engines, it will not stop web crawlers and spammers who are looking for email addresses. 2 Assuming the Current Staff Has the Right Skills Amazon and Microsoft have made it easy for developers to put applications into their clouds. Microsoft even offers credits for Azure services to Microsoft Develop- ment Network (MSDN) subscribers. This means that many IT professionals could create and move sensitive data into the cloud, often without oversight or autho- rization. Organizations have no technical controls and little oversight that would stop this action. The first question every CIO should ask is, "Just because we CAN use the cloud, are we PREPARED to use the cloud?" Applica- tion and network architects and operators who have spent their entire career design- ing systems used in a corporate data center may not have the skills or experience to design and operate a cloud-based solution. For one, designs and techniques used in a closed environment, e.g., a self-hosted data center, may not be appropriate for the cloud. Authentication, firewalls, and event monitoring tools well- suited for local access may not be optimized for the cloud. Tools suited for the cloud will likely be virtualized so additional training may be needed before the IT team is proficient. 3 Shortcutting the Testing and Validation Cycle Other management processes that worked in a self -hosted data center may not be adequate to control risks. For exam- ple, organizations using cloud-hosted By Clyde Hewitt , CI SSP, CH S

Articles in this issue

Links on this page

Archives of this issue

view archives of Security Technology Executive - SEP-OCT 2018