Can you create your own “Big Yellow Taxi” rule? 

Following the widely reported Microsoft breach between May and July 2023, the Cyber Safety Review Board conducted a comprehensive root cause analysis, culminating in a report that exemplifies the 5-Whys methodology. The collaborative efforts of CISA, affected federal customers, the CSRB and Microsoft are noteworthy for their thorough application of the 5-Whys technique in understanding the breach.

The entire report is a great read but our blog here talks about an important part of the report. As the attackers infiltrated mailboxes of various individuals, they initially went undetected until the SOC in the State Department found anomalous activity with MailboxItemAccessed log for some users in their organization. This anomalous log was detected using a rule called the “Big Yellow Taxi”. 

While it is not clear where this rule is applied, it is likely that it was a detection rule on a SIEM. The State department had fortunately purchased the G5 license (equivalent to E5 in commercial) that allowed them access to logs. We can further assume that these logs were aggregated in a SIEM and a few rules were added specifically to detect Business Email Compromise (BEC). 
The report also talks about the fact that this rule is noisy and often causes false positives. In this case though, the state department SOC went ahead with their investigation which resulted in discovering the breach. 

Building your own “Big Yellow Taxi” rules

While the state department is clearly doing a lot of things really well, it is quite clear that finding anomalous activities such as these is likely going to be way too expensive to the average enterprise. Even if they have built rules such as this, if these rules are prone to false positives, they will likely be turned off or ignored. The Cybersecurity industry has typically called this a “alert fatigue” problem. However, therein lies the problem.

To understand this problem - I will borrow a quote from a 5-part series on detection engineering titled - “Detection engineering is painful”. The blog series was led by Anton Chuvakin. The entire blog series is full of amazing insights but this particular quote is a gem: The age of “I just need to know a few popular Windows event IDs to detect” is long over. This quote is in the context of the complexity of data and systems that make processing data really hard. If the attackers had used different resources, it is likely that the “Big Yellow Taxi” rule would not have generated the alert. 

Dedicated detection engine is needed for identity attacks

The CSRB report then further explains that had the attackers not tried to login to mailboxes but instead tried to access other services, they likely could have remained undetected. This is where you need a much broader detection engine - rather than just a “Big Yellow Taxi” rule. 

While upcoming standards like DPoP, DBSC and SSE/CAEP will further enhance security posture, it will take a while for these standards to be fully adopted. But we must develop specific detection, remediation and prevention engines for complex Credential Access tactics. As attackers continue to evolve their techniques, a set of rules developed by a smart security engineer running on a SIEM are going to be woefully inadequate. 

At WideField Security, we are committed to innovating in building dedicated detection systems for initial credential access. If you are interested in knowing more about us - please reach out to contact@widefield.io

Footnote: The image for this blog was generated by DALL-E. WideField Security does not claim any copyright on the image.

Don't miss these stories: