{"id":34403,"date":"2019-09-03T18:08:00","date_gmt":"2019-09-03T14:08:00","guid":{"rendered":"https:\/\/www.msp360.com\/resources\/?p=34403"},"modified":"2025-05-05T15:00:35","modified_gmt":"2025-05-05T11:00:35","slug":"securing-your-office-365-tenants-part-2","status":"publish","type":"post","link":"https:\/\/www.msp360.com\/resources\/blog\/securing-your-office-365-tenants-part-2\/","title":{"rendered":"Securing Your Office 365 Tenants. Part 2"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">In this article, we will be reviewing the next set of recommended steps to take to secure an Office 365 tenant. These steps revolve around Office 365\u2019s built-in protection policies, including Anti-Spam, Anti-Phishing, Anti-Spoofing, custom Mailflow transport rules, and a few general organization-wide policies.<\/span><!--more--><\/p>\n<p><span style=\"font-weight: 400;\">In the <a href=\"https:\/\/www.msp360.com\/resources\/blog\/securing-your-office-365-tenants-part-1\/\">previous article<\/a> of the series, we reviewed things you can do quickly secure an Office 365 tenant quickly. These steps are geared toward MSPs who manage multiple Office 365 tenants and require some level of automation to configure Office 365 tenants in bulk.<\/span><\/p>\n<p><span style=\"font-weight: 400;\"><span class=\"further-reading \">Further reading<\/span> <\/span><a href=\"https:\/\/www.msp360.com\/resources\/blog\/securing-your-office-365-tenants-part-1\/\"><span style=\"font-weight: 400;\">Securing Your Office 365 Tenants. Part 1<\/span><\/a><\/p>\n<p><span style=\"font-weight: 400;\"><div class=\"table-of-content \">\n\t\t\t\t<p>Table of Contents<\/p>\n\t\t\t\t<ul><\/ul>\n\t\t\t\t<\/div><\/span><\/p>\n<h2><span style=\"font-weight: 400;\">Disabling Basic Authentication<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">According to Microsoft, Basic authentication uses legacy authentication protocols to connect to services such as Exchange. Some of these legacy protocols are IMAP4 and POP3. By leaving this backward compatibility open, you also leave your end users open to brute force or password spray attacks.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">When you disable Basic authentication for users in Exchange Online, their email clients and apps must support modern authentication. <\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span><span style=\"font-weight: 400;\">Those clients are:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Outlook 2013 or later (Outlook 2013 requires a registry key change)<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Outlook 2016 for Mac or later<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Outlook for iOS and Android<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Mail for iOS 11.3.1 or later\u00a0<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">There are 2 different methods to disable or prevent Basic Authentication.<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\"><b>Exchange Online Authentication Policy<\/b><span style=\"font-weight: 400;\"> - By running a simple PowerShell command that disables Basic Authentication for the entire Office 365 tenant.<\/span><\/li>\n<li style=\"font-weight: 400;\"><b>Azure Conditional Access Policy<\/b><span style=\"font-weight: 400;\"> - By leveraging Conditional Access Policies in Azure (you must have an Azure AD P1 license) to prevent access to Basic Authentication for select users or groups.<\/span><\/li>\n<\/ol>\n<blockquote><p><span style=\"font-weight: 400;\">Before picking one method and running with it, it is highly recommended to ensure all your end users are not using legacy authentication protocols. If they are and you disable basic authentication, you will very likely get a bunch of calls to your help desk from confused and frustrated users who are unable to access their emails. To avoid that chaotic scenario, you can use the Azure sign-in logs to see which users may still be signing in with older protocols.<\/span><\/p><\/blockquote>\n<h3><span style=\"font-weight: 400;\">How to Get Azure Sign-In Logs<\/span><\/h3>\n<ol>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Sign in to Azure AD Portal<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Navigate to <\/span><b>Users<\/b><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Under <\/span><i><span style=\"font-weight: 400;\">Activity<\/span><\/i><span style=\"font-weight: 400;\">, click <\/span><b><i>Sign-ins<\/i><\/b><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Make sure the following columns (at a minimum) are selected for the sign-ins report<\/span>\n<ol>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">User, Application, Status, IP Address, Client App<\/span><\/li>\n<\/ol>\n<\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Apply and refresh<\/span><\/li>\n<li style=\"font-weight: 400;\"><b><i>Download <\/i><\/b><span style=\"font-weight: 400;\">the report to CSV<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Open the report in Excel and filter out the Client App to show anything containing the words \u201cOther clients\u201d in the \u201cClient App\u201d column<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">Now, review the result of users that are returned from that filter. You may have to reach out to them to make sure they are using apps that support modern authentication to access their Office 365 services. After that is complete, check back in a few days and refresh the report. If only a few users are returned, you can proceed with the next steps (you may still receive calls from a few users, but the volume should be manageable).\u00a0<\/span><\/p>\n<h4><strong>Method 1 - Exchange Online Authentication Policy<\/strong><\/h4>\n<p><span style=\"font-weight: 400;\">This method requires no extra licensing and can easily be automated and run with PowerShell.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The general logic of the commands below is that you first need to create a new authentication policy. By default, when creating a new authentication policy, ALL basic authentication protocols are disabled.<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">While this approach offers the greatest security, one of its drawbacks is that by accessing PowerShell with Basic Authentication, disabling you will no longer be able to connect to Exchange Online using PowerShell by passing credentials with Get-Credentials. Without that, you may limit and restrict the ability to use PowerShell to administer Office 365 tenants. You can of course still access PowerShell for Exchange Online instead of using the MFA module, but this doesn\u2019t offer a way to pass credentials into the prompt, which effectively cripples the ability to log on to your Office 365 tenants with direct credentials in an automated loop.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Given this limitation, I personally am holding off on recommending this approach, at least until Microsoft provides a way to pass the credentials into the MFA prompt and allow them to pass over to Connect-MSOL or Azure Remote PowerShell module as well.<\/span><\/p><\/blockquote>\n<p><span style=\"font-weight: 400;\">After creating a new policy, you then reference that policy when setting the default authentication policy for the entire Office 365 tenant.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Here are the commands:<\/span><\/p>\n<pre># I recommend running this beforehand to ensure Modern Authentication is enabled. \r\n# Although Microsoft reports that Modern Authentication is enabled by \r\n# default, I\u2019d err on the side of caution here and run the command to\r\n# enable it anyway, as you don\u2019t want to block access for all\r\n# users mistakenly.\r\nSet-OrganizationConfig -OAuth2ClientProfileEnabled $true\r\n\r\n# First create a new policy that will block all basic auth protocols\r\n# except for PowerShell\r\nNew-AuthenticationPolicy -Name \u201cBlock Basic Auth - Except PowerShell\u201d -AllowBasicAuthPowerShell:$true\r\n\r\nSet-OrganizationConfig -DefaultAuthenticationPolicy \"Block Basic Auth - Except PowerShell\"\r\n<\/pre>\n<h4><strong>Method 2 - Azure Conditional Access Policy<\/strong><\/h4>\n<p><span style=\"font-weight: 400;\">Unlike the previous method, the Conditional Access Policy provides the ability to fine-tune granularity based on certain conditions. The great benefit of this approach is that we can exclude or only apply this policy to select users or groups so that we can avoid locking out applications or users that may still require the use of legacy authentication. The disadvantage of using this strategy over Method 1 is the lack of the ability to automate this process with PowerShell. You will have to apply this policy manually for every tenant using the Office 365 Azure portal.<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">Before proceeding further, make sure you review the Azure sign-in logs as explained above to identify any legitimate possibilities of users or applications that may still require basic authentication. If there are any, be sure to add those users and apps to a custom \u201cExclusion\u201d group so that you can easily exclude them from the policy restricting legacy authentication.\u00a0<\/span><\/p><\/blockquote>\n<p><span style=\"font-weight: 400;\"><strong>Notes<\/strong>:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Policies can take up to 24 hours to apply<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">First test the policy on a small subset of test users to ensure you don\u2019t lock yourself out<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Blocking \u201cOther Client Apps\u201d which is what we want to do here will block access to Exchange Online PowerShell, so be sure to exclude any admin accounts needing PowerShell access (that\u2019s why you should test this out first, as explained above)<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\"><strong>Steps<\/strong>:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Navigate to Azure AD admin center &gt; Azure Active Directory &gt; Conditional access<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Create a new policy; define a simple name (e.g. \u201cBlock Basic Auth for Other Client Apps\u201d)<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Choose all users to include, and under exclude add any groups or users that require exclusion<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Under cloud apps, select <\/span><i><span style=\"font-weight: 400;\">Office 365 Exchange Online<\/span><\/i><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Under client apps, check <\/span><i><span style=\"font-weight: 400;\">Mobile Apps and desktop clients<\/span><\/i><span style=\"font-weight: 400;\"> &gt; check only \u201c<\/span><i><span style=\"font-weight: 400;\">Other Clients<\/span><\/i><span style=\"font-weight: 400;\">\u201d<\/span>\n<ol>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">NOTE: This will block access to Exchange Online PowerShell - be sure to exclude admin accounts needing access to that (which is why I prefer method 1)<\/span><\/li>\n<\/ol>\n<\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Under <\/span><i><span style=\"font-weight: 400;\">Access controls<\/span><\/i><span style=\"font-weight: 400;\"> &gt; <\/span><i><span style=\"font-weight: 400;\">Grant<\/span><\/i><span style=\"font-weight: 400;\">, choose <\/span><i><span style=\"font-weight: 400;\">Block access<\/span><\/i><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Save and enable this policy when ready<\/span><\/li>\n<\/ol>\n<h2><span style=\"font-weight: 400;\">Disable External Forwarding<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Disabling external forwarding across the Office 365 tenant will prevent all users from forwarding emails to external accounts. You may want to do this to prevent data leaks or to meet corporate policies. However, for the purposes of this tutorial, we will be doing this to prevent compromised accounts from forwarding all emails to external recipients. It\u2019s common when an account gets hacked that malicious inbox rules are created, usually to forward all emails to an external account to which the hacker has access, combined with another rule to delete emails thereafter.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">To block forwarding to all external domains for all users, you can run the following PowerShell Exchange Online command:<\/span><\/p>\n<pre>Set-RemoteDomain Default -AutoForwardEnabled $false<\/pre>\n<h2><span style=\"font-weight: 400;\">Enable Safe Links Policy For All Users<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Theoretically, Safe Links is a great email security feature. It is supposed to scan all URLs in an email and wrap the URL to a re-written URL that, when clicked, requires the destination page to be scanned by Microsoft\u2019s URL scan service. If it identifies the destination URL as malicious, it will not redirect the user there and will instead show a warning to the user that the link is unsafe. I say \u201cit\u2019s great in theory\u201d because it can overlook <\/span><i><span style=\"font-weight: 400;\">some<\/span><\/i><span style=\"font-weight: 400;\"> malicious URL. But nonetheless, if you are not using a third-party email protection service (which I <\/span><i><span style=\"font-weight: 400;\">highly<\/span><\/i><span style=\"font-weight: 400;\"> recommend you do, as Office 365 has a long way to go to be a solid email protection offering), this is better than nothing.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Fortunately, it\u2019s simple to enable safe links with PowerShell using Exchange Online commands.<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">Note that the policy doesn\u2019t offer a built-in way to apply these rules to all users. Instead, you have to specify a group that contains the users that you would like to apply the policy to.\u00a0<\/span><\/p><\/blockquote>\n<p><span style=\"font-weight: 400;\">The best way to do that is to create a dynamic group with the criteria to contain all users with a mailbox; that way, you are sure to have a group that is always updated to contain all mailboxes as they are added or removed automatically.<\/span><\/p>\n<pre># Don't forget to change this\r\n$ExclUrls = ('url1','url2')\r\n$GroupName = \u2018ChangeMe\u2019\r\nNew-SafeLinksPolicy -Name 'Enable Safe Links Policy' `\r\n    -EnableForInternalSenders $true `\r\n    -DoNotTrackUserClicks $false `\r\n    -IsEnabled $true `\r\n    -DoNotAllowClickThrough $true `\r\n    -ScanUrls $true `\r\n    -DoNotRewriteUrls $ExclUrls `\r\n    -ExcludedUrls $ExclUrls `\r\n    -Enabled $true\r\n\r\nNew-SafeLinksRule -Name 'Enable Safe Links Rule' `\r\n    -Priority 0 `\r\n    -SentToMemberOf $GroupName `\r\n    -Enabled $true `\r\n    -SafeLinksPolicy 'Enable Safe Links Policy'\r\n<\/pre>\n<h2><span style=\"font-weight: 400;\">Anti-Spam Settings With Region Blocking<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Next up is setting up anti-spam settings. Again, if you do not use a third-party email protection service like Mimecast, Barracuda or Proofpoint, I highly recommend you do so as they offer much better protection and detection than Office 365. Otherwise, you can use the commands below to create a default anti-spam policy to block emails that are from certain regions, fail certain authentication\/authenticity checks or otherwise appear malicious.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Here are some basic settings we can apply using Office 365\u2019s built-in Email protection.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">You can run the following PowerShell command with the Exchange Online PowerShell module as well.<\/span><\/p>\n<pre># Change the values of these variables\r\n$AllowedSenders = \u2018SenderDomain1\u2019,\u2019SenderDomain2\u2019\r\n\r\nSet-HostedContentFilterPolicy `\r\n   -Identity 'Default' `\r\n   -AllowedSenderDomains $AllowedSenders `\r\n   -BulkSpamAction MoveToJmf `\r\n   -BulkThreshold 7 `\r\n   -EnableRegionBlockList $true `\r\n   -RegionBlockList 'CN','NG','KP','RU','UA','TH','PH','JP','HK','TW' `\r\n   -HighConfidenceSpamAction MoveToJmf `\r\n   -IncreaseScoreWithBizOrInfoUrls On `\r\n   -IncreaseScoreWithNumericIps On `\r\n   -InlineSafetyTipsEnabled $true `\r\n   -MakeDefault `\r\n   -MarkAsSpamBulkMail Off `\r\n   -MarkAsSpamFromAddressAuthFail On `\r\n   -MarkAsSpamNdrBackscatter On `\r\n   -MarkAsSpamSpfRecordHardFail On `\r\n   -PhishSpamAction MoveToJmf `\r\n   -SpamAction MoveToJmf `\r\n<\/pre>\n<h2><span style=\"font-weight: 400;\">Anti-Phishing Settings<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">The anti-phishing settings can be created with PowerShell Exchange Online commands. I have set the policy according to what I think would offer the best mix of protection and functionality. Of course, you are free to adjust the parameters of the policy to your liking.<\/span><\/p>\n<blockquote><p><span style=\"font-weight: 400;\">Note that I have set the action for detected messages to \u201cQuarantine.\u201d As such, you should be sure to frequently check the Quarantine and release any false-positive emails if needed. Also note that I have enabled AntiSpoof protection, which may block emails that are legitimately sent from applications that are set to display the <\/span><i><span style=\"font-weight: 400;\">Send From<\/span><\/i><span style=\"font-weight: 400;\"> address as one of your users. If there are emails that are blocked as a result of the anti-spoof protection, you can always whitelist selected users and origin email servers. To do so, please refer to the article on the command <\/span><a href=\"https:\/\/docs.microsoft.com\/en-us\/powershell\/module\/exchange\/advanced-threat-protection\/get-phishfilterpolicy?view=exchange-ps\"><span style=\"font-weight: 400;\">Get-PhishFilterPolicy<\/span><\/a><span style=\"font-weight: 400;\"> from Microsoft.<\/span><\/p><\/blockquote>\n<p><span style=\"font-weight: 400;\">Please see commands below:<\/span><\/p>\n<pre># Change the values of these variables\r\n$PolicyName = \u2018Custom_AntiPhishing_Policy\u2019\r\n$RuleName = \u2018Custom_AntiPhishing_Rule\u2019\r\n$InclGroups = ('Group1','Group2')\r\n$ExclGroups = ('ExclGroup1','ExclGroup1')\r\n$ExclDomains = ('Domain1','Domain2')\r\n$ExclSenders = ('Sender1','Sender1')\r\n\r\nNew-AntiPhishPolicy `\r\n\t-Name $PolicyName `\r\n\t-AuthenticationFailAction Quarantine `\r\n\t-EnableAntispoofEnforcement $true `\r\n\t-EnableAuthenticationSafetyTip $true `\r\n\t-EnableAuthenticationSoftPassSafetyTip $true `\r\n\t-EnableSuspiciousSafetyTip $true `\r\n\t-Enabled $true `\r\n\t-EnableMailboxIntelligence $true `\r\n\t-EnableMailboxIntelligenceProtection $true `\r\n\t-EnableOrganizationDomainsProtection $true `\r\n\t-EnableTargetedDomainsProtection $true `\r\n\t-EnableTargetedUserProtection$true `\r\n\t-EnableUnauthenticatedSender $true `\r\n\t-EnableSimilarDomainsSafetyTips $true `\r\n\t-EnableSimilarUsersSafetyTips $true `\r\n\t-EnableUnusualCharactersSafetyTips $true `\r\n\t-PhishThresholdLevel 3 `\r\n\t-TargetedDomainProtectionAction Quarantine `\r\n\t-ExcludedDomains $ExclDomains `\r\n\t-ExcludedSenders $ExclSenders\r\n\r\nNew-AntiPhishRule `\r\n\t-Name $RuleName `\r\n\t-AntiPhishPolicy \"Custom_AntiPhishing_Policy\" `\r\n\t-SentToMemberOf \"$InclGroups\" `\r\n\t-ExceptIfSentToMemberOf $ExclGroups\r\n\r\nSet-AntiPhishPolicy  `\r\n-Identity $PolicyName `\r\n-EnableAntispoofEnforcement $true `\r\n-MakeDefault\r\n<\/pre>\n<h2><span style=\"font-weight: 400;\">Custom Mail-Flow\/Transport Rules<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">As an additional measure of protection, you can create custom Exchange rules to block or redirect emails that meet certain conditions. I\u2019ve come across one particular suggestion that I thought would be great to share. It suggests creating a rule that blocks email that contains the word Bitcoin! I thought that to be a great idea.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">See the PowerShell Exchange Online commands below to create such a transport rule. (Note that you can, of course, add other cryptocurrency keywords to use as the basis for a quarantine.)<\/span><\/p>\n<pre># Change the values of these variables\r\n$RuleName = 'Quarantine Bitcoin'\r\n$Keywords = 'Bitcoin','Bit coin','Keyword3'\r\n[int]$PriorityLevel = 0\r\n\r\nNew-TransportRule `\r\n\t-Name $RuleName\r\n\t-FromScope NotInOrganization\r\n\t-SubjectOrBodyContainsWords $Keywords\r\n\t-Quarantine $true\r\n\t-Priority $PriorityLevel\r\n<\/pre>\n<p><span style=\"font-weight: 400;\">You can also create other rules that block attachments that match file types based on regex patterns, create a rule to Prepend Subject with the word \u201cEXTERNAL\u201d on all mail sent from outside the organization as a measure to help prevent users from falling prey to spoofing, and more. Leveraging Mail Flow rules is a great and granular way to enhance the protection of your Office 365 environment.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\">Conclusion<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">I hope you have found this article informative and helpful for protecting your Office 365 tenants. Please feel free to take a look at <a href=\"https:\/\/www.msp360.com\/resources\/blog\/author\/isaac-sofer\/\">other articles<\/a> I have posted previously on the MSP360 Blog for tips and references for PowerShell scripts I have created to help automate and run Exchange and MSOL commands to administer Office 365 tenants.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>In this article, we will be reviewing the next set of recommended steps to take to secure an Office 365 tenant. These steps revolve around Office 365\u2019s built-in protection policies, including Anti-Spam, Anti-Phishing, Anti-Spoofing, custom Mailflow transport rules, and a few general organization-wide policies.<\/p>\n","protected":false},"author":72,"featured_media":34410,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[877,885],"tags":[],"class_list":["post-34403","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-articles","category-other"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts\/34403","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/users\/72"}],"replies":[{"embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/comments?post=34403"}],"version-history":[{"count":1,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts\/34403\/revisions"}],"predecessor-version":[{"id":59956,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts\/34403\/revisions\/59956"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/media\/34410"}],"wp:attachment":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/media?parent=34403"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/categories?post=34403"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/tags?post=34403"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}