In the past, security decisions were rarely included in the planning when it came to combining networks after companies merged — just getting the two systems up and running and talking to each other came first and foremost.
It was standard procedure to disable workstation firewalls, enable server message block (SMB v1) protocols and in general do everything the C-suite wanted. But in doing so, we made choices that not only added complexity but increased weaknesses in our networks.
Case in point was the long-standing tradition of setting up domain trust — migrating or joining the existing domain was just not done; rather, a domain trust and possibly multiple forests were set up and you went on with your business. The larger the firms, the more likely you merely connected the multiple systems by whatever means possible.
But neglecting to take time to review the existing infrastructure, folding in what worked and throwing out what didn’t, introduced complexity, insecure permissions, and typically a lack of understanding of network infrastructure.
Merged systems should ideally get a top-to-bottom review
In an ideal world, all network settings and options would be reviewed before businesses are integrated. Clearly none of us live in an ideal world, and unfortunately security teams must often plead the difficult case to a business that resources need to be taken from other projects to review infrastructure that is already working.
First and foremost, plan that you will be compromised, not that you might. Secondly, ensure that you identify your key Active Directory assets and consider the worst-case scenario of having to rebuild an Active Directory infrastructure from scratch — a daunting task. Ideally you will have an offsite and offline backup and have practiced the recovery of your domain. As with any recovery process, the more complicated it is, the harder it will be to recover from an attack.
