New cheat sheet: Incident Response for Web Applications. #1468
Conversation
Credit goes to @aditya6298 for creating it, I'm just making the PR.
New abbreviation used in Incident Response for Web Applications Cheat Sheet.
…Web_Applications_Cheat_Sheet Adding "IDS" to `.textlintrc` did not work. The terminology dictionary appears to be case insensitive, and whichever came first of "IDs" and "IDS" would cause the other form to fail.
|
That took care of the "IDS" issue! Now there's a new error: Also do you mean "Short" instead of "Snort"? |
Lint failed with: `cheatsheets/Incident_Response_for_Web_Applications_Cheat_Sheet.md:18 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- Employ anomaly detection alg..."]` because I guess that comment broke up the list item.
Snort is an IDS product. That line looks to be a sample rule for it. |
|
FYI I opened a discussion in textlint-rule-terminology about the IDS/IDs trouble. |
|
@kwwall Any chance you can review this? Thanks! |
There was a problem hiding this comment.
Here are some a semi-random general comments / observations.\
- Somewhere, we need to point out the steps that you ABSOLUTELY MUST COMPLETE before an incident versus those that you can do during an incident investigation. Because to a large extent, if you don't have certain things already done, you don't have much of a prayer.
- I'm not convinced this is currently sufficiently detailed to formulate an action-plan. Its more like a general outline of steps. I think that is okay as long as somewhere near the beginning, you clearly set expectations.
- Looking at some of this (e.g., running with DEBUG logging enabled, without being very specific) comes at a huge cost, especially if you are in the cloud and paying for log storage. Also, there is such a thing as getting overwhelmed by data, especially if that data is unfamiliar to the IR team. If it's unfamiliar, then lots of things look like anomalies. As a result, it may be better to set up canaries (such as honey pots) and use technology such as Tripwire and monitor for those events as likely early warnings.
- Forgot to mention it earlier, but memory analysis should probably proceed disk analysis because by its very nature, it's more ephemeral.
Lastly, despite all my comments (which I hope you find as constructive rather than as critical), this is a great start and definitely fills a need.
| Enable verbose logging: `LogLevel debug` | ||
| <!-- textlint-disable terminology --> | ||
| - Implement intrusion detection systems (IDS) for real-time monitoring. \ | ||
| Snort IDS rule example: |
There was a problem hiding this comment.
Given that we are OWASP, wouldn't it be better if we had an example with mod_security CRS instead of Snort?
| ### 3. Containment and Eradication | ||
|
|
||
| - Isolate affected systems to prevent lateral movement. \ | ||
| Network isolation using iptables: `iptables -A INPUT -s <infected_IP> -j DROP` |
There was a problem hiding this comment.
A few things:
- Using iptables is likely to confuse a lot of people, especially those only using Windows of BSD (and thus use pfsense).
- Only old school Linux system administrators probably still use iptables. Now they likely use either nft (for nftables) or ufw.
- 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.
- 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.
|
|
||
| - Isolate affected systems to prevent lateral movement. \ | ||
| Network isolation using iptables: `iptables -A INPUT -s <infected_IP> -j DROP` | ||
| - Employ network segmentation to contain the spread of the incident. \ |
There was a problem hiding this comment.
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.
| Network isolation using iptables: `iptables -A INPUT -s <infected_IP> -j DROP` | ||
| - Employ network segmentation to contain the spread of the incident. \ | ||
| VLAN configuration example: \ | ||
| `switchport mode access` \ |
There was a problem hiding this comment.
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".
| @@ -0,0 +1,97 @@ | |||
| # Incident Response for Web Applications Cheat Sheet | |||
There was a problem hiding this comment.
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".
| - Monitor network traffic for signs of malicious activity during the recovery phase. \ | ||
| Wireshark filter for suspicious traffic: `tcp.flags == 0x02 && ip.src != trusted_IP` | ||
| - Validate data integrity to ensure recovered systems are not compromised. \ | ||
| File integrity validation using md5sum: `md5sum -c integrity_checksums` |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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)? 😜
|
|
||
| ### 1. Incident Response Plan | ||
|
|
||
| - Develop a detailed incident response plan (IRP) specific to web application security. |
There was a problem hiding this comment.
Again, this CS does not seem specific to 'web applications', so I'd drop that and maybe just change it to cyber-security.
| - Draft incident notification templates for internal and external stakeholders. | ||
| - Implement secure communication channels, considering encrypted email and secure messaging apps. | ||
|
|
||
| ### 3. Evidence Preservation |
There was a problem hiding this comment.
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.
|
|
||
| ### 3. Evidence Preservation | ||
|
|
||
| - Document incidents thoroughly, preserving logs, screenshots, and memory dumps. |
There was a problem hiding this comment.
Good idea to video tape the process as well.
|
@ChaseOnTheWeb can you respond to comments form @kwwall ;-) |
|
@ChaseOnTheWeb - Do you intend to respond? I've had unresolved comments since Aug 14, 2024. If you want a 2nd opinion, I'd sure I can get someone I know who specializes in IR to comment on it, but they'd likely have way more things they would want changed that the relatively minor things I've requested. Please let us know one way or another. It's okay to say "Never mind. I'm not interested in making the requested changes" or "I don't have time" or whatever. No one in this group will think any less of you. But at least then we can close this PR and move on. Thanks in advance for letting us know. |
Credit goes to @aditya6298 for creating it, I'm just making the PR.
This PR covers issue #1235.
You're A Rockstar
Thank you for submitting a Pull Request (PR) to the Cheat Sheet Series.
Please make sure that for your contribution:
[TEXT](URL)If your PR is related to an issue, please finish your PR text with the following line:
This PR covers issue #
<REPLACE WITH ISSUE NUMBER>.Thank you again for your contribution 😃