In November 2020, Baltimore County Public Schools disclosed that its network was hit with a ransomware attack. The incident caused the district to cancel classes for two days. A report released last week by the Maryland Office of the Inspector General says that the attack was initiated through a malicious email message in early November 2020. The district’s security contractor “mistakenly opened the email with the attachment using their unsecured BCPS email domain account and not in their secured email domain.”
Note
- Many major incidents involve multiple mistakes – this one is a good example: user falls for phishing, but luckily can’t get malicious attachment to run; user asks Tech Liaison for help, TL thinks attachment looks suspicious, forwards to contractor security staff; contractor mistakenly opens the attachment on an “unsecured BCPS email network” (which doesn’t sound like a good idea to have, no matter what) and infects the network, enabling the ransomware attack to succeed. Great scenario for a tabletop exercise. I hope the Tech Liasion gets promoted!
- A couple security observations: 1) tools and processes were in place to initially block the malware and they worked [secure configuration]; and, 2) the email with attachment was recognized as suspicious by adjunct IT staff [security awareness training]. Usually, both of these security procedures are enough to defend against a ransomware attack. Unfortunately, the breakdown occurred with the contracted security staff likely not following established procedures for handling suspected malware. A final comment: incident response and data recovery only work if you follow well established backup rules and regularly test the recovery process.
- Part of the problem is that findings from earlier assessments were either not addressed, or inadequately implemented. While there are always two sides to a story, make sure that you’re clearly documenting why you’re not addressing findings from a security assessment, and be doubly cautious about terms like delayed response to malware, as was configured in this case. As email continues to be a huge attack vector, consider carefully allowing access to personal email from corporate systems, possibly restricting that access to sandboxed browsers if at all.