When a company as massive and pervasive as Cisco announce a breach, security professionals take notice, particularly in an era of supply chain attacks that wreaked havoc for organizations across public and private sector.
But this was generally a success story. Cisco detected the security incident targeting Cisco’s corporate IT infrastructure on May 24 and took immediate action to remediate the impact. It has since hardened its IT environment to prevent such incidents, which relied on a series of sophisticated voice phishing attacks against an employee who eventually accepted multi-factor authentication (MFA) push notifications made by the attacker, granting access to the VPN.
“I love that they used voice – so old-school,” said Jim Lewis, senior vice president and the director of the Technology and Public Policy Program at the Center for Strategic and International Studies. “Cisco says they caught it quick, which is the secret to success.”
But do lessons still exist from the situation? How might a chief information security officer digest the incident? SC Media connected with Dan Meacham, the vice president of global security and corporate operations and CISO/CSO at Legendary Entertainment to find out his.
Cisco’s response was swift. What’s your perspective on how they communicated the incident?
I appreciate the transparency on the attack vector and the creation of the Calm AntiVirus signatures. Providing the attack approach and suspected tools used in the attack position security practitioners the opportunity to assess their environments for similar exposure and risks.
Zero trust and trusted devices are not perfect security models. In this attack, the hackers gained access through MFA fatigue – the attack where you basically create an MFA request DDoS on the user in hopes that the user will eventually accept the MFA token request. Once the hackers were in, they enrolled their systems as trusted devices to the compromised user.
So how might practitioners assess their own environment, as you said?
There are several key takeaways from this attack. First, training – users need to ensure MFA is turned on for all of their accounts, including Google Gmail and Chrome. Did the hacker gain access to a Google / Chrome account that did not have MFA enabled? Users really shouldn’t cache credentials in their browsers (Safari, Chrome, FireFox, Edge, etc.). Instead, users need to use a password manager. And the last training point is to always notify security when you have an MFA request that you did not initiate – ALWAYS. If you get an unsolicited MFA request – someone knows your password and is actively using it.
Second, monitor [user behavior analytics] – the compromised user account escalated to administrator. This action alerted the Cisco SOC and activated their Cisco Security Incident Response Team. If Cisco was not monitoring for this type of behavior or activity, the actions may have gone deeper into the Cisco systems and taken longer to identify a compromised account. Additionally, the hacker was using LogMeIn, TeamViewer, and offensive security tools such as PowerSploit, Mimikatz, Impacket, and Cobalt Strike. Use of remote access/control utilities need to be locked using a Privileged Access Manager (PAM) where controls can be set to limit access times, source locations, and triggers auditing and alerting when used. Moreover, indicators of compromise should be in place to alert when offensive tools are ran on the network or systems.
Cisco of course is massive. What about smaller organizations that have fewer resources?
I think each security team needs to consider asking the following questions internally and with their ZTNA / IDM / SSO / MFA providers: 1) What mechanisms or counter measures are in place to prevent MFA fatigue attacks? 2) What mechanisms or counter measures are in place to restrict device enrollment? For example, when a user wants to enroll a new device, is there a secondary control where an administrator must release the enrollment request? 3) What is the overlap between a Google user/Chrome account and an SSO provider’s plug-in – Is the SSO provider’s plug-in cached in Google for new Chrome browser logins? What mechanisms or counter measures are there to restrict or limit the auto-population of the SSO provider’s plugin on a new Chrome login?
