Security Technology Executive

SEP-OCT 2018

Issue link: https://securitytechnologyexecutive.epubxp.com/i/1030460

Contents of this Issue

Navigation

Page 52 of 59

www. SecurityInfoWatch.com • September/October 2018 • SECURIT Y TECHNOLOGY E XECUTIVE 53 About The Author Clyde Hewitt, CISSP, CHS is v ice president of securit y strategy at CynergisTek . He brings more than 30 years of executive leadership experience in cybersecurit y to his position with CynergisTek , where his many responsibilities include being the senior securit y ad v isor and client executive, thought leader and developer of strategic direction for information and cybersecurit y ser v ices, nationwide business development lead for securit y ser v ices, and contributor to CynergisTek 's industry outreach and educational events. applications and data will want to consid- er a strong separation of duties between the developers and the operations team. At a minimum, cloud-facing applications should have independent vulnerability scans and penetration testing that is dif- ferent than internal applications. These skills may not be available in all internal IT departments. Addressing the second issue of main- taining a separation of duties, it is more important to have an independent gate- keeper with authority to stop deployment of untested applications. In many IT depart- ments, there is pressure to maintain dead- lines, but this can lead to higher error rates and ultimately more breaches. Formal qual- ity gates with formal reviews of indepen- dent testing results can significantly reduce the risk of breaches caused by misconfig- ured or poorly designed systems. 4 Skipping the Responsibility Matrix During Contract Negotiation Another common mistake does not involve the technology itself, but how the cloud technology is managed. First, not all cloud environments are the same as there are major architectural differences between Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), and Application as a Service (AaaS) also known as Application Service Provid- ers (ASP). All cloud models will require the organization planning to move into the cloud to mitigate the risk to confidential- ity, integrity, and availability as the ultimate responsibility for securing one's data cannot be delegated. One method for clarifying roles is to create a responsibility matrix and include it in the contract. Specific actions to be addressed include who has responsibility for each of the required security controls, as well as who will manage the opera- tions. There is at least one instance where an organization put applications and data into a PaaS cloud and assumed the hosting organization would manage the firewalls. While the assumption was correct that the hosting data center did have a firewall, it only controlled external access into the data center but did not adequately firewall off individual users within the data center. Other users have incorrectly assumed that an IaaS or PaaS solution would pro- vide geographically separated environ- ments for disaster recovery purposes. For example, many of the 9,000 clients using The Planet, a nationally recognized data center provider, learned the hard way that contracting for a secondary backup location is not foolproof. In this instance, The Planet had its primary and backup data centers in the same building and shared many of the same utilities. When a fire occurred in 2008, separate data centers on different floors went offline because the fire depart- ment did not let the company operate the backup generators. Starting with availability, providers of SaaS (who host their own software) and ASP (typically solutions based) generally have turn-key solutions that address data back- ups and disaster recovery challenges. Con- tracts with SaaS and ASP providers typically contain fewer details about "how" the cloud is designed to be resilient and more about "what" happens if a downtime occurs. Both SaaS and ASP providers have been known to include contract language that prom- ises a minimum reliability, as measured in uptime. Depending on the criticality of the application, uptime guarantees should be in the 99.9 to 99.999 range. Financial penalties for not meeting these expectations should be reasonable, but a definite deterrent to incentivize better performance. Contracting officers may expect to see language where downtime is paid on the percentage missed, but this may not be adequate to compen- sate the using organization who must resort to paper downtime procedures. PaaS and IaaS providers require a much different contracting vehicle. In these cases, the using organization is responsible for identifying all security and privacy controls, then either contracting for those services or providing them organically using virtual servers and virtual applications. Typical errors to avoid include not planning for a second data center to use as a disaster recovery center. 5 Failing to Perform a New Risk Assessment All the above mistakes could have been avoided if a thorough risk assessment was conducted prior to implementing any cloud-based solution. A proper risk assess- ment should have identified these risks. A mature risk management plan should have mandated that these risks be mitigated to an acceptable level. Performing a comprehensive risk assessment requires different skills and perspective than what is typically found in IT departments. Attempts to conduct risk assessments with untrained staff or staff with an 'agenda' can result in a myo- pic view of risks. This leads to unsafe con- ditions being scored at a lower level than what an independent assessor will find. The decision to move data and applica- tions into a cloud is an excellent example of a justifiable and appropriate use of an independent risk assessor. This risk asses- sor can work for the same organization but should not report into the IT depart- ment or else he/she may be pressured to not slow down the project. If these condi- tions cannot be met, consider the use of an independent third-party assessor who can not only perform the risk assessment, but also the vulnerability scans and penetra- tion testing. Conclusion By now, it should be clear that any move from a self-hosted data and application environment into a third party or cloud environment introduces significant risks to any organization that is unprepared for the change. There are technical challenges, but more importantly, organizational and management adjustments that must be made before the first connection is made. These challenges require careful planning, or else organizations will find themselves in the news trying to explain why they exposed sensitive data.

Articles in this issue

Links on this page

Archives of this issue

view archives of Security Technology Executive - SEP-OCT 2018