You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 ruleEXPL_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.
The text was updated successfully, but these errors were encountered: