Merging IT and security strategies that were developed at different times, under different conditions, and different management teams is no simple task. In one organization that I worked for, innovation and growth was handled through merger and acquisition. A trend that is quite common in the current economy as businesses look for opportunities to gain new markets, increase their corporate strengths, and bring in new talent and ideas.
The organization when I arrived had just completed 2 substantial acquisitions, extending its reach across Canada, parts of the UK, and 2 US states. The IT team and I faced huge challenges in merging technologies, introducing a structured IT strategy, and unifying information security practices.
All 3 businesses were considerably behind the times in terms of their security programs. There were no security policies to speak of, and head office relied primarily on contract IT and information security staff used primarily for after-hours support and fire-fighting missions. The smaller units had basically no security considerations beyond the firewall. It was basically building the program from the ground up in terms of staffing, training, equipment, policies and procedures.
There had been several minor security events and at least one major incident involving malware that needed immediate attention. These incidents supported my suggestion to unify and update multiple anti-virus products to a single primary vendor offering, supported by layered anti-virus at the gateway. A defense in-depth approach using multiple vendor offerings in a structured manner stemmed the tide of malware incidents.
The larger technology aspects were equally challenging. One business was using Active Directory, but not the version that head office was using. The other business was running good old Novell Netware. Nobody was using GPO’s or other management control structures. The routers and switches were compatible, for the most part, but the network integration was still fraught with challenges. No two organizations even shared a common email platform. All of the servers and services in the business at each location needed to be catalogued, patched, audited, footprint minimized, and configuration recorded. Many were found to be insecurely and less than optimally configured, and in some cases, redundant. Several were wiped and re-purposed, others were hardened and placed on a maintenance schedule.
We started working on “the plan” in January, and by June, it had developed well, bringing all three businesses into one strategy, at least on paper. The actual integration took another twelve months to get right, and policy development was an ongoing thing. One of the first hurdles was simply becoming familiar with the physical and logical design of each operation and its satellites, as well as the staff at those facilities. We worked closely with the regional IT departments, relying on their expertise throughout the migration, because they did things completely differently than we did.
Each location faced its own set of challenges, having had a history of using a variety of different vendors and consultants. When a technical incident happened and a server went down, we had all these different companies saying, ‘Oh no, not us, it’s them, or maybe it’s them’. We wanted to get one service provider we could call for everything, or at least one provider for each continent. We settled on two major providers, eliminating about six others for regional support, and also used them both for Disaster Recovery as alternate providers in a pinch.
The security strategy had to include the regulatory considerations for each global region, and we settled on governance based on the ISO-7799 standard, derived from the British 17799 Standards, coupled with specific governance for the industry we operated in, and a dose of guidance from NIST standards. We also introduced ITIL practices in order to streamline, align and unify our processes, such as Change and Configuration Management. It was a challenge to gain adoption of ITIL practices in the Eastern and Western most provinces more so than anywhere else mainly due to politics, however once these offices saw how little unplanned downtime we incurred, how quickly we could back out a change to restore services, and how well documented our infrastructure had become to support change, ITIL was greeted with a little more zeal.
With the introduction of Configuration Management and hardening standards, it was understood by all why a server existed, what services were expected to be running, that it was as well protected as it could be, and any changes to that configuration could be monitored and detected. Change Management was a more challenging sell, as it forced the “cowboys” in the smaller shops who were used to “just winging it” to stop, think, and plan the execution of every change. Approvals meant accountability, and downtime had repercussions beyond your own perimeter. Suddenly the time-table previously built on IT’s convenience, whenever Joe or Frank was available and ready, was brought up to the level of management that it needed in order to be successful. Resistance was high at first, but eventually continued successes, and failures, made questions like “Where’s your back-out plan” “Do you have your procedures documented” and “What else is scheduled during that window” commonplace. It will still rarely be fun to sit in on a CAB meeting, and Change Management takes more time than making it up on the fly, but the impact that planning has on stabilizing an organization’s IT assets is profound.
This organization is now one of the largest and best run in its industry, and they continue to grow. I am proud to have had the opportunity to help make these changes a reality and hope that I have left a legacy. All the best, and continued success!