Impact analysis report

Case scenario

Task is below the case scenario

You are an ICT technician. As part of your job role you are required to back up system, restore information, secure the system and information in a stand-alone or client-server environment.

Your client has advised you that when they were migrating all their data and applications from disaster recovery environment to the cloud, they acknowledged the applications and data were too complex and required too much horsepower and caused significant downtime.

Through the initial analysis, you have identified that your client has two choices: find a cloud service provider that could cost-effectively deliver the compute needed to support the business, or move its DR environment to a third-party, on-premise provider that could accommodate its complexity and horsepower requirements.

You have gathered the following information from the company documents and browsing the internet:

Vulnerability assessment and general definition of requirements

1. Consumers Have Reduced Visibility and Control. When transitioning assets/operations to the cloud, organisations lose some visibility and control over those assets/operations. When using external cloud services, the responsibility for some of the policies and infrastructure moves to the cloud service providers (CSP).

The actual shift of responsibility depends on the cloud service model(s) used, leading to a paradigm shift for agencies in relation to security monitoring and logging. Organizations need to perform monitoring and analysis of information about applications, services, data, and users, without using network-based monitoring and logging, which is available for on-premises IT.

1. On-Demand Self Service Simplifies Unauthorized Use. CSPs make it very easy to provision new services. The on-demand self-service provisioning features of the cloud enable an organization's personnel to provision additional services from the agency's CSP without IT consent. The practice of using software in an organization that is not supported by the organization's IT department is commonly referred to as shadow IT.

1. Due to the lower costs and ease of implementing PaaS and SaaS products, the probability of unauthorized use of cloud services increases. However, services provisioned or used without IT's knowledge present risks to an organization. The use of unauthorized cloud services could result in an increase in malware infections or data exfiltration since the organization is unable to protect resources it does not know about. The use of unauthorized cloud services also decreases an organization's visibility and control of its network and data.

1. Internet-Accessible Management APIs can be Compromised. CSPs expose a set of application programming interfaces (APIs) that customers use to manage and interact with cloud services (also known as the management plane). Organizations use these APIs to provision, manage, orchestrate, and monitor their assets and users. These APIs can contain the same software vulnerabilities as an API for an operating system, library, etc. Unlike management APIs for on-premises computing, CSP APIs are accessible via the Internet exposing them more broadly to potential exploitation.

Threat actors look for vulnerabilities in management APIs. If discovered, these vulnerabilities can be turned into successful attacks, and organization cloud assets can be compromised. From there, attackers can use organization assets to perpetrate further attacks against other CSP customers.

5. Separation Among Multiple Tenants Fails. Exploitation of system and software vulnerabilities within a CSP's infrastructure, platforms, or applications that support multi-tenancy can lead to a failure tomaintain separation among tenants. This failure can be used by an attacker to gain access from one organization's resource to another user's or organization's assets or data. Multi-tenancy increases the attack surface, leading to an increased chance of data leakage if the separation controls fail.

This attack can be accomplished by exploiting vulnerabilities in the CSP's applications, hypervisor, or hardware, subverting logical isolation controls or attacks on the CSP's management API. To date, there has not been a documented security failure of a CSP's SaaS platform that resulted in an external attacker gaining access to tenants' data.

No reports of an attack based on logical separation failure were identified; however, proof-of-concept exploits have been demonstrated.

1. Data Deletion is Incomplete. Threats associated with data deletion exist because the consumer has re duced visibility into where their data is physically stored in the cloud and a reduced ability to verify the secure deletion of their data. This risk is concerning because the data is spread over a number of different storage devices within the CSP's infrastructure in a multi-tenancy environment. In addition, deletion procedures may differ from provider to provider. Organisations may not be able to verify that their data was securely deleted and that remnants of the data are not available to attackers. This threat increases as an agency uses more CSP services.

Acceptance test plan

1. The cloud service providers (CSP) supports testing scalability: With a cloud-based platform, performance testing doesn't have to be with a restricted number of users, the testing can be more realistic with hits from the expected number of users.
2. The cloud service providers (CSP) supports Geographical Testing: Performance testing on a cloud can be done from any region, wherever the application is expected to be accessible, hence global scaling is also possible.
3. The cloud service providers (CSP) supports Production Apps/Systems: Most of the time, the testing is restricted to Staging or test environment, but with the use of cloud-based testing tools, testing can be done in a production environment also.
4. The test plan also covered performance tests based on the following tests:
   1. Stress Test
   2. Load & Performance Test
   3. Browser Performance Test
   4. Latency Test
   5. Failover Test
   6. Capacity Test
   7. Soak Test

Business impact analysis

A Business Impact Analysis for cloud computing or in house is a plan that must continuously be updated. A business impact analysis (BIA) is the cornerstone of a disaster recovery (DR) strategy and plan. A BIA will identify the processes, systems and functions that are critical to the survival of your company. Understanding these elements allows you to allocate resources wisely to ensure operations even with unexpected events disrupting normal business operations.

A business impact analysis is an analytic process that aims to reveal the business impacts that would result when a critical process exceeds its maximum allowable outage.

The following parameters are taken into consideration to develop a business impact analysis plan:

1. Get support from senior management for the exercise. You will then be able to meet with the operations-level managers that know enough detail about the processes to be helpful to the program. It's hard to get people's time and even harder to get follow up for a business continuity plan (BCP) without this support.

1. Hold a kickoff meeting with the managers responsible for the core business processes and introduce the program goals, timelines and deliverables.

1. Collect data. Implement a business impact analysis questionnaire, which you will distribute at the meeting to all managers. Instruct each manager on how to complete the document. Make it clear that you will be following up with each manager on an individual basis to review the document. See the sidebar to the left for more information about creating a BIA questionnaire.

1. Document the gross revenue and net profit your organization generates per year. This can be done at the appropriate business unit levels as well. The data sets the upper limit for business losses related to the business operation. Include this on your presentations to drive home the importance of the program.

1. Meet with each manager and review the data collected. If needed, block off a couple of hours to help com-plete and refine the document with the manager.

1. Merge all the data into a spreadsheet or database for easy data analysis and reporting capability.

1. Schedule and conduct a "BIA review and prioritization meeting" with all managers participating in the program. Look for gaps not mentioned by the departments, especially between departments. Prioritize each process based on impact to the business, both direct and indirect as the process may be critical dependency for another process. High, medium and low can be used as measures.

1. During the prioritization discussion you will need to document a recovery time objective (RTO) for each process. The RTO defines the time to return the process to normal operation before impact results to the business and is generally measured in hours.

1. Create groups or bands of process RTOs. Start with the shortest allowable RTO first and then define the upper limits not to exceed 24 hours. These items constitute the Tier 0 RTOs. The next band of RTOs is the Tier 1 group. This group generally extends from 24 to 48 hours. Recovery point objectives (RPOs) are different as they deal more with data recovery and are used more in a "data protection strategy" context. They are also usually measured in minutes to hours as in the case of a production database. It may have an RPO of 20 minutes between scheduled replications.

1. Lastly, convene a summary meeting to present the results of the program to senior management, managers and others core to the processes at the topic. You will want to present the business processes in order of RTO and importance, along with the other process details collected during the program. Issue a final report to meeting attendees to reinforce the learning and memory of the participants. Make the report available in hard copy to use in the event of an actual outage to help prioritize actions to resume operations.

Information technology security assurance specifications

This section provides a non-exhaustive list of Information technology security assurance specifications.

Not meeting any of the following information technology security assurance specifications does not necessarily mean that cloud computing cannot be used, it simply means that the security consideration requires additional contemplation to determine if the associated risk is acceptable.

Maintaining availability and business functionality

• My data or functionality to be moved to the cloud is not business critical.
• I have reviewed the vendor's business continuity and disaster recovery plan.
• I will maintain an up to date backup copy of my data.
• My data or business functionality will be replicated with a second vendor.
• The network connection between me and the vendor's network is adequate.
• The Service Level Agreement (SLA) guarantees adequate system availability.
• Scheduled outages are acceptable both in duration and time of day.
• Scheduled outages affect the guaranteed percentage of system availability.
• I would receive adequate compensation for a breach of the SLA or contract.
• Redundancy mechanisms and offsite backups prevent data corruption or loss.
• If I accidentally delete a file or other data, the vendor can quickly restore it.
• I can increase my use of the vendor's computing resources at short notice.
• I can easily move my data to another vendor or inhouse.
• I can easily move my standardised application to another vendor or inhouse.

Protecting data from unauthorised access by a third party

• My choice of cloud sharing model aligns with my risk tolerance.
• My data is not too sensitive to store or process in the cloud.
• I can meet the legislative obligations to protect and manage my data.
• I know and accept the privacy laws of countries that have access to my data.
• Strong encryption approved by the ACSC protects my sensitive data at all times.
• The vendor suitably sanitises storage media storing my data at its end of life.
• The vendor securely monitors the computers that store or process my data.
• I can use my existing tools to monitor my use of the vendor's services.
• I retain legal ownership of my data.
• The vendor has a secure gateway environment.
• The vendor's gateway is certified by an authoritative third party.
• The vendor provides a suitable email content filtering capability.
• The vendor's security posture is supported by policies and processes.
• The vendor's security posture is supported by direct technical controls.
• I can audit the vendor's security or access reputable third party audit reports.
• The vendor supports the identity and access management system that I use.
• Users access and store sensitive data only via trusted operating environments.
• The vendor uses endorsed physical security products and devices.
• The vendor's procurement process for software and hardware is trustworthy.

Protecting data from unauthorised access by the vendor's customers

• The vendor adequately separates me and my data from other customers.
• Using the vendor's cloud does not weaken my network security posture.
• I have the option of using computers that are dedicated to my exclusive use.
• When I delete my data, the storage media is sanitised before being reused.

Protecting data from unauthorised access by rogue vendor employees

• The vendor does not know the password or key used to decrypt my data.
• The vendor performs appropriate personnel vetting and employment checks.
• Actions performed by the vendor's employees are logged and reviewed.
• Visitors to the vendor's data centres are positively identified and escorted.
• Vendor data centres have cable management practices to identify tampering.
• Vendor security considerations apply equally to the vendor's subcontractors.

Handling security incidents

• The vendor is contactable and provides timely responses and support.
• I have reviewed the vendor's security incident response plan.
• The vendor's employees are trained to detect and handle security incidents.
• The vendor will notify me of security incidents.
• The vendor will assist me with security investigations and legal discovery.
• I can access audit logs and other evidence to perform a forensic investigation.
• I receive adequate compensation for a security breach caused by the vendor.
• Storage media storing sensitive data can be adequately sanitised.

Relevant statutory documentation

Cloud computing (IT and software-as-a-service) arrangements are a form of outsourcing. They may be for storage or other online services like Office 365, DropBox and Google Drive.

Arrangements may be agency wide or specific to 1 or 2 people for a particular application or piece of software.

Your agency is legally responsible for records it creates or stores in the cloud. You need to make sure you can meet your legislative obligations when it comes to capturing, managing and disposing of public records.

You can read more information through the following weblinks

You must ensure com-plete and reliable records of your business activities are created, kept, managed and lawfully disposed of.

Consider your legal obligations in Australia and the legal issues and requirements if a service provider is in a different state or country.

Service providers based or registered internationally are subject to the laws of that country, and possibly the laws of other jurisdictions. These laws may apply to the information and records they store or manage on your behalf, even if that information is stored in Australia.

Your agency's legal team may need to:

• ensure the agreement includes provisions covering legislation that may impact on the agreement
• take into account possible differences in similar pieces of legislation (e.g. US Privacy Act vs. Australian Privacy Act), legal interpretations and standard contracts.

Impact analysis report

• Include the following information:

• Executive summary

Describe the key information for decision making

Scope of impact analysis.

Key findings.

Recommendations

• Scope of impact analysis

Describe clearly the scope and the purpose of the evaluation

• Findings

The findings of the impact analysis address the following in response to the key questions of the impact analysis

• Lessons learned

The lessons learned could be analyzed and should specify the following questions:

Which lessons learned were distilled from the impact analysis of the project?

Could these lessons be utilized as best practices in other business areas?

• Recommendations

Make clear recommendations that can be implemented:

Each recommendation must be from a previous evaluation

Priorities will be identified for the implementation of recommendations