Authentication is the new entry point into federal government networks. Most federal users know this, and more importantly, attackers know this as well. Federal agencies can no longer recommend changing passwords on a periodic basis and consider that an adequate security measure.

Additionally, merely using two-factor authentication can lead to approval fatigue where a user gets lulled into a false sense of security and approves a prompt even though it may be the attacker who is triggering the two-factor authentication prompt.

What about your MFA implementation?

Even if your agency has a working multifactor authentication (MFA) implementation to your network or cloud resources, it’s time to reevaluate and see if you need to make further adjustments. Microsoft is tweaking their own recommendations for two-factor authentication.

In February of 2023, Microsoft enabled a two-factor authentication methodology that is called number matching. With this method, a number is displayed to a user once they sign in and they have to confirm the exact number on the multifactor authentication device.

MFA implementation fatigue

Often when you sign in, you will receive a pop-up notification sent to your phone or to your iWatch. It’s quick and easy to approve these prompts. It’s also too easy, and attackers take advantage of our multifactor authentication notification fatigue to gain access to our systems

Several recent intrusions into networks began when someone harvested the password and then spammed the user enough with a two-factor authentication prompt that the user accidentally and inappropriately approved the prompt. Thus, the attacker was able to gain access to the cloud resource by using the user’s (administrator) credentials and gain access as that user.

Recommendations for hardening security for MFA implementations

One top recommendation is to set up groups and begin the process now to test the enforcement of two factor across your agency network. While Microsoft will be implementing better authentication techniques later on in early 2023, you want to be testing out these changes now. One technique that stands out is the geographic addition to the multifactor authentication. This gives an immediate indication of where the two-factor prompt is coming from and showcases to the end user to be aware of multifactor spamming attacks especially for your key, agency personnel and highly sensitive accounts. Even the Cybersecurity and Infrastructure Security Agency (CISA) recommends enhancing MFA implementation techniques. They recently released guidance regarding phishing-resistant authentication.

Phishing-resistant MFA implementations

CISA recommends the gold standard, at least for now, is to deploy Phishing-resistant MFA implementation including FIDO/WebAuthn authentication and Public key infrastructure (PKI)-based. As noted in their documentation, “Separate physical tokens (called “roaming” authenticators) connected to a device via USB or near-field comms (NFC) or embedded into laptops or mobile devices as “platform” authenticators.” Tokens such as YubiKey ensure that multifactor can’t be spoofed. Implementation of tokens does take time, and it’s recommended to have more than one token as a backup.

Therefore, there is a cost and budget to consider when choosing this methodology. Furthermore, there is an issue of ease of implementation. Physical tokens demand that you remember to keep them with you, whereas for many of us, a phone is a more natural item to keep with you. Thus, you’ll need to also think about devices that help users keep tokens handy and make it easier for them to have them on hand when the need arises.

Then, you need to investigate your MFA implementation to see if the applications you wish to protect will support these enhanced multifactor implementations. Some will not support these additional tokens and instead will only rely on application tokens instead. There may also be a learning curve and implementation time. You may wish to use an application-based multi factor as a temporary measure to ensure that protection is in place and then later on deploy the token-based approach for additional protection.

Prioritizing deployments

Overall, you’ll want to prioritize deployment to key roles and cloud needs to ensure that these most
at-risk assets are protected. Prioritize the deployment to those roles and cloud applications that need the most protection. Review your risk analysis and what protections are needed based on actual threats you see in your endpoint protection and other indicators.

Using number matching

CISA has provided a white paper on using number matching-based, multi-factor authentication as additional protection to your cloud applications. As they point out, several vendors are including number matching in their two-factor implementations. While Microsoft is not mandating number-based multi-factor at this time, starting February 27, 2023, they will begin to roll out the mandate. Other vendors including Duo verified push, and Okta TOTP are just some of the vendors that are implementing these additional protection methodologies.

Administrators should periodically review the audit logs and review the failed multifactor authentications. Encourage staff to report any unusual MFA prompts they receive and have them be specific in the timing of when the events occur so that your forensic staff can review logs.

Updating defaults on Azure Active Directory

If you have not changed the defaults on Azure Active directory, your MFA implementation of the additional protections offered by the Microsoft authenticator application is set to “Microsoft managed.” That is, you are subject to their timing and roll out.

I recommend changing this to “enabled” and then choose the specific groups you want it implemented on. Having specific dates that the number matching will be enabled is a much better way to implement multifactor than relying on Microsoft. Often when you leave the timing to Microsoft, you won’t properly inform your users of the timing of the implementation. This may confuse your end users and cause more friction and frustration in your two-factor implementation.

Being mindful during migrations

Recently, I upgraded my iPhone and migrated the applications and two factor authentication applications from one phone to another. During the migration process, I became aware of how hard some of the migration paths were from an older phone to a newer one, let alone If you had plans to migrate to a different platform.

I personally found that I had to ensure that I temporarily kept the old phone to provide me with two-factor access in order to set up the multifactor applications on the new phone. If I had immediately wiped my old phone, I would be unable to log into my applications. Thus, when deploying new iPhones, ensure that you keep the old phone for a short time in order to finalize the migration of the two-factor applications.

Ideally, you want to have the user reauthenticate their multifactor application in a trusted location and come into a physically secure location to reactivate the multifactor authentication applications. Alternatively, you can use a new feature called Temporary Access Pass that provides a short-term workaround while you plan for a long-term solution.

To do this, go to Azure AD, then to the Security option and then select “Authentication methods.” Click “Temporary Access Pass.” Be sure that the Temporary Access Pass is enabled for impacted users.

Conclusion

If you haven’t implemented multifactor authentication for your at-risk users, I highly recommend you do so immediately. But if you are like me where you have MFA implemented, it’s time to review your implementation and see if you have opportunities to enhance it. Attackers are no longer one step behind you, they are often one step ahead.

This article originally appeared on Quest Software’s official blog, HERE.

About the Author

Chris Roberts

Chris Roberts is a seasoned technology leader with over 25 years of experience in the industry, having held various engineering and sales roles at market-leading companies such as Microsoft, Dell, and Quest Software. Currently, he serves as the Director of Federal Sales Engineering at Quest Software Public Sector Inc., where he leads a multi-disciplinary team of IT professionals. Their mission is to support governmental agencies with comprehensive software solutions around Zero Trust, securing Active Directory against unwanted intrusions, managing privileged access, and providing advanced recovery and governance tools. Previously, as a Senior Solution Architect at Quest Software, Chris focused on building and delivering innovative solutions for IT operations in enterprise customer environments. His expertise lies in modernizing legacy workloads and specializing in performance analytics for large-scale applications in both private and public cloud spaces. At Microsoft Corporation, Chris held roles as an Architectural Engineer and Principal Technology Specialist. He was instrumental in driving the introduction of technologies considered the standard in enterprise IT today while driving customer sales and success programs, delivering comprehensive technology roadmaps, and leading competitive opportunity management. Chris studied Computer Science and Marketing at the University of Maryland and Andrews University. His specialties include public speaking, enterprise software architecture, virtualization, cloud analytics, identity management, and technology management, among others. His track record of success, combined with his extensive knowledge and skills, make him a credible voice in the technology industry focused on solving challenges within the federal government.

Related Articles