You can find the first part of the article here.
Detect
Detection is where most of the fun stuff happens. Your systems (we will discuss them shortly) constantly analyze logs, monitor network activities, and look for suspicious behavior. They generate an alert if they spot anything and hopefully you have some very skilled and smart engineers who will react fast and efficiently. Yeah, I understand the second part is a bit tricky. Because we all have other work to do and we never know when this security alert will come. The most common scenario is when you have an on-call/on-duty schedule.
Now let’s dive into the tools and systems that will help you detect the intruders and deal with them so they get what they’ve deserved.
Most of the instruments can be scanning (and sometimes preventing) either application-level breaches or network (or both).
At the application layer, you could use:
- Dynamic Application Scanners (DAST).
- Static Application Scanners (SAST).
- Software Composition Analysis Scanners (SCA).
- Interactive Application Scanners (IAST).
- Runtime Application Self-Protection Scanners (RASP).
Manual code reviews are also proven to be a powerful security instrument if done right. If you’re not yet doing it, I’d highly recommend starting doing code reviews. They are instrumental from many perspectives.
Network vulnerability scanners can be:
- Agentless scanners.
- Agent-Based Scanners and Configuration Management.
As for the tools, here is a list of some I find to be useful and common enough for the cloud environment.
Many popular forensic toolsets, such as Encase and FTK, now have some cloud capabilities.
I recommend that you go through the following steps in the order listed:
- Draw a diagram of your application, with trust boundaries.
- Make sure that your inbound connections use TLS, and that all component-to-component communications that may go across the wire use TLS with authentication.
- Enforce a perimeter and internal segmentation, and provide a secure way for your administrators to manage the systems via a bastion host, a VPN, or another method offered by your cloud provider.
- Set up a web application firewall, RASP, and/or IDS/IPS, if appropriate.
- Set up DDoS protection if appropriate.
- Set up at least limited egress (outbound) filtering.
- Check all of these configurations regularly to make sure they’re still correct and useful. Some cloud providers provide services to check configurations (AWS Config, etc).
The toolset and security measures should build a solid basis for you to be able to detect the malware and unusual activities that potentially could turn out to be an attack. Now you have to think about how you will respond.
Respond
When your security scanners detected unusual and suspicious activity, the security team should be notified. Right, there should be a security team. In general, I would recommend having SecOps in your team working full-time basis. Often companies would either delegate security to DevOps and QA/Dev folks or hire a security company. The second case is better, but also more expensive. Depending on how likely your data and/or operations could become interesting to attackers there are a few scenarios:
- You have a contract with a security company that will be responsible for the security of your data and systems. That means they will install all necessary tools and equipment and have dedicated people monitoring and reacting in case if they notice a high probability of an attack. This might be due to the compliance requirement or due to the fact that security is definitely not a crucial part of the value stream of your organization.
- You have a SecOps person or team responsible for the security of your data and operations. You also have a contract with a security company that performs security testing and audit from time to time. Such a company can help you in case if you spot an attack. This is a recommended set-up, which will be efficient from the cost/benefit perspective.
- You hire and train a strong security team (or multiple teams). You establish authority and knowledge schema to make sure no one has all keys, you train them well and pay them well.
Apart from people focused on security, it is recommended that you create a contact list with people from the engineering, legal, HR, and communications departments. These are people whom the security team will involve during the attack. Engineering person or people will help identify the areas and ways your system most likely will be attacked. And provide valuable insights on how the attack can be eliminated or blocked. People from legal will help with questions regarding contracts, compliance, and regulations. HR will help identify if there is an insider threat and deal with it.
You can also think about all stakeholders you should notify and work with in case anything happens (customers, government, publicity, etc.)
It is important to have clear plans that are concrete and accepted/acknowledged by everyone in your team. In general, the plan would consist of 3 groups of activities:
- Observe,
- Orient,
- Decide,
- Act.
Respond actions
Observe is about monitoring and we’ve spoken about this earlier. I should stress here that it is particularly important to pay attention to everything that is going on with privileged users. As they are the likely target for the attackers. Work with logs and try to spot some patterns that could indicate the attack signature. This is the right time to mention the term “Kill chain”. This term aggregates some tactics attackers have used during some famous attacks in the past. I recommend the book called “The Unified Kill Chain” written by Paul Pols. The author analyzed the famous attacks and generated typical flow as described in the picture below:
He also added the extra step of Network Propagation which is relevant for a complicated systems breach. In this case, attackers initially find a foothold in a demilitarized zone, explore and find their way behind the secured perimeter.
- When your team has spotted the suspicious activity they should first aim to understand what is the plan and the possible aim of the attackers. And how far are they in their plan? In some famous cases, the attackers had access for months. So it is good to understand what is going on before the attackers will know you know they’re here.
- When you understand the target and the plan (or you think you understand) it is time to act. It usually requires blocking access and securing the data. The security team will block access, change network topology, move or even delete data. The actions required depend on the specifics of the asset you’re protecting and the intent of the attack.
- At the same time, you might want to come up with explanations of what is going on for your users, community, and other stakeholders. Usually, I wouldn’t recommend trying to keep this information secret. Only if there is a good reason to hide it you should hide it. Like for example, this could provoke users to start some transfers that will create chaos and help the intruders.
- During the protective activities, your team should also think about forensics. You will need evidence for the analysis and legal procedures later.
- When you’ve successfully blocked the attack, now it is time to recover. At this point, it is hard to provide general suggestions. Because cases could be very different. In some cases, you just change passwords or privileged access schemas, while in others you would have to delete the data and completely shut down the compromised infrastructure. So it depends.
What I would recommend doing is to perform a security audit to find all the vulnerabilities in the system.
Because if you’re not shutting down and rebuilding the system from scratch – attackers may come back. And they might have a good understanding of the vulnerabilities of the system. Even if you decide to shut down and recreate a system, you should consider the mistakes in order to prevent problems in the future.
I really hope these two articles were useful for you! And please let me know in case you have any questions or comments.
