CIAOPS MS-101 Certification prep course now available

I am happy to announce that the CIAOPS MS-101 Certification prep course is now available for purchase. This builds on the existing successful CIAOPS MS-100 Certification course.

The good news is that if you are one of the first few to purchase the course you’ll receive a 50% discount off the purchase price as a “beta tester”. Please the code MS101BETA at check out or this link to receive the discount. Remember, there are only a limited number of discounted places available so hurry. No matter when you purchase the, you’ll continue to have access to all the current and any new material added.

I’ll continue to build on the content that is available in the course, however currently there is over 75 individual lessons, study guides, links to additional material and more. This material should give you the best chance of passing the MS-101 certification course. Of course, you could just take the course to improve your knowledge of Microsoft 365 if you wanted, but why not also go for the certification if you are going to invest the learning time?

As I said, I will continue to add more content to the course over time and I hope that the early adopters will provide feedback on what extra needs to be added to make the course even better.

remember, if you want the 50% discount, you’ll need to hurry!

Changing client Log Analytics workspaces

I have been using Azure Log Analytics solutions for a while now to do things like report on client machine changes, updates, inventory, security and so on. However, I wanted to change my workspace for these clients from one Azure tenant to another.

image

I was thinking that I’d have to do into the registry and change the workspace id and key but when I searched the registry there were far too many entries. Turns out you don’t need to do that at all! All you need to do is got to the control panel and find the Microsoft Monitoring Agent as shown above.

image

When you run that you’ll see any workspaces you are current joined to. You can Edit or Remove what is there.

image

Then you you can add a new workspace as shown above.

image

All you then need to is plug in the new Workspace ID and Key from new workspace and you are away.

I also discovered that you can configure the agent to report to multiple workspaces, even in different tenants if you want. That makes things really easy.

How easy is that?

Need to Know podcast–Episode 217

We are in the run up to Microsoft Ignite in November but there is still lots and lots of news, however before that we have an interview with Jason LeGuier from Hotline IT about communicating the value of Microsoft 365. Brenton speaks with Jason and teases out how to explain the benefits technology to the average small business and not get lost just in the tech. We also get an update from Brenton on his recent speaking gig at Cybercon in Melbourne.

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-217-jason-leguier/

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

Jason LeGuier

@contactbrenton

@directorcia

Windows Virtual Desktop now generally available

Windows Virtual Desktop now available for Microsoft 365 Business Subscribers

Changes to blocked file types in Outlook on the web

New Office 365 phishing attack with your branding

More Dark mode

All your code belongs to us

Microsoft and NIST partner

How to pronounce Azure

Security is shared responsibility

The good and bad thing about the Internet is that we are all now pretty much connected to each other all the time. The growth in attacks by bad actors continues to expand and become ever more sophisticated.

One of the ways I have suggested that can help yourself be that little bit more secure is to brand your Microsoft 365 tenant. I wrote an article on how to do this:

Office 365 branding using Azure Resource Manager

Why this makes you a little bit more secure is that most phishing attacks are generic and take you to an unbranded, generic Microsoft 365 login page. Thus, having your own branding on your tenant will hopefully get users to stop and think before giving up their credentials to malicious sites. Yes, I know it is not fool proof, but every little bit helps.

It however, was only a matter of time before the bad actors worked out how to get around this as has now been brought to my attention.

SNAGHTML5ec48a3

image

As you can see from the above, I am getting my tenant branding displayed even though the URL is not for the Microsoft Online URL!

image

You can see the attack does have a flaw on a large screen as shown above, but I’m sure it will fool most people.

So, how can I make sure Microsoft knows about this? I can use my (real) Microsoft 365 Admin portal to report the URL.

image

I go to the Microsoft 365 Security Center and select Submissions from under the Threat Management section. You then select +New submission as shown.

image

You then simply complete the details for what you wish to tell Microsoft about and select the Submit button down the bottom.

image

You should get a confirmation like shown above.

image

You should then also be able to see your submission in the bottom of the screen. Just make sure you select the correct query options and results to see this.

You can read more about this at:

How to submit suspected spam, phish, URLs, and files to Microsoft for Office 365 scanning

Security it never an exact science. Attackers work hard to bypass barriers configured, so you should never be complacent. However, you should also share what you find with people like Microsoft to help them harden their systems against attack and thereby help others.

We are all in this together, so let’s work together to make it a safer place for all.

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.

Connecting to Cloud App Security API

As I have said previously, I believe Microsoft Cloud App Security is a must have for every tenant:

A great security add on for Microsoft 365

You can also manipulate it via an API and PowerShell. Most of this manipulation is currently mainly to read not set information but that is still handy. Here’s how to set that up.

image

You’ll firstly need to go to the Microsoft Cloud App Security console and select the COG in the upper right corner of the screen. From the menu that appears, select Security Extensions as shown.

image

The option for API tokens should be selected, if not select this. Now select the + button in the top right to generate a new token.

image

Enter a name for this new token and select the Generate button.

image

Your API token should be generated as shown. Copy both the token and the URL and select the Close button. Note, you’ll need to take a copy of you token here as it won’t be available once you move forward.

image

You should now see the token listed in the Microsoft Cloud App Security portal as shown above.

This token can now be utilised to access Microsoft Cloud App Security via PowerShell. I have created a basic script for you to use here:

https://github.com/directorcia/Office365/blob/master/o365-mcas-api.ps1

that will basically return all of the data current in there.

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

image

but in essence what that script does is take the token and uri and apply to the invoke-rest method to get a response. That return response contains a whole range of data from Microsoft Cloud App Security.

image

To see what you can and can’t do with the API visit the Microsoft Cloud App Security portal again and select the Question mark in the upper right this time. Select API documentation from the menu that appears.

image

In there you’ll find a range of information about the API.

As I said, most of the available command current just “get” information. Hopefully, commands that “set” information aren’t too far away.

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.