Over the past decade, the IT world has been relatively simple: Internal and external IT were clearly separated. Internally, our protected LANs and WANs ran, which were secured with additional functions such as Network Access Control. Externally, the users cavorted in the big, evil Internet, which always triggered attacks against the DMZ. In between one or, depending on the number of DMZs, the datatraffic between internal and external IT was regulated. Appropriate building security ensured that devices and network connections could only be used by authorized persons.
However, with the use of Outlook Web Access or Exchange Active Sync, the security boundary was already removed from the company at that time. Smartphones thus also became systems that had to be protected. Smartphones, often ownedby employees, often make a strict device restriction impossible. Nevertheless, IT must ensure that the data consumed on these devices is protected from unauthorized access.
Since then, various methods have been used to secure the devices accordingly and to prevent access by outsiders in addition, more and more services are published on the Internet, whether on-premises or in the cloud, plays a subordinate role in this case. What is often forgotten, however, is the protection of the accessing account, which brings us to the topic of identity protection. What is the best use of secure devices if an attacker can put a device, such as a smartphone, into operation using a username and password?
The problem becomes even clearer when Azure AD is used. A connection between the user and his Windows 10 device established from outside the secured perimeter and made possible. Even though today we work exclusively with internal AD and Group Policies, the use of Azure AD in a standard configuration, which is required as a basis for Exchange Online or SharePont Online, enables such a hto add devices by a user. Azure AD added devices (so called “Azure AD Device Join”) get a very trustworthy status compared to the Azure AD and the attached services like Exchange Online or SharePoint Online.
It is therefore important to protect the user account as sensibly as possible without restricting the user too much in his daily work. It is also necessary to identify accounts that do not provide additional protection. Specific service accounts are given examples. One option for additional protection is the use of a multi-factor authentication (MFA) solution. This is included with the Azure AD from P1 licensing. Additional settings can significantly increase security both when using and rolling out an MFA solution. For example, if a user can only roll out his MFA within a secured perimeter. This setting example also shows, however, that such increased security can meet with a lack of understanding on the part of the end user. This is precisely why such an application must be weighed up carefully.
Another issue that needs to be addressed within Identity Protection is the possibility of guests to the Azure AD. If an attacker is invited by a user, he can impersonate another person in a chat and with appropriate preparation. In general, such phishing opportunities should be countered in all possible areas, for example with the Exchange Online Anti-Phishing solution.
Innovations should also be tracked and implemented. Old methods that can no longer be used and misused as attack vectors should be deactivated. As an example for such a new function the FIDO2 compatible devices represent, which make a passwordless logon possible. Or, on the other side of the scope, you should disable legacy authentication in Exchange Online to prevent password spray attacks.