-
Notifications
You must be signed in to change notification settings - Fork 13
Description
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.