Incident Response in the Age of Cloud

Techniques and best practices to effectively respond to cybersecurity incidents

Dr. Erdal Ozkaya

• Publisher: Packt Publishing
• Year: 2021
• ISBN:
  9781800569928
• Edition: 1
• Topic: Computer Science
• Subtopic: Cyber Security
• Index: Computer Science

Learn to identify security incidents and build a series of best practices to stop cyber attacks before they create serious consequences

Key Features

• Discover Incident Response (IR), from its evolution to implementation
• Understand cybersecurity essentials and IR best practices through real-world phishing incident scenarios
• Explore the current challenges in IR through the perspectives of leading experts

Book Description

Cybercriminals are always in search of new methods to infiltrate systems. Quickly responding to an incident will help organizations minimize losses, decrease vulnerabilities, and rebuild services and processes.

In the wake of the COVID-19 pandemic, with most organizations gravitating towards remote working and cloud computing, this book uses frameworks such as MITRE ATT&CK® and the SANS IR model to assess security risks.

The book begins by introducing you to the cybersecurity landscape and explaining why IR matters. You will understand the evolution of IR, current challenges, key metrics, and the composition of an IR team, along with an array of methods and tools used in an effective IR process. You will then learn how to apply these strategies, with discussions on incident alerting, handling, investigation, recovery, and reporting.

Further, you will cover governing IR on multiple platforms and sharing cyber threat intelligence and the procedures involved in IR in the cloud. Finally, the book concludes with an "Ask the Experts" chapter wherein industry experts have provided their perspective on diverse topics in the IR sphere.

By the end of this book, you should become proficient at building and applying IR strategies pre-emptively and confidently.

What you will learn

• Understand IR and its significance
• Organize an IR team
• Explore best practices for managing attack situations with your IR team
• Form, organize, and operate a product security team to deal with product vulnerabilities and assess their severity
• Organize all the entities involved in product security response
• Respond to security vulnerabilities using tools developed by Keepnet Labs and Binalyze
• Adapt all the above learnings for the cloud

Who this book is for

This book is aimed at first-time incident responders, cybersecurity enthusiasts who want to get into IR, and anyone who is responsible for maintaining business security. It will also interest CIOs, CISOs, and members of IR, SOC, and CSIRT teams. However, IR is not just about information technology or security teams, and anyone with a legal, HR, media, or other active business role would benefit from this book.

The book assumes you have some admin experience. No prior DFIR experience is required. Some infosec knowledge will be a plus but isn't mandatory.

15

Ask the Experts

You have finally reached the last chapter of the book. This chapter has not been written by me, but instead by a selection of very well-known Incident Response (IR) experts, some of whom work at Fortune 500 companies like Microsoft, Sony, and Standard Chartered. In this chapter, they have shared their perspectives with you as guest authors in my book. With more than 300 years' experience between them, I am sure you will enjoy reading and learning from this chapter as much as I did.

So that you can navigate this chapter in an order of your choosing, we have divided the contributions into four broad topics, which are as follows:

• Approaches to IR
  • Orin Thomas – Cloud security requires an updated mindset
  • Tyler Wrightson – Know thy enemy
  • George Balafoutis – The acronym that should be in every CISO's vocabulary
  • Yilmaz Degirmenci – Cybersecurity visibility analysis: a soldier's analysis
• IR in the cloud
  • Brian Svidergol – Incident response fundamentals
  • Mark Simos – The cloud transformation journey
  • Hala ElGhawi – Cloud incident management and response
  • Ahmed Nabil – Incident response in the cloud
• Tools and techniques
  • Emre Tinaztepe – The case: a modern approach to DFIR
  • Raif Sarica and Sukru Durmaz – Remote incident response with DFIR
  • Santos Martinez – Protecting corporate data on mobile devices
  • Ozan Veranyurt – Artificial intelligence in incident response
• Attack methods
  • Gokhan Yuceler – Analyzing a target-oriented attack
  • Grzegorz Tworek – Windows object permissions as a back door

You can open this chapter at any given point, at a section that interests you—although, of course, we recommend reading all of the expert opinions in this chapter, as they will all add immense value to your approach to IR!

Approaches to IR

Orin Thomas – Cloud security requires an updated mindset

Thinking about the security of cloud workloads requires a fully updated mindset to how we think about the security of on-premises workloads. Cloud workloads are intrinsically different from on-premises workloads. If the history of the inclusion of the OSI model in networking textbooks is an example, it's likely that future students of cloud security won't start with learning about how to secure workloads in cloud environments, but instead will begin building their cognitive models of cloud security using conceptual frameworks developed on-premises.

Let me elaborate.

At some point in your education about networking, you learned about the OSI model. Whilst you might excuse that by pointing to the fact that people were still using VCRs when you learned about networking, students of networking today, in the 2020s, also learn about the OSI model, usually right at the beginning of the class. If you spend some time thinking about it though, teaching this model doesn't really make sense. It doesn't make sense because the OSI model was never adopted and it would be challenging to find any networks built this century that use anything other than Internet Protocol suite protocols. It would make more sense to explain networking using the model that has been used for more than 40 years, the Internet Protocol suite model.

The Internet Protocol suite model was developed in the 1970s and adopted by the US Department of Defense in 1982. It's a practical model and the protocols it models and represents have been used in some manner for more than four decades. Instead, what still happens in most introductory networking classes is that they start with the OSI model and once students comprehend it, then attempt to explain Internet Protocol suite protocols by mapping them onto the OSI model.

So what does trivia about networking models have to do with cloud security? The fact that the OSI model is still taught shows us that ways of thinking about complex concepts have inertia. We teach networking in that way because we've always taught it that way. Once a concept embeds itself widely in textbooks, it can be very hard to dislodge. I wouldn't be surprised if the OSI model is still taught to networking students several decades from now.

How most people will think about cloud security in the future will be based on how most people were taught to think about on-premises security in the past. When teaching people about securing cloud workloads such as serverless applications, I'm often asked "how do we configure a firewall to only allow access from a known range of IP addresses and ports?". In that example, the student is thinking about securing the workload running in the cloud using the same toolkit that they would think about securing a workload running on an on-premises perimeter network with. Even though you'll have another student pipe up with "identity is the new security control plane," when it comes to security, we often fall back on what worked for us in the past rather than updating our toolkit to function properly with cloud-based environments, rather than outdated on-premises security assumptions.

It is crucial to update and modernize your approach to cybersecurity to be relevant to the cloud. That doesn't mean that you sometimes won't use the same tools on-premises and in the cloud, but what it does mean is that you need to think about security from a cloud-first perspective. If you don't update your conceptual toolkit and core cybersecurity principles to succeed in cloud environments, the clever attackers who are always probing your cloud workloads will successfully leverage that against you.

About Orin Thomas

Orin has written more than 40 books for Microsoft Press. A recognized cloud and datacenter expert, he has authored video-based training for Pluralsight and instructor-led training for Microsoft Learning on datacenter and cloud topics. He is experienced at presenting at in-person events as well as in online seminars. He is completing postgraduate research at Charles Sturt University focused on cloud security compliance accreditations.

Tyler Wrightson – Know thy enemy

When I was initially asked to write this chapter, I immediately knew what I could share and I was excited to do so.

My recommendation for all incident responders is to know thy enemy. Never forget that there is another human (or group of humans) on the other end of the incident you are responding to or investigating. Knowing your enemy may seem a little obvious at first, but it is nuanced and important enough to explore further.

First, your enemy is ever-changing, thus your understanding and knowledge of your enemy should be too. Understanding your enemy tomorrow will be different from today, which will likely be very different six months from now. Second, your knowledge of your enemy is not binary, meaning you don't simply understand your enemy or not. Instead, you understand your enemy on a spectrum, from zero knowledge to a complete or holistic understanding. Striving to constantly learn and adapt as your enemy adapts will be paramount for your effectiveness as an incident responder.

Let's dig deeper into this concept of knowing your enemy. First and foremost, you must embrace the fact that at no point are you battling a computer or software. Until the day we have AI creating malware and viruses (which, mark my words, is coming), your adversary is a human or a group of humans. Again, I think this bears repeating, software is not your enemy. Instead, software (malware, viruses, and so on) are agents or vehicles of your enemy.

How does this impact you as an incident responder? It's simple. It seems that too many incident responders focus on the technology and forget the huge impact and implications of the threat actors involved. Should you ignore how a specific piece of malware works or the actions it is attempting to perform? Of course not. However, it seems that technology is the focus of most incident responders—they have backgrounds in technology, they are good with technology, and therefore they focus on technology.

So, in addition to your investigation and analysis of any software, IOCs, or artifacts that you are investigating, be sure to try and understand the human adversary in your investigation. Specifically, you should seek to understand the following:

• Level of skill
• Previous tactics—entire kill chain; Tactics, Techniques, and Procedures (TTPs)
• Motives or agenda—intentions or plan to execute

Not only should you seek to understand and define these in any incident, but you should continually research and refine your understanding of threats between incidents.

Level of skill

Understanding the level of skill of your adversary based solely on your investigation can be a tricky thing. It is best to understand that just as understanding your enemy is not binary, their level of skill is not binary either. A hacker is not simply highly skilled or unskilled. Nor are they simply sophisticated or unsophisticated. Instead, their skill exists on a spectrum; you could even understand it as multiple spectrums in various areas, domains, or sections of the kill chain.

As an example, if you were to define the level of skill of the NSA, you'd likely say that they are highly skilled. However, as you've seen, some of their operations security (OPSEC) was relatively bad, resulting in the public release of many of their tools. Or you could say that an attacker using a zero-day exploit as their initial beachhead into a network is highly skilled, only to find that they fumbled the access they had obtained once inside the network.

If all of this is true, how does understanding their skill level assist you in responding to incidents? It simply helps you to paint a clearer picture of your adversary, how to respond to the current incident, and how they might attempt to attack your organization again in the future.

Let's look at some of the criteria for understanding the level of skill or sophistication of an attacker:

• The age of the vulnerabilities exploited
• The age of the exploits utilized
• How common/esoteric is the vulnerability?
• The targeted nature of attacks

The age of the vulnerability being exploiting can be very telling. If it's a zero-day, with no relevant "chatter" on the internet, then you are most likely not dealing with a complete novice. Many people fall into the trap of thinking that any zero-day vulnerability requires a high level of skill, however, that is simply not true. There is far more context needed to understand the level of sophistication than simply whether or not your adversary is exploiting a publicly known vulnerability.

An exploit that takes advantage of a zero-day vulnerability in the bleeding-edge version of one of the major internet browsers—that could require a high level of skill. An exploit that takes advantage of a zero-day vulnerability in a new ubiquitous IoT device may actually require a lot less skill than you think!

...