Today I’m not talking regarding Azure, I’m talking generally in the Cloud, so… the case here is: you’re ready to modernize your infrastructure to truly benefit from the cloud and avoid sprawl, poor performance, complexity, and sky-high subscriptions. Here are the five key areas you need to plan things out.
What problem are you solving? The business case behind your infrastructure must be understood, with input from key stakeholders. How will the cloud help you deliver that value to your users or customers? How will you benchmark and improve on that goal? Common goals for cloud infrastructure are faster service delivery, lower operating costs, agile deployment, simplified user experience, modernization, and resilience.
What base infrastructure components will be used across your stack? Your subscription model, identity management, network, storage, backup, and other key components should work with any given app or VM that might be attached to your subscription.
Where can you automate? Automation and standard procedures are key to realizing the full benefit of the cloud. This helps minimize costs by automatically provisioning and decommissioning and implementing configurations without intervention. Infrastructure as Code will only continue to be more vital to cloud management.
Who is responsible for each piece of the stack? As you embrace more and more components delivered entirely as a Service, you must understand which entity is responsible for their management and potential failure. Obviously the underlying hardware is not yours to command, and a hardware-level failure would fall upon the service provider. But issue-resolution can be a difficult gray area. Be prepared to work with the cloud provider and have processes in place for issue tracking and resolution as well as version control and backup/restore.
How are you managing cloud governance? Depending on your management models, it may be much easier for users within or outside the IT department to provision their own resources. It was much harder to order, install, and configure a physical server than to simply click a few times to have a virtual one ready to go. You must be ready to protect and secure your data from inside and outside risks, while also reining in sprawl and maintaining compliance. Automation tools and code are a good place to start with governance and compliance.
Let’s face it: Sometimes you get false positives in Office ATP phishing Email alerts. Either this is caused by the system or you may have scheduled a phishing simulation from a third party provider that cannot be properly whitelisted.
In such cases, you find yourself sitting in front of an infinite list of either investigation events:
or infront of a likewise infinite list of the associated alerts:
Both lists have one thing in common: filtering and modification of additional columns is very limited. In fact, both lists do not provide any valuable data in this overview. To get more information, you have to click an entry of one of those lists and then you might have to click even further only to find out, you don’t have to touch that alert, cause it is a false positive.
Legal Hold can be used as an alternative to using third-party backup solutions since all emails are retained and cannot be deleted by the user or admin, except by retention policies.
Admins can place mailboxes on litigation hold or in-place hold. When you place content locations on hold, content is held until you remove the hold from the content location or until you delete the hold.
Litigation hold in O365 originally only existed for Exchange Online mailbox data, but has been extended to SharePoint Online, Teams, OneDrive, etc.
The user you wish to place on hold must a subscription that includes at least Exchange Online (Plan 2). This includes the following online licenses:
Microsoft 365 E5
Microsoft 365 E3
Office 365 E5
Office 365 E3
Users in subscriptions that include Exchange Online (Plan 1) can also be put on hold if the user has the add-on Exchange Online Archiving . Holds only apply to mailbox data with this license.
One great advantages of hold is that the user account can be deleted after they leave the company and the data will still be preserved for eDiscovery. So you won’t be burning a license for a user who does not access their mailbox any longer.
Following my last post about Azure AD Smart Lockout, have you ever wonder, how to monitor those events? Of Course, we can do it with Log Analytics
HOW TO MONITOR SMART LOCKOUT?
Integrating the monitor and alerting of Smart Lockout is very simple, this post will explain you how to do it:
In Azure Portal, Select Azure Active Directory > Diagnostic settings -> Add diagnostic setting. select Export Settings from the Audit Logs or Sign-ins page to get to the diagnostic settings configuration page.
In the Diagnostic settings menu, select the Send to Log Analytics workspace check box, and then select Configure.
Select the Log Analytics workspace you want to send the logs to, or create a new workspace in the provided dialog box.
Select one or both of the following:
To send audit logs to the Log Analytics workspace, select the AuditLogs check box
To send sign-in logs to the Log Analytics workspace, select the SignInLogs check box
Select Save to save the setting.
Now, what we will need to do is wait, probably in 5-10 minutes we will start to have data into workspace.
The logs we are looking for are in the AuditLogs and SigninLogs tables in the workspace.
| limit 50
and click on run to get the last 50 sign-ins listed. As we are interested into the actual Smart-Lockouts (ResultType 50053), we need to add a filter criteria to our query and we probably want to limit it to the last seven days only.
| where CreatedDateTime >= ago(7d)
| where ResultType == "50053"
And because we like to get notified, we can also set an Alert Rule on this type of query. Click on New Alert Rule, which will bring you the next blade.
Then we need to reuse and Action Group or create a new one, this is used to be alerted when the signal occurs. we have to be aware that depending of the frequency of the alert, we will be charged in €€€
Another thing to keep in mind is that we will have a lag between the alert and the action when it happens, it’s not inmediately.
Have you ever wondered how Microsoft prevents password guessing attacks or brute force attacks on Azure AD? Well, it is basically the same method as you would do on your on-premises User Directory! It is just smarter!
Azure AD Smart lockout is a feature being applied to every sign-in processed by Azure AD, regardless if the user has a managed account or a synced accounts using password hash sync or pass-through authentication.
The smart part comes from the ability to distinguish valid users from attackers. It locks out the attackers while letting your users continue to access their accounts and be productive.
The default lockout setting kicks in after ten invalid login attempts for one minute. The account locks again after each subsequent failed attempt, for one minute at first and longer periods in subsequent attempts. Also, smart lockout tracks the last three bad password hashes to avoid incrementing the lockout counter for the same password, basically, if the same bad password is entered multiple times, it will not cause another lockout.
Note: The monitoring of the same sign-in attempt is only available for the Password Hash sync scenario, as the Pass-Through password validation happens against your on-premise AD domain controllers.
Smart Lockout is always turned on for all Azure AD customers. If you want to modify the default behavior of 10 invalid attempts to trigger a one-minute lockout, then you require Azure AD P1 or P2 licenses for your users.
I know that we have to take security seriously, but I faced this problem so many times. Have you recently created a new Microsoft 365 or Office 365 account and users are being forced to setup MFA within 14 days despite MFA not being configured?
we are in the same boat!
I’m constantly setting up new tenants for clients and performing migrations and while enforcing MFA is a great idea and having it enabled by default is good it does cause issues during the configuration stage of a tenant.
The issue is being caused by a new security default policies being applied to the tenant.
Here is how to temporally (take it seriosly yo!) disable the new security default policies to turn off this behaviour.
Log into your tenant and go to the Admin console https://admin.microsoft.com and click in ‘Azure Active Directory’ from the left hand menu.
now click on ‘Azure Active Directory’ then ‘Properties’ then ‘Manage Security Defaults’.
Set ‘Enable Security Defaults’ to ‘No’.
Tick an option which most applies to you and click ‘Save’.
Now users will not be forced to configure MFA but remember weak passwords are causing us all major issues so please enable MFA for user accounts as soon as you can.
I just thought of sharing some insights about Microsoft Defender ATP today.
Microsoft Defender ATP is a unified platform for preventive protection, post-breach protection, automated investigation, and response.
Top 10 MDATP Advantages
Threat Vulnerability and Management: is the latest innovation in Microsoft Defender ATP, which continues to evolve to provide customers with powerful, real-time, and integrated means to discover, prioritize, and remediate threats.
Vulnerability Management Maturity Model
Microsoft Threat Experts: Threat Experts from Microsoft provide technical consultation on relevant detection’s and adversaries. MTE provide your Security Operations Center with expert-level threat monitoring over your de-identified data, threat analysis, and support to discover and respond to critical threats in your unique environment.
MDATP: Microsoft Defender ATP offers out of the box integration with Azure AD, Azure ATP, Azure Security Center, Azure Information Protection, Microsoft Cloud App Security, Microsoft Intune, and Office 365 ATP.