New cheat sheet: Incident Response for Web Applications.

[ChaseOnTheWeb]

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.

🚩 If your PR is related to grammar/typo mistakes, please double-check the file for other mistakes in order to fix all the issues in the current cheat sheet.

Please make sure that for your contribution:

• In case of a new Cheat Sheet, you have used the Cheat Sheet template.
• All the markdown files do not raise any validation policy violation, see the policy.
• All the markdown files follow these format rules.
• All your assets are stored in the assets folder.
• All the images used are in the PNG format.
• Any references to websites have been formatted as [TEXT](URL)
• You verified/tested the effectiveness of your contribution (e.g., the defensive code proposed is really an effective remediation? Please verify it works!).
• The CI build of your PR pass, see the build status here.

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 😃

[szh]

That took care of the "IDS" issue! Now there's a new error:
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..."]

Also do you mean "Short" instead of "Snort"?

[ChaseOnTheWeb]

Also do you mean "Short" instead of "Snort"?

Snort is an IDS product. That line looks to be a sample rule for it.

[szh]

LGTM, since the text is copied from #1235 which has approval

[ChaseOnTheWeb]

FYI I opened a discussion in textlint-rule-terminology about the IDS/IDs trouble.

[jmanico]

This is excellent work but I want to wait for others to review before I approve.

[szh]

@kwwall Any chance you can review this? Thanks!

[kwwall]

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.

[kwwall]

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

[kwwall]

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.

[kwwall]

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.

[kwwall]

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".

[kwwall]

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".

[kwwall]

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.

[kwwall]

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)? 😜

[kwwall]

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

[kwwall]

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.

[kwwall]

Good idea to video tape the process as well.

[kwwall]

@kwwall Any chance you can review this? Thanks!

To @szh - Be careful what you ask for. 😉

[mackowski]

@ChaseOnTheWeb can you respond to comments form @kwwall ;-)