Broke into general log use cases + security use cases. #1633
Conversation
Brought in a few things that were more clear in the old cs, and did some refactoring. https://wiki.owasp.org/index.php?title=Error_Handling,_Auditing_and_Logging
adamshostack
requested review from
kwwall,
mackowski,
jmanico and
szh
as code owners
| - Establishing baselines | ||
| - Assisting non-repudiation controls (note that the trait non-repudiation is hard to achieve for logs because their trustworthiness is often just based on the logging party being audited properly while mechanisms like digital signatures are hard to utilize here) | ||
| - Business process monitoring e.g. sales process abandonment, transactions, connections |
There was a problem hiding this comment.
Seems like some additional punctuation would be useful here. E.g.,
Business process monitoring; e.g. - sales process abandonment, transactions, connections
| - Providing information about problems and unusual conditions | ||
| - Contributing additional application-specific data for incident investigation which is lacking in other log sources | ||
| - Helping defend against vulnerability identification and exploitation through attack detection | ||
| - Performance monitoring e.g. data load time, page timeouts |
There was a problem hiding this comment.
Ditto in this case as well.
There was a problem hiding this comment.
no argument - if you go in to make the change re alert vs investigations, do you want to roll these into that change?
There was a problem hiding this comment.
At this moment of time, I am not that ambitious. And I think what you have is fine.
| - Identifying security incidents | ||
| - Monitoring policy violations |
There was a problem hiding this comment.
After 25+ years of me working in AppSec with CIRT and/or DFIR teams, I've observed that the CIRT / DFIR teams tend to split the log messages for security use cases into 2 main camps. One are log messages that they will use to trigger alerts (often combined with thresholds), and the other type are log events that is used as forensic evidence which they generally ignore until they open an investigation into a potential breach.
This division referenced here seems to be alluding to that. I'm not saying that we ought to provide more detail here, but was just curious if anyone else had had ever made similar observations.
There was a problem hiding this comment.
I haven't seen this, but I think from an advice perspective something like "Ask yourself 'is this a message someone will use to trigger an action, or as part of a larger investigation'?"
| - Compliance monitoring | ||
| - Data for subsequent requests for information e.g. data subject access, freedom of information, litigation, police and other regulatory investigations | ||
| - Legally sanctioned interception of data e.g. application-layer wire-tapping | ||
| - Other business-specific requirements | ||
| - Contributing additional application-specific data for incident investigation which is lacking in other log sources |
There was a problem hiding this comment.
This is like the forensics use that I previously mentioned.
| - Anti-automation monitoring | ||
| - Identifying security incidents | ||
| - Monitoring policy violations | ||
| - Assisting non-repudiation controls (note that the trait non-repudiation is hard to achieve for logs because their trustworthiness is often just based on the logging party being audited properly while mechanisms like digital signatures are hard to utilize here) |
There was a problem hiding this comment.
This could take up a cheat-sheet topic just on it's own. While it is not easy to achieve, the difficulty varies depending on your specific goals. It also need not require dsigs (e.g., recording logs to a WORM drive doesn't require that.) The bigger question is whether a business would consider this of something of value. To answer that, I think you need to consider it from a cost-benefit perspective and then do a threat model to decide what level of assurance of non-repudiation are you trying to achieve in like of the surfaced threats. That seems just the type of thing that fits in @adamshostack's wheelhouse. 😄
Brought in a few things that were more clear in the old cs, and did some refactoring. https://wiki.owasp.org/index.php?title=Error_Handling,_Auditing_and_Logging
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 fixes issue #
<REPLACE WITH ISSUE NUMBER>.Thank you again for your contribution 😃