First off, all opinions and thoughts here are my own. You, my dear reader, are not required to agree with me nor are you required to read the post. Continue at your own peril.
Second, while I’m not a neurosurgeon, psychotherapist, psychologist, or sociologist, I can still use that mushy-grey-matter in between my ears to notice things and draw conclusions using deductive reasoning and critical thinking.
Third, I fully realize that I’m making some generalizations in my statements but I also realize that many of these generalizations have been proven time and time again by the customers/organizations I’ve interacted with over the past four years.
"A vast majority of Enterprises - but especially large(r) ones - act like petulant children when they begin their journey to 'the Cloud'."
This seems to manifest itself in multitudes of ways:
- Features/Functionality may be different, resulting in user training challenges and thus resistance (or outright refusal) to adapt.
- Internal Business Processes must be retooled to work around deficiencies or adapted to take advantage of enhancements, which sometimes never occurs.
- Cost model structures typically need to change to account for simple service consumption costs instead of complex CapEx/OpEx models that were previously used.
- Internal corporate fiefdoms battling each other to ‘maintain face’ or ‘maintain their ground’ or ‘maintain X reason for this is how it’s done’, resulting in significant delays or stoppage altogether.
As a result, Enterprises often act like children and throw temper tantrums, scream and cry, or go pout in a corner as a response to the changes seen as a result of their ‘Cloud journey’.
Despite my statements above, the reality is that all of these responses are natural to our human nature and our psychology. We, as humans, all hate change.
For all of the reasons I’ve listed in the previous section, there is a valid point to be expressed. Each one impacts the nature of the Enterprise and how it operates. It impacts not only the business but also those employed by the business, which include people like you and me. As a result, we all have skin in this game.
I make no argument that our concerns ought not be fleshed out. Concerns must be acknowledged, worked on, and resolved. If any organization is to be successful in the journey to “the Cloud”, they must embrace Operational Change Management and solve problems that arise.
That being said, there are one or two groups within IT that often exhibit a far greater resistance to change. They often remain steadfastly gripped to their existing ways, resisting at all opportunities, mumbling ‘over my dead body’ with each change that comes. Coincidentally enough, these are my old peeps. My old team members from a previous life. Folks responsible for defending the Enterprise castle from the Barbarians that seek to take it over. Who, you ask?
Information Security and their counterparts, Enterprise Networking.
The Enterprise Castle
For years, InfoSec and EntNet were responsible for defending the castle:
We used firewalls, VPN tunnels, IDP, IPS, HTTP proxies, and other defense-in-depth ‘stuff’ to keep the bad guys out. Our data and processes were based around keeping the Enterprise castle safe and making sure the crown jewels remained in the king and queen’s vault.
Where Office365 Breaks the Castle
With the advent of ‘the Cloud’ and offerings like Office365, the castle mentality fails at the outset. The Cloud is Saas (Software-as-a-Service) and runs in data centers outside of your control. You, the enterprise, interact with services that run over the public Internet and thus the ‘protect our internal stuff’ mentality fails because your ‘stuff’ isn’t internal anymore. Despite that, the SaaS ‘castle’ mentality is similar to the Enterprise ‘castle’ mentality: they still protect their internal stuff just as you do, but given that their castle contains jewels for multiple kings and queens, they operate in a new state that completely differs from how a single Enterprise operates.
When Office365 comes in the picture, InfoSec and EntNet usually steps in and issues their list of demands:
- Communication must be restricted only to specific IPs
- Ports must be restricted to only TCP/UDP ports required
- HTTPS traffic must be inspected
- We control how/where the traffic goes
Now this is fine-and-dandy to demand but the reality is that this is a tall order to implement. More importantly, some of these simply cannot be ascertained no matter how much you dislike it. Examples? Ok, no problem…
In the URL above, Microsoft provides customers with a centralized list of all the IPs, FQDNs, and TCP/UDP ports required to interface with their Office365 services. They even break it down by service…how nice of them! When this list is presented to InfoSec/EntNet, the push back is immediate and fierce:
- There are hundreds of IP ranges listed! Not allowed. We need something more specific.
- Our firewalls cannot handle DNS-based rules. See demand #1.
- The ports are too many (especially Skype4B)! Not allowed. We need to restrict them.
- The FQDNs are too many and go across too many domains. Not allowed. We need to restrict them.
While I ‘understand’ the asks above, the stark reality is that you won’t get your demands or there are significant issues with your asks:
- While MSFT breaks down the IP ranges by service, due to the dynamic nature of HA/DR within Office365 for each service, your data could be accessible via any of the IP ranges listed. If you restrict IP’s and a fail over occurs within Office365 that results in a different IP block now responsible for communication, and that IP block is not in your ‘allowed list’, then the fault is yours not Microsoft’s.
- While MSFT lists the TCP/UDP port ranges by service, you risk an outage if you alter your config to not allow the listed ports. There is a functional reason for those port ranges being required and you risk causing a service disruption for your end-users if you deny the ports. Don’t shoot yourself in the foot.
- MSFT lists FQDNs for each of the services because it is easier to administer by DNS than by ranges of IP blocks. MSFT adds and removes IP blocks and FQDNs from Office365 as required, so DNS-based resolution automatically keeps up with those changes if you can implement it. Otherwise, you – the Enterprise – must keep track of changes that occur to the service and respond accordingly.
Why OCM and the ‘petulant’ mentality matters
At the end of the day, Microsoft is providing you a service, guaranteeing that it will work with the published configuration. Despite that published information, nothing in IT is stagnant, and Office365 remains true to that statement. Almost every month Microsoft publishes updates to the Office365 FQDN/IP/Port page to an RSS feed that every single Office365 customer should follow because that RSS feed includes changes that are not yet active and published on the FQDN/IP/Port lists:
What typically happens is that Enterprises often take the original lists, plug them into firewalls, IDP, IPS, HTTPS proxies, etc, and then move on to other tasks. Until something breaks, that is, and then Microsoft support is involved and determines that the issue is because the Enterprise didn’t keep up with the changes in the Office365 service or that security was too restrictive:
- Maybe firewall rules weren’t updated to account for new IP blocks.
- Maybe HTTP proxies weren’t updated with new FQDNs.
- Maybe firewall rules weren’t updated to account for new TCP/UDP ports.
- Maybe client communication paths are using CDNs or other non-Microsoft controlled endpoints:
WARNING: IP addresses filtering alone isn’t a complete solution due to dependencies on internet based services such as Domain Name Services, Content Delivery Networks (CDNs), Certificate Revocation Lists, and other third party or dynamic services. These dependencies include dependencies on other Microsoft services such as the Azure Content Delivery Network and will result in network traces or firewall logs indicating connections to IP addresses owned by third parties or Microsoft but not listed on this page. These unlisted IP addresses, whether from third party or Microsoft owned CDN and DNS services are dynamically assigned and can change at any time.
Whatever the reason, it often boils down to a stagnant mentality by the Enterprise that change doesn’t occur, or that they don’t ‘agree’ with the change, or maybe it was just an honest mistake. For instance, 61 IP sets were added to the Skype for Business Online service this month, and those IP addresses become effective on 12/1/2016. You, as the Enterprise customer, simply don’t have an option on whether those IPs are used for your ‘stuff’. If you draw a line in the sand and say “NO! We don’t WANT it that way!”, then expect issues and egg on your face. The better option is to keep up with the changes and implement as required so that things continue to function.
I “get it”. I really do. I understand the ‘old mentality’ and the ‘castle’ mindset. That mindset will bite you though.
Enterprises and my fellow friends in InfoSec/EntNet must adapt to the changes and realities of a shared service like Office365. Every decision made is a trade off between security, usability, and risk. Microsoft isn’t perfect and neither are Enterprises. They are, however, doing their part in alerting Enterprises that may have stricter needs in regards to security. We all hate change, myself included, but change is a bona-fide fact of life and those who don’t adapt will suffer (or fail) in their journey. Please, please, please make sure you start thinking about OCM and how you will adapt to the dynamic structure of not only Office365 but also other cloud services as well. Your future truly does depend on it.