Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New cheat sheet: Incident Response for Web Applications. #1468

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
97 changes: 97 additions & 0 deletions cheatsheets/Incident_Response_for_Web_Applications_Cheat_Sheet.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,97 @@
# Incident Response for Web Applications Cheat Sheet
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to start off with a confession. IR is not my field of expertise; AppSec is. And while I've worked alongside of people in IR teams (mostly on the digital forensics side of things), I still have relatively little direct experience except what I've absorbed in 25+ years of working with these teams. So take everything you read that I'm commenting on with a huge grain of salt. I am NOT an expert. (If fact, I almost told @szh "no; I don't think I'm qualified to review this".)

Anyway... when I first read this title, I was thinking to myself "what about REST APIs?" Shouldn't they be included, since from an IR perspective, they're not that much different. However, after I read though this, I don't see why you've added the "for Web Applications" at all. This covers way more than HTTP based stuff.

Until we flesh out this skeleton those, I might call it "Incident Response for Beginners Cheat Sheet". Once we add more details, we can drop the "for Beginners".


## Introduction

Incident response is a crucial aspect of web application security, ensuring swift and effective actions are taken when security incidents occur. This comprehensive cheat sheet provides technical guidance for handling incidents throughout the entire lifecycle.

## Common Security Issues

### 1. Incident Detection

- Utilize robust logging mechanisms to capture relevant security events. \
Enable verbose logging: `LogLevel debug`
<!-- textlint-disable terminology -->
- Implement intrusion detection systems (IDS) for real-time monitoring. \
Snort IDS rule example:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that we are OWASP, wouldn't it be better if we had an example with mod_security CRS instead of Snort?

`alert tcp any any -> $HOME_NET 80 (msg:"Possible SQL injection attempt"; content:"SELECT * FROM"; sid:1000001;)`
<!-- textlint-enable -->
- Employ anomaly detection algorithms to identify unusual patterns in user behavior. \
Python script for anomaly detection:
`from sklearn.ensemble import IsolationForest`

### 2. Analysis and Triage

- Establish an incident response team (IRT) with roles like Forensic Analyst, Malware Analyst, and Incident Coordinator. \
Incident Response Team (IRT):

- Forensic Analyst: Conducts digital forensics investigations.
- Malware Analyst: Analyzes malicious code and artifacts.
- Incident Coordinator: Coordinates overall incident response efforts.
- Leverage digital forensics tools for in-depth analysis of affected systems. \
Use Autopsy for disk analysis: `autopsy -i <image_path>`
- Conduct memory analysis to identify malicious processes and artifacts. \
Volatility framework example:
`vol.py -f <memory_dump> --profile=<profile> pslist`

### 3. Containment and Eradication

- Isolate affected systems to prevent lateral movement. \
Network isolation using iptables: `iptables -A INPUT -s <infected_IP> -j DROP`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few things:

  1. Using iptables is likely to confuse a lot of people, especially those only using Windows of BSD (and thus use pfsense).
  2. Only old school Linux system administrators probably still use iptables. Now they likely use either nft (for nftables) or ufw.
  3. When I see something referencing iptables, I usually think of (Linux) host-based firewalls, not a firewall appliance. Host-based firewalls is probably not the place you want to do this from because there are just too many hosts.
  4. Definitely want to log the dropped packets as well. Generally there will already be a rule for that, but it's probably worth mentioning.

For that reason, I would suggest rewriting this something along these lines:

  • Configure your all your relevant network appliance firewalls to drop and log all packets originating from any known compromised IP addresses.

- Employ network segmentation to contain the spread of the incident. \
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And if you had led with this, I probably wouldn't have bothered to write out all the details of my previous comment. With this in place, if you want to supplement this network segmentation with additional host-based firewalls for high value target hosts, it may make sense.

VLAN configuration example: \
`switchport mode access` \
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not everyone uses Cisco IOS for this, so since YMMV, I'd recommend using English-based description here. For example "Segment the traffic of the suspected compromised IPs onto their own VLANs".

`switchport access vlan <segment_ID>`
- Use endpoint detection and response (EDR) tools for real-time threat containment. \
Carbon Black sensor commands: `cbresponse -th <threat_hash> -d`
- Eradicate malware and backdoors using antivirus tools and manual inspection. \
ClamAV scan for malware: `clamscan -r /path/to/scan`

### 4. Recovery

- Develop a recovery plan outlining steps to restore services securely. \
Recovery Plan:

1. Restore from clean backups.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there should be a 'step 0' here. Something like:

0.  If you have a 'Disaster Recovery plan' for the compromised services, now is the time to dust if off and follow it. If you don't have a DR plan, perhaps a Business Recovery plan? If you don't have either, then follow the remaining steps in this section instead.

Then add to '1. Restore from clean backups.' something like "If you don't have recent clean backups, re-install your operating system from scratch, followed by re-installing your applications."

2. Validate the integrity of restored data.
3. Monitor network traffic for signs of re-infection.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before you do this, I think you need to undo the steps you did in Section 3 "Containment and Eradication".

- Monitor network traffic for signs of malicious activity during the recovery phase. \
Wireshark filter for suspicious traffic: `tcp.flags == 0x02 && ip.src != trusted_IP`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems naive. You may have something like a 10.0.0.0/8 CIDR block that is "trusted" in the sense that they are all on your intranet. So in that sense trusted_IP is probably too broad even if you use CIDR notation. However, what you really want to monitor is anything outside the expected range of direct connections that anticipate your application is expected to connect to. If you know what your egress rules are / supposed to be, you can leverage that. Otherwise, good luck.

Also, long term, I'd probably use tcpdump and just create a pcap file you can analyze later. After going through an incident where you spent all night restoring systems and trying to figure out what the hell just happened, no one is going to want to spent an extended amount of time babysitting Wireshark. I'd watch if for maybe 15 to 30 minutes and if nothing interesting pops up, run tcpdump instead as it has less overhead. But maybe that's just me. Like I said, I am not an expert. Heck, I didn't stay at a Holiday Inn last night. 😄

- Validate data integrity to ensure recovered systems are not compromised. \
File integrity validation using md5sum: `md5sum -c integrity_checksums`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MD5? Come on. Really? Collisions could truly come into play here if you are attacked by a Nation State actor. Ditto SHA1. Should at least use sha256sum here.

Of course, the bigger concern is that you actually have an offline copy of 'integrity_checksums' file that you can trust. If you only had an online copy stored on the compromised server, you're probably SOL unless you had a SHA256 digest of that file stored offline and you have a way to verify your checksum file.


### 5. Lessons Learned

- Conduct a thorough post-incident analysis (PIA) to identify vulnerabilities and weaknesses.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You call it PIA, but it's generally what the rest of the world calls root-cause analysis or sometimes a postmortem.

However, if we really want a new acronym, how about 'post-incident trauma analysis' (PITA)? 😜

- Update incident response plans based on PIA findings.
- Provide training sessions for the incident response team to enhance skills.

## Incident Response Objectives

### 1. Incident Response Plan

- Develop a detailed incident response plan (IRP) specific to web application security.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, this CS does not seem specific to 'web applications', so I'd drop that and maybe just change it to cyber-security.

- Define communication protocols, including secure channels for incident reporting.
- Establish clear escalation procedures for different types of incidents.

### 2. Communication Strategies

- Establish a communication hierarchy to disseminate incident information efficiently.
- Draft incident notification templates for internal and external stakeholders.
- Implement secure communication channels, considering encrypted email and secure messaging apps.

### 3. Evidence Preservation
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You better well have thought of this LONG before now, unless you don't intend prosecution of the perpetrators of the current incident exercise you've been discussing (assuming they are ever caught), as chain-of-custody in handling evidence is extremely important to winning a court case whether it be criminal or civil litigation.


- Document incidents thoroughly, preserving logs, screenshots, and memory dumps.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea to video tape the process as well.

- Ensure compliance with legal and regulatory requirements for evidence preservation.
- Implement digital chain-of-custody procedures for all collected evidence.

### 4. Quick Incident Identification and Response

- Implement automated incident detection through security information and event management (SIEM) tools.
- Conduct regular incident response drills to enhance team readiness and response times.

## Technical References

- [Invicti Incident Handling Guide](https://www.invicti.com/blog/web-security/incident-response-steps-web-application-security/)
- [Wire 19](https://wire19.com/incident-response-plan-for-website/)
- [Tech Target](https://www.techtarget.com/searchsecurity/definition/incident-response)
Loading