Know your enemies - this is the title of an almanac on targeted complex attacks published by the Institute for Critical Infrastructure Technology in November 2015. According to microblogger William Nizzle, the handbook reveals "everything you need to know about APTs" (Advanced Persistent Threats = targeted complex attacks). The primer provides a readable insight into the actors, targets and backgrounds of today's most active APT groups and the currently most important known attack vectors. This information is very useful when it comes to designing and validating possible threat scenarios for your own company - the basis of any effective incident response strategy. However, no manual in the world can answer the question of what the individual course of action should be, only each organization can decide for itself!

There is no doubt that the digital transformation has triggered a paradigm shift in companies: for reasons such as efficiency, agility and scalability, it makes sense to no longer provide all processes in your own IT, but to continue to control and manage them. However, companies should not fall into the trap of assuming that the use of cloud services means that responsibility for the security of their data is transferred to the provider alongside data or processes. Rather, the different models of cloud services and architectures lead to the principle of shared responsibility between the cloud-using company and the provider - especially when it comes to defending against targeted, complex cyber attacks in the form of an incident response strategy.

This is one of the reasons why IT managers should be aware of the access and design options of the various types of cloud services and carefully consider which data is most secure in which cloud and where incident response activities should be carried out under their own control - or whether the cloud-using company must rely on the provider in this regard.

Actively dealing with risks

The incident response strategy - i.e. the structured response to a security incident - is one of the reactive IT security measures that are just as relevant as proactive measures (e.g. the implementation of an information security management system - ISMS for short - or security architecture design). The aim here is to

• to actively manage the consequences of an attack in a focused manner, i.e. to limit potential damage,
• shorten the recovery time for data, processes and systems as much as possible and
• keep the costs for the entire process as low as possible.

The basis for effective incident response is the definition of what the organization understands by a security incident and which process steps are to be followed when dealing with the incident. The second step is to implement an appropriate strategy. The basis for this is the automated detection of security incidents - through the use and effectiveness of technical tools for monitoring in order to detect the "one important signal in the background noise". It is also important to define the point of escalation at which a targeted defense - if necessary by using external experts - is essential.

Regardless of whether the IT is installed locally or operated in the public, private or hybrid cloud, the key question for a successful incident response is always the same: Is it possible to actively monitor the events in the infrastructure itself or does the cloud-using company have to trust the provider to do this on its behalf?

An effective incident response: the ideal process

In the event of security incidents, it may make sense to temporarily take certain services offline. This is why it is so important that the company itself has access to the infrastructure - to avoid losing valuable time.

© Fotolia, kirill_makarov

The requirements for targeted incident responses are complex. In a nutshell, the ideal process is as follows: detect, analyze, qualify, combat. A company with effective incident response structures should be able to collect new findings and use them for analysis purposes in order to be a learning organization within the dynamic threat situation. For example, there should be access to internal or external expertise and resources in order to be able to evaluate and qualify reports and data promptly:

• Is it a false alarm or a targeted attack?
• Which data sources are available?

Finally, the incidents must be prioritized, correlated with the available data sources and evaluated with regard to the infrastructure. It is also necessary to check whether adjacent systems may be affected. These are questions that require expert know-how and appropriate technological analysis systems.

To combat the damage, all affected security systems must be adapted accordingly and workarounds developed so that the organization returns to normal. The infection is investigated and combated in the background, so to speak, and then analyzed in detail. Following this, a vulnerability analysis of the affected systems is recommended as well as preventive measures to prevent further attacks with analogous attack vectors. Measures and continuous monitoring in the hybrid cloud are heavily dependent on the infrastructure in which the company operates.

Which tasks the parties involved take on and to what extent depends less on the access characteristics of the public, private or hybrid cloud structures and more on the responsibility in the technological types of cloud services. Because the key questions for incident response are: Can attacks be detected at all? If so, who takes on this complex task? And finally, what options does the cloud-using company have to take countermeasures itself? Below is an overview of the respective scope of action within the various cloud services.

IaaS versus PaaS versus SaaS

An effective incident response strategy should take into account the special features of the individual cloud services. The radius of action for cloud-using companies is not the same everywhere.

© Fotolia, fotohansel

Infrastructure-as-a-Service (IaaS) offerings are the ideal environment for incident response, as the user retains control over their own systems even in the public area of their cloud. They are responsible for the selection, installation, operation and functioning of the systems used - and therefore also for the IT security of operating systems, for applications and their own services, for data encryption and for ensuring the integrity of the systems through to identity and access controls at system and application level. The user can therefore decide on their own initiative about the use of sensors for the operating systems - even if they are located in the public cloud.

At system level, a connection is made either to the in-house Security Information and Event Management (SIEM), or the sensors that track network traffic are installed in all virtualized computer hardware resources such as computers, networks and storage, so that monitoring can be combined. Access to the system infrastructure is the basis for countermeasures in the sense of incident response, for example by deactivating services or taking servers out of operation in order to take further hardening measures or to take forensic action. As this is only possible to a limited extent at network level for the cloud-using company, as the provider generally does not allow access to its physical network infrastructure, it is recommended that the provider and the cloud-using company pursue a joint response strategy and actively share their findings from the physical network area and system monitoring within the cloud. However, coordinated emergency plans and defined escalation procedures are required to ensure that incidents are processed promptly and efficiently.

Platform-as-a-Service - PaaS for short - provides programming or runtime environments with flexible, dynamically adaptable computing and data capacities. Within PaaS, the cloud-using company develops its own software applications or has them executed within a software environment that is provided and maintained by the service provider. As the company can implement the logic for detecting attacks in the application provided by the provider or at least collect important event data, it would ideally have access to valuable information for detecting a security incident.

Here, too, it does not make sense to maintain different systems for consolidating incident information. This raises the immediate question of integration into the company's own SIEM. For PaaS, which are based in a hybrid cloud structure on their own infrastructure, the full range of countermeasures is available. This is a problem for the public cloud component because there is no access to the system infrastructure; information about incidents therefore primarily comes from an application operated on the PaaS. An incident response is mainly based on coordination and dependency on the provider. Therefore, without information from the provider, the user has no rational basis for deciding, for example, to take services off the network.

Finally, with Software-as-a-Service (SaaS), the user has access to software groups or application programs. The applications run in the public cloud shares on the infrastructure of the SaaS service provider. The user only has access to the application, for example via a web front end, but not to the underlying network structures - and therefore no chance of meaningfully integrating the monitoring of the computing infrastructure. However, this would be an essential prerequisite for adapting the incident response strategy in individual cases. The fact that with SaaS, the provider is responsible for the IT security of the underlying infrastructure means in plain language for the cloud-using company: no implementation of its own sensor technology, thus no tapping and no detection options, and therefore only very limited incident responses of its own.

In the SaaS environment, cloud users therefore cannot avoid the monitoring and security measures of a 'Cloud Access Security Broker' (CASB) if they want to operate effective incident response themselves. CASBs are locally installed or cloud-based security solutions that are placed between the cloud-using company and the cloud service provider. CASBs enable transparent monitoring of access to cloud services and the implementation of technical guidelines in the areas of malware prevention, authentication, encryption and data leakage prevention (DLP).

Access monitoring by the CASB allows cloud users to extend monitoring at network level to the SaaS service and integrate it into their own systems. The CASB enables sensible countermeasures such as the situational blocking of access in the event of an incident, the establishment of DLP mechanisms or the tightening of their rules. Beyond that, the only option is to work closely with the provider. To assess which incidents and threats the cloud-using company is currently exposed to, it is helpful to combine the information from the infrastructure and from the CASB in a separate monitoring system. This forms the basis for analysis and effective countermeasures.

Sharing responsibility responsibly

Cooperation between the two parties in accordance with the shared responsibility principle requires that the cloud-using company agrees with the provider in advance which monitoring measures the provider will implement and which information the cloud user will receive on potential security incidents that are required for assessment, analysis and handling. Depending on what data the provider intends to deliver and to what extent the cloud user trusts that the data will actually be delivered, the incident response strategy must include monitoring and technical capabilities. For the proportion of a hybrid cloud within its own company, the cloud-using company can independently record security incidents and roll out the full range of countermeasures. The higher the proportion of infrastructure in the public cloud that is not administered independently, the more essential additional measures become.

In a nutshell: Cloud users should be aware of which additional technologies are essential for security and incident response in the cloud (e.g. CASB). This means that all information must be recorded in separate incident management procedures. This also includes systematically documenting all information from and agreements with the provider. In principle, the same roles should be provided for the operation of the hybrid cloud as for local IT. Depending on which access to the infrastructure is possible, this can extend to the administrator of a system. At the same time, the company using the cloud should always make agreements with the provider for the outsourced parts and be aware that there is always a certain dependency on the provider.

Author:
Dr. Daniel Hamburg is a cloud expert at TÜV Rheinland.