Forum Discussion
MicrosoftAnnouncement: Office 365 Secure Score Released to Public Preview
Another issue with Secure Score.
"You should require that all of your users reset their password at least every 60 days"
This is no longer current best practice where strong passphrases and 2FA are used since more rapid enforced change of passwords leads to the use of weaker ones.
MicrosoftThanks for the feedback! I'm adding the notification feature to the backlog. We intend to provide an easy way to 'undo' any given action, but I agree that a notification is a good extension of the control framework.
For your second question, the [Not Scored] items are definitely intended to be scored eventually. It is surprisingly hard to find the source data in the ecosystem, and we wanted to get the experience in the hands of real users sooner rather than later. We exposed the full list of controls because we'd love to hear if you think we've missed anything, or that the identified control is off target.
Lastly, I think facilitating a regular review cadence is a good suggestion. Several of the controls are for report reviews, which happen weekly or monthly. We explicitly wanted to avoid an 'alerting' framework, but finding ways to poke you to come back is a good suggestion. Possibly might use the Security and Compliance Center 'Action Center' functionality for that. For now, you'll have to manage manually.
Thanks again for the feedback!
Brandon Koeller
BrandonKoeller wrote:
Hey Paul,
... It is surprisingly hard to find the source data in the ecosystem, ...
Well, at last! Someone from Microsoft acknowledging this. Perhaps you could also raise the visibility of some of the audit issues - like missing data from the audit reports.
Also perhaps you could get someone to finally deal with the issue of trying to identify which users have not used the system recently (e.g. have not logged in in the last 90d). This appears to still be virtually impossible, especially when users are not using Exchange Online.
These issues are causing no end of problems.
I recently tried to identify people not using the system in order to recover licenses. I used the audit reports for the last 180d thinking that at the very least all active users must have changed their password in that time and that should have been audited. Needless to say that resulted in nearly 10% of identified users that were actively using the system.
- BrandonKoellerHey Julian,
Thanks for the feedback. My comment about the difficulty of finding source data in the system is related to the complexity of the back end ecosystem, not the availability and accessibility of relevant data for customers. In general, customer-facing data stores are meant to be straightforward, at least through the supported interfaces (usually web, api, and powershell). To your point, however, there are some resources that you can use to get your answers:
-The Admin Center Usage Reports page should allow you to discover which users are using which services for any given period of time: https://portal.office.com/adminportal/home#/reportsUsage
-You can also focus just on logons by looking at the list of users and comparing it to the logon activity logs in the service. I've taken the liberty of whipping up a quick powershell script which dumps the UPNs of users who have not logged in for the last 90 days: https://github.com/OfficeDev/O365-InvestigationTooling/blob/master/InactiveUsersLast90Days.ps1
-The Search-UnifiedAuditLog cmdlet, and its web interface (https://protection.office.com/#/unifiedauditlog) is a great resource to tracking any kind of activity in the service.
-If you are targeting illicit activity detection along discrete threat vectors, you can also use our 'Finding Illicit Activity The Old Fashioned Way' article: https://blogs.technet.microsoft.com/office365security/finding-illicit-activity-the-old-fashioned-way/
Thanks!
Brandon KoellerAlso, thanks for the pointer to the Investigation Tooling Github. I've run the script to check for users not logged in in the last 90d but the first entry that it reports is one that I know is used daily because the person sits behind me in the office! They are a very heavy Office 365 user as they helped my set up our tenant.
I've raised a couple of issues in the github log. I think the reason it thought my colleague hadn't logged in is that it only returns 5k records. That's nowhere near enough for a 90d review of logins for 8k users. I'll update the issue with a new script when I've finished it or I can do a pull if you prefer, let me know in the issue (I am TotallyInformation on GitHub).
Many thanks Brandon. I've been tracking these issues for some while but I've struggled to pin down actual evidence.
Having just revisited the issues that I'm having. I now have hard evidence from the get-msoluser and the combined audit log that something is very badly wrong. At least with our tenancy if not something wider.
Two definitive issues: One is that get-msoluser consistently reports some users with PasswordNeverExpires set to TRUE which should never happen.
The second is even more serious. I have found a user who is currently logged into the system but according to the Get-MsoUser data hasn't changed her password for 181 days (our tenant is set to require password change after 90d). Here is some relevant information:
BlockCredential : False
IsLicensed : True
LastPasswordChangeTimestamp : 2016-04-22 11:27:22
LicenseReconciliationNeeded : False
OverallProvisioningStatus : Success
PasswordNeverExpires : False
StrongPasswordRequired : True
StsRefreshTokensValidFrom : 2016-04-22 11:27:22
ValidationStatus : Healthy
WhenCreated : 2013-05-07 10:11:03
Checking the combined audit log I can see that it agrees that the user last changed their password on the 22nd April but they are still logging in. They should not have been able to log in after July 21st. However, the audit log has recorded 23 logins since then.Previously, I'd been assuming that some data was missing from the audit logs but it appears that there may be a more serious issue.
- Thanks for sharing this. I hope that this is an isolated event, but I'll do some research on my clients tenant to see if the same problem exists
