Why You Should Use Conditional Access Policies With MFA in Microsoft Azure

Why You Should Use Conditional Access Policies With MFA in Azure by Tim Layton

For many scenarios in the cloud today, multi-factor authentication (MFA) simply isn’t enough. I recently wrote an article reviewing why MFA isn’t enough any longer in public cloud environments.

In Azure, you can use conditional access policies in conjunction with MFA to help add an additional layer of protection to privileged accounts at a minimum. Refer to the diagram below for a conceptional overview.

With conditional access policies, you can block logins from suspicious IP address, deny access from devices without malware protection, and even limit access from risky sign-ins.

Before we cover more details on conditional access policies, I will quickly review multi-factor authentication (MFA).

Get My Free Cloud Security Risk Management Journal

Multi-Factor Authentication (MFA)

Multifactor authentication (MFA) is understood by most IT and security professional to be a good choice when you want to add additional security for identities by requiring two or more elements for full authentication. These elements fall into three categories:

  • Something you know: A password or the answer to a security question.
  • Something you have: A mobile app that receives a notification or a token-generating device.
  • Something you are: Some sort of biometric property such as a fingerprint or face scan used on many mobile devices.

It is easy to understand how using MFA increases the security of identities in the cloud and limits the potential impacts of credential exposures.

When using MFA, a threat actor not only would need to know a users password, but they would need physical access to their phone or the users face in order to fully authenticate. Only nation state actors would have the skills and abilities to bypass these types of additional security measures.

In the public cloud single factor authentication (password only) is insufficient for any user, and I would argue dangerous for privileged accounts. Enabling MFA in Azure is about as simple as it can get.

Azure AD has multi-factor authentication capabilities built in, so it couldn’t be easier to implement. It can also integration with a wide variety multi-factor authentication providers.

Azure Conditional Access Policies

Along with multi-factor authentication (MFA) described above, ensuring that additional requirements are met before granting access can add another layer of protection.

With conditional access policies, you can blocking logins from a suspicious IP address, or denying access from devices without malware protection, and even limit access from risky sign-ins.

Azure Active Directory provides conditional access policies based on group, location, or device state.

The location feature in conditional access policies allows your organization to differentiate IP addresses that don’t belong to the network, and it satisfies the security policy to require multi-factor authentication from defined locations and address blocks.

For example, you could create a conditional access policy that requires users that request access to your Azure hosted web application from an IP address outside of your corporate network to be challenged with multi-factor authentication.

In the diagram below, you can see that when a user makes a request to access your cloud and even on-site applications, a list of conditions are evaluated and enforced via policy. Users are either allowed access or forced to go through multi-factor authentication or blocked based on the defined conditions.

Tim Layton specializes in demystifying the complexities and technical jargon associated with cloud computing security and risk management for business stakeholders across the enterprise. Tim is a cloud security thought leader defining actionable and defensible strategies to help enterprise stakeholders make risk-based decisions and prioritize investments in the new digital frontier.

Stay Connected With Tim Layton

LinkedIn: www.Linkedin.com/in/TimLaytonCyber

Website: http://CloudSecurityLaunchPad.com

Get My Free Cloud Security Risk Management Journal


Threat: Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service. (NIST 800–30)

Threat: potential cause of an unwanted incident, which can result in harm to a system or organization. (ISO 27001)

Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source. (NIST 800–30)

Vulnerability: weakness of an asset or control that can be exploited by one or more threats. (ISO 27001)

Likelihood: A weighted factor based on a subjective analysis of the probability that a given threat is capable of exploiting a given vulnerability or a set of vulnerabilities. (NIST 800–30)

Likelihood: chance of something happening. (ISO 27001)

Risk: A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. (NIST 800–30)

Risk: effect of uncertainty on objectives. (ISO 27001)

Security Controls: The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. (NIST 800–30)

Compensating Security Control: A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system. (NIST 800–30)

Impact Level: The magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability. (NIST 800–30)

Residual Risk: Portion of risk remaining after security measures have been applied. (NIST 800–30)

Security Posture: The security status of an enterprise’s networks, information, and systems based on information assurance resources (e.g., people, hardware, software, policies) and capabilities in place to manage the defense of the enterprise and to react as the situation changes. (NIST 800–30)

Get My Free Cloud Security Risk Management Journal

Tim Layton

Tim Layton

Get Tim Layton's Free Cloud Security Journal so you can remain current with the latest cloud security trends and updates. Tim is a cloud security thought leader defining actionable and defensible strategies to help organization's make risk-based decisions and prioritize investments.

Recommended Articles

Leave a Reply

Your email address will not be published.