Legitimate non-MFA protection

image

There is no doubt that multi-factor authentication (MFA) is the great thing for the majority of accounts. It is probably the best protection against account compromise, however are there times that perhaps, MFA doesn’t make sense?

Security is about minimising, not eliminating risk. This means that it is a compromise and never an absolute. Unfortunately, MFA is a technology and all technologies can fail. If MFA did fail, or be unavailable for any reason, then accounts would be unavailable. This could be rather a bad thing if such an issue persisted for an extended period of time.

In such a situation, it would be nice to be able to turn off MFA for accounts, so users could get back to work, and re-enable it when the MFA service is restored. However, today’s best practice is to have all accounts, especially administrators, protected by MFA.

A good example is the baseline policies that are provided for free in Microsoft 365 as shown above.

image

You’ll see that such a policy requires MFA for all admin roles.

image

And yes, there is a risk for admin accounts that don’t have it enabled but there is also a risk if it is enabled and MFA is not working for some reason.

The challenge I have with these types of policies is that they are absolute. It is either on (good) or off (bad), and in the complex world of security that is not the case.

I for one, suggest there is the case for a ‘break glass’ administration account, with no MFA, that be used in the contingency that MFA is unavailable to get into accounts and re-configure them if needed. Such an account, although it has no MFA, is protected by a very long and complex pass phrase along with other measures. Most importantly, it is locked away and never used, except in case of emergency. There should also be additional reporting on this account, so it’s actions are better scrutinised.

Unfortunately, taking such an approach means that you can’t apply such absolute policies. It also means that you won’t be assessed as well in things like Secure Score. However, I think such an approach is more prudent that locking everything under MFA.

As I said initially, security is a compromise, however it would be nice to see the ability to make at least on exception to the current absolute approach because service unavailability can be just as impactful as account compromise for many businesses.

Retrieving credentials securely with PowerShell

In a recent article I highlighted how you can securely save credential from PowerShell to a local file using the Export-Clixml command here:

Saving credentials securely with PowerShell

The idea with saving credentials securely is that you can now get to them quickly and easily. Just as easily in fact as embedding them into your PowerShell (which is a major no-no). So how do you do that?

You basically use the the import-clixml command like so:

$clientidcreds = import-clixml -path .\clientid.xml

to retrieve them. This will open the client.xml in the current directory, read in the encrypted values (username and password) and store them in the variable $clientidcreds.

Now $clientidcreds.password is a secure string, which means it can’t easily be used as a normal string in PowerShell. No problemo, now jus run the command:

$clientid = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($clientIdcreds.password))

and $clientid will have the plain text variable you initially saved and exported to the secure  XML file.

This is pretty neat eh? It allows you to securely save items such as oAuth and API keys in a secure file on you machine and then recall them quickly and easily with the above commands and use them in your PowerShell code.

Saving credentials securely with PowerShell

There are times when you want to securely save and retrieve information in PowerShell. Saving things like passwords and other credentials to plain text is not a good idea at all. To avoid that, you can use the Secure string feature of PowerShell. The most common way to do this is via the command:

$Secure = Read-Host –AsSecureString

This creates a secure string. After you enter the command, any characters that you type are converted into a secure string and then saved in the $secure variable. With this command, the characters you enter are not displayed on the screen.

image

Because the $secure variable contains a secure string, PowerShell displays only the System.Security.SecureString text when you try and view it. So the information to be secured is now saved as a protected variable called $secure in PowerShell. How can this now be written securely to a file so that it can be re-used later and still remain protected, even on the disk?

You can use the command Export-Clixml because a valuable use of this on Windows computers is to export credentials and secure strings securely as XML.

Thus, a better way to capture the value you want to save securely is probably via:

$Secure = get-credential -credential ClientID

image

Which will prompt you for the information as shown above. You will note that the User name filed has already been created thanks to the –credential parameter.

This will then give you a variable with a username (here ClientID) and a secure string that is a PowerShell credential.

You can then save the information via:

$clientid | Export-CliXml -Path .\clientid.xml

image

If the Export-Clixml is used to save that variable to a file (here clientid.xml), it will save it like shown above. You will note that the Password field is encrypted. This is where the secure information is kept, which is great, since it is now encrypted on disk.

The other great thing about using Export-Clixml is that:

The Export-Clixml cmdlet encrypts credential objects by using the Windows Data Protection API. The encryption ensures that only your user account on only that computer can decrypt the contents of the credential object. The exported CLIXML file can’t be used on a different computer or by a different user.

image

Thus, if the file with the saved and encrypted information is copied and used by another login on the same machine or on a different machine, you get the above result. Basically, it can’t be decrypted.

Of course, this isn’t perfect, but it does mean that once you have saved the information using the above technique the only way it can be decrypted is via the same logon on to the same machine. This means you don’t need to have secure variables saved as plain text inside scripts or in unprotected files on disk that can be copied and work anywhere. With this technique you can ensure that information saved to a file is encrypted and cannot be used by any other user or by any other machine. Thus, if someone got hold of the file, the information couldn’t be viewed or decrypted and thus access would be denied.

Hopefully, that should allow you to develop more secure PowerShell scripting.

Capturing ALL Microsoft Secure Score items

image

Ok, so you are telling me you have time on your hands and want to improve the security of your Microsoft 365 tenant? Ok, if you are only kind of serious, I’d tell you to go to:

https://security.microsoft.com/securescore

and select the Improvement actions as shown above.

image

That will show you a filtered view of items based on what hasn’t yet been completed in the tenant. In the case above, that equates to 67 items.

Oh, you want more to do you say?

image

Ok, if you remove that filter you’ll see the number in the list increase. In this case up from 67 to 84. That’s 36% increase in things you can address. Enough?

What? You want even more? Are you sure? Really sure?

image

Well, if you are, then the good news is that I have written a script for you that uses the Microsoft Graph to go in and grab all, and I mean ALL, of the secure score items. You’ll find the script in my Office 365 GitHub repo:

https://github.com/directorcia/Office365/blob/master/o365-ssdescpt-get.ps1

Now before you run this scripts, you’ll need to follow the instructions I have written about before:

Access the Microsoft Graph with a script

and set yourself up an OAuth token to access your tenant. You only need to do this once.

You’ll then need enter the values from this configuration into the script prior to running it:

image

You get these three items from the oAuth token set up I set out.

image

When run, the script will connect to the Microsoft Graph and start reading information from the Secure Score of YOUR tenant. It will also save the output to a text file in the parent directory. Why you ask?

SNAGHTML20f6be5

Well, as you can see from the output from my tenant above, there are now potentially 6,972 items that I can go look at and configure to make my tenant more secure. That’s a 8,200% increase in things to keep you busy.

Remember, you did ask for more after all.

Connecting to Exchange Online with Azure Cloud Shell

I’ve written previously about

Azure Cloud Shell

and how handy it is when it comes to connecting to your tenant with PowerShell. What you may not realise is that you can also Azure Cloud Shell to connect to Exchange Online! All you need to do once you have launched Azure Cloud Shell is run the command:

connect-exopssession

image

As you can see from the above where I have connected and then used the command get-mailbox inside Azure Cloud Shell.
image

This now means you could copy my mailbox forwarding checking script:

https://github.com/directorcia/Office365/blob/master/o365-exo-fwd-chk.ps1

into your Clouddrive that is part of Azure Cloud Shell and run it.

image

And thanks to Clouddrive it will be there next time you use Azure Cloud Shell. Handy eh? If you want to learn about this capability, visit:

Azure Cloud Shell now supports Exchange Online

Need to Know podcast–Episode 215

In this episode I speak with Alex Fields about the power of conditional access. You’ll learn what it is, how to implement it as well as many best practices recommended by Alex based in his experience and knowledge. The great new is conditional access is part of Microsoft 365 Business, so listen in for the way to make it work to protect your information.

Brenton and I also bring you up to speed with all the latest Microsoft Cloud news, so listen in for the latest as always. We hope you enjoy this episode and don’t forget to send us your feedback.

This episode was recorded using Microsoft Teams and produced with Camtasia 2019

Take a listen and let us know what you think – feedback@needtoknow.cloud

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-215-alex-fields/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.

Resources

@vanvfields

@contactbrenton

@directorcia

CIAOPS Patron Community

ITProMentor

ITProMentor – Best parctices

Attacker Kill Chain described

ITProMentor – Free Microsoft 365 Business eBook

ITProMentor – Licensing Guide

Telstra Purple

New version of To-Do

Authenticator backup on Android now available

Prepare for iPadiOS Launch

New webparts coming to SharePoint

Azure QuickStart Center

Top 5 advantages of syncing with OneDrive

Modernize your root site

Check your journaling rules

One of challenges with security is that there are lots of places to check and secure but only one vulnerability required for compromise. Most compromises happen at the user level but there are also other places that you may want to keep an eye. One of the is the journaling rules in Exchange Online.

Now, journaling rules can only generally be configured by an administrator. According to:

https://docs.microsoft.com/en-us/exchange/security-and-compliance/journaling/journaling

“Journaling can help your organization respond to legal, regulatory, and organizational compliance requirements by recording inbound and outbound email communications.”

That means it maybe possible to record email traffic and forward it to another location. That may mean for example, a rogue administrator setting up a journaling rule to send the CEO’s emails to their own private external email box.

Defending against rogue admin is tough and requires some planning. The least that you could do is check any existing journaling rules and ensure that only required ones appear.

image

You can do this by visiting the Exchange Online Admin Center. From here select Compliance Management then journal rules as shown above.

As you can see there are no journal rules in this tenant and it is my experience that most tenants don’t use journaling at all. That doesn’t mean there isn’t legitimate reasons for having journaling rules. All I’m saying is that you should check what you have and ensure it is right.

As always, I find that using PowerShell is a much quicker way to report on this using the command:

get-journalrule

The reason which checking journaling is important, is because as I understand it, journaling won’t show up in the audit logs for the tenant. This means that once it was surreptitiously enabled, it could run unreported in the background, collecting information unknown to everyone? That is a bad thing.

The best solution against rogue administrators in general is Privileged Access Management (PAM) in Office 365:

Configuring Privileged Access Management

which is typically only included in advanced Microsoft 365 licensing like E5. This, unfortunately, puts it beyond the reach of many. So, for the time being, keep an eye on your journaling rules and check to see where they maybe sending your information.

 

New Safe Links option

An eagled eye CIAOPS Patron spotted this new option in Office 365 ATP Safe Links:

image

Wait for URL scanning to complete before delivering the message

image

You get to this via the Security and Compliance Centre, Threat Management, Policy, Safe Links. You then select the lower policy option as shown above.

I had a look at the PowerShell for this policy:

image

Indeed, there is now an option:

delivermessageafterscan

as shown above.

Interestingly, there is no mention of this option yet in the:

Set-SafeLinksPolicy

documentation. So I thought I’d try adding it to the existing policy anyway.

image

No error, which is a good sign.

image

Checking back in the GUI, you can now see that option is set.

So, there is now a nice new shiny option that you can set Office 365 ATP Safe Links to prevent a message being delivered to an end user until the links have been fully checked. This now matches the policy option for safe attachments. You can also set this option via PowerShell.