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.
The Musing?
"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.
- Etc…
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’.
Acknowledging Reality
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.
https://hbr.org/2012/09/ten-reasons-people-resist-chang
http://www.huffingtonpost.com/morty-lefkoe/is-it-really-human-nature_b_906331.html
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:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
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
- Etc…
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…
Office 365 URLs and IP address ranges
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.
- Etc.
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:
https://support.office.com/en-us/o365ip/rss
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.
Bottom Line
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.
with all due respect, IT admins are used to change. it’s ingrained in our souls.
the problem with O365’s “new paradigm” is that the rate of change is accelerated to the point where the IT admins are getting squeezed by MS trying to wring more money out of their customers and by their own bosses who were sold on “O365 will allow your IT team to stop supporting menial office tasks and focus on big picture ideas that will make you more money.”
surprise, all the qualified IT admins understand the squeeze is on and tell you to go pound sand. how could anybody possibly be surprised at this.
I would clarify your statement and say true IT admins are used to change and embrace it. Those folks acknowledge and adapt to the dynamic nature of the beast. There are others, however, that I would say don’t handle it as well (or at all) that wouldn’t fall into my (and your) definition of an “IT Admin”.
O365’s rate of change is just the tip of the iceberg in the market. Look at Android and iOS – they are updated on a nearly continuous basis as well. Adobe’s Creative Cloud. Azure. AWS. Salesforce. The list goes on. DevOps and the high rate of churn is simply a reality in the marketplace for many solutions we rely on. There’s no denying that MSFT and others are moving towards the subscription-based model for various reasons (both perceived as “good” or “bad”). You are also right in that sometimes the “sales pitch” doesn’t match up with expectations. That’s long been the case with on-premises solutions though, so I can’t pin-the-tail-on-the-cloud-donkey for that expectation not always being met.
Despite all that, IT is supposed to be a business enabler. Many customers I’ve interacted with have strained relationships with their internal IT folks because IT has been proven to be a business inhibitor. Our internal IT was largely viewed that way at my previous employer, as well. Granted, sometimes we (the IT group collectively) were keeping the business from shooting itself in the foot so the pushback was needed but other times we simply didn’t deliver or didn’t deliver on time or didn’t deliver what the business asked for. O365 is often utilized because it’s a faster approach to enabling the business and I do agree that this is often the case – not always, but very often. If the admins tell me (as in the guy who’s helping an enterprise deploy/migrate to O365) to go “pound sand”, it doesn’t hurt ,my feelings. The people who might care – the business users – may have something different to say when they aren’t able to use something they’ve purchased the rights to use or may have business plans that depend on.
“The people who might care – the business users – may have something different to say when they aren’t able to use something they’ve purchased the rights to use or may have business plans that depend on.”
are these the menial labor business users that work in the contact center and have no say in anything? or are these the leadership team business users who created/enabled the security team to make the decisions that are the root of the caution that protects the company from itself and subsequently slows cloud adoption?
because either way, their complaints won’t get very far – unless they’re some SMB fiefdom where the proprietor/entrepreneur has dictator status – in which case they’re already making terrible decisions on a daily basis anyway so they have absolutely nothing to lose by just handing the reigns over to MS.
the rest of us have change control and SMEs who are taken seriously when they raise an issue that slows cloud adoption. I suppose it also helps to have a leadership team that trusts their own VPs and Directors too.
also nobody makes a business plan that depends on a specific tool. For example, “we don’t have O365 operating yet, but I’m going to assume I can use power BI when creating this business plan.” it isn’t done that way.
“are these the menial labor business users that work in the contact center and have no say in anything? or are these the leadership team business users who created/enabled the security team to make the decisions that are the root of the caution that protects the company from itself and subsequently slows cloud adoption?” – Could be either. Or both. Or another group. At the end of the day those users are the customers of IT, so I don’t make a whole lot of distinction and simply aim to provide whatever service is needed to the users, regardless of a label.
“Nobody makes a business plan that depends on a specific tool” – How about continuity plans that require tools such as routers, switches, data centers, servers, applications, tape drives, data circuits, etc? The business plan, which relies on the continuity plan, absolutely requires specific tools in that case. Or maybe the business plan is dependent upon certain cost structures being reduced so that investments could be made elsewhere to grow the business. Many avenues here but the business plan certainly does rely on implementation of people, products, and services to fulfill.
At the end of the day, I think you and I are discussing the same side of the coin. I not saying that SME’s and Change Control aren’t valuable because they absolutely are. Concerns are to be raised, acknowledged, discussed and worked through – there is no denying that. It is fruitful to discuss concerns and arrive at a resolved issue, if possible. There are certain facets though, that simply can’t be avoided in the SaaS world. It’s largely unavoidable for me, for you, and every other customer out there.