cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Contributor II

Divestiture planning

I'm working up a rough-hewn divestiture plan, and came to realize there's a lot of stuff to uncover.  From scrubbing Active Directory data on servers that could leave in an asset purchase, to determining the scope of a password change (and whether or not both sides should endure a password change!), to changing admin- or manager-level passwords and SSIDs on all departing equipment... there's a lot of stuff that must be thought of and properly managed to preserve confidentiality.

 

My most principal concern would be to prevent AD data (and password hashes for a whole company) to leave in a divestiture.  One solution is to force a password change on the remaining company, but I would rather scrub the AD information from departing servers instead.  It seems simpler

 

Anyone have any tips they can share on divestiture planning?  Especially in the case of AD.  Thanks!

---
Eric Geater, CISSP
I've always said, "There's nothing an agnostic can't do if he really doesn't know whether he believes in anything or not."
6 Replies
Highlighted
Community Champion

Re: Divestiture planning

You may receive many responses, but this is one of those "it depends"
questions. Do you have a data retention plan or policy to reference? Many
of the answers that you seek would be informed by that policy. Yes. I have
many answers, but it depends upon your business policies that you must
observe.

--
Lamont29
Lamont Robertson
M.S., M.A., CISSP, CISM, CISA, CRISC, CDPSE, MCSE
Highlighted
Newcomer II

Re: Divestiture planning

I have to agree with Lamont - there is a lot that depends.

 

My personal course of action would be to get involved with the deal team and/or the legal department (and make friends with these folks) to understand what they are planning to include in the sale.  Ultimately, many of the concerns you have can be front-loaded.

 

I've been through a number of divestitures and acquisitions and it is quite typical to see AD, servers, VMs, etc, stay with the selling organization and the new organization then spins up new servers they have procured to stand up the necessary environment and import data that is provided (after being reviewed and appropriately sanitized). 

 

To summarize: Get involved early and often, make the legal/deal team aware of the implications, and understand what is being included in the sale.

Highlighted
Contributor II

Re: Divestiture planning

This is an area where we're working to develop our policy so that it can inform our decisions.  Oftentimes, as you may have experienced, IT is something that just creeps from its dark recesses on stakeholder request, and can be easily overlooked until it's too late.  This is part of my strategy, in fact, because what is not governed by policy would definitely require hasty decisions.

 

Funny side note: back in January, our IT director at the time was aware of an acquisition which was scheduled to complete in 75 days. His executive decision was to fully leave IT out of the process until the week before the acquisition took place.  It wasn't a funny story at the time, of course.

 

Stuff like this is why I like asking lots of annoying questions.

---
Eric Geater, CISSP
I've always said, "There's nothing an agnostic can't do if he really doesn't know whether he believes in anything or not."
Highlighted
Community Champion

Re: Divestiture planning

This could be a big issue - such as did they deploy an Enterprise PKI system attached to the AD itself, plus did they use other tools such as Sharepoint.  My main concern would be exactly where, what, how and who has access to the current organisation data, and has it been classified, categorised and who is authorised to see that data.   How will you ensure that any residual data, whether under contractual agreements, is not accessed by the remaining company or is being accessed by unauthorised personnel.   How will you ensure that all systems residual data has been suitably cleansed, and confirm to be sanitised?   Which may include metadata, in various formats and types i.e. unstructured and structured data.

 

What about the actual systems themselves i.e. servers physical, virtual memory, storage systems and any other places where data could reside without peoples full knowledge over time.

 

Plus you can add paper records, electronic records, databases, and any off line storage systems as well.

 

Regards

 

Caute_cautim

Highlighted
Newcomer III

Re: Divestiture planning

I guess tha it depends to some extent on scale and the nature of the
divestiture. If you're spinning off a business unit to go it alone it will
need its own infrastructure and services so it will need something going
forward in order to continue trading. If it's simple and small enough you
may want to consider rebuilding from the ground up.

We see things more from the acquisition point of view. Typically, we take
on data using an OS-neutral approach so we import the data, files or
whatever but absorb them into our own structure as the acquisition's OS and
security/privacy posture are matters over which we had no control. That is
often simpler and safer than trying to be clever. Things like email domains
we handle by export/import and tweaking DNS to re-point MX and SPF records.
Websites we prefer to absorb rather than run in parallel. Blah, blah, blah.

If you're divesting to another parent company and it's halfway competent,
then deal with the team at the new owners. If after initial prowling and
sniffing around to get the measure of ech other you can do business, you've
saved yourself a ton of work. They're no more likely to want a load of guff
out of your AD than you are likely to want to lose it.

Best
Tim
Highlighted
Community Champion

Re: Divestiture planning

 

 

@ericgeater, ensure that the scope is properly defined --- if you miss out anything and have to deal with it at the last moment, things are likely to get overlooked.

 

The policies of both the organization getting rid of assets & the one acquiring them will have to be considered & enforced as needed, lest there be unwanted consequences.

 

And I can't stress enough on the need for documentation. If this isn't being maintained properly, there will be a host of problems at all stages.

 

Nowadays, IT is integrated into everything, so someone from your team should be involved at the start. Alas, it doesn't always happen that way --- I've often seen projects agreed on at the top level, & then just 'dumped' on IT, with the result that they lag or eventually fail.

 

I'm sure you've already done a good lookup for info on this; if not, here are 2 sources that might be useful: -

 

https://www.alexandria.unisg.ch/219829/1/JML_339.pdf

https://www.intel.com/content/dam/doc/best-practices/intel-it-it-leadership-managing-it-aspects-of-l...

 

 

 

 

 

Shannon D'Cruz,
CISM, CISSP

www.linkedin.com/in/shannondcruz