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

Feature request: Make a reference book for customer clarity. #10

Open
tweedge opened this issue Dec 20, 2021 · 0 comments
Open

Feature request: Make a reference book for customer clarity. #10

tweedge opened this issue Dec 20, 2021 · 0 comments

Comments

@tweedge
Copy link

tweedge commented Dec 20, 2021

Hi there, old friends :)

To make a recommendation: when people are using this tool, not all of them are understanding what the output of this tool means. As log4shell scanning increases, especially as a Mirai sample was found with log4j integration today, more RMM community customers will be receiving findings in the next few weeks. A thread was started earlier today by a confused Datto customer on Reddit: https://www.reddit.com/r/cybersecurity/comments/rkou5z/evidence_of_a_log4j_attack_found_now_what/

Having a brief KB article written by Datto engineering, which customers could use to assess the impact to their environment when an exploit attempt is found, could substantially reduce confusion. This helps both parties - giving the customer valuable context in an urgent and concerning alarm, and would also help Datto increase its thought leadership in the security space for MSPs. For example, rule SUSP_JDNIExploit_Error_Indicators_Dec21_1 indicates that a JNDI lookup was attempted but failed - and therefore the customer may need to look for signs of compromise in their environment or review the logs more deeply. Whereas rule EXPL_Log4j_CVE_2021_44228_Dec21_Soft only indicates that an exploit payload was sent, but if the JNDI lookups were correctly disabled and/or the customer had already completely patched (which the customer then needs to validate) at the time the log was made, this would not on its own indicate a compromise. This context and next steps are not clear to non-security-engineer operators.

While of course this would need to have a succinct legal summary that the customer is responsible for security and incident response in their own environment, I don't think that would be a major hurdle to clear given the value just a few sentences about each rule would provide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant