Acquiring a Company... What to look for security-wise?

SoCalGuy858SoCalGuy858 Member Posts: 150 ■■■□□□□□□□
Much like a thread I posted previously about building a security department from scratch...

My company just made a public offering to buy another company after multiple unsuccessful attempts over the years. Nothing has happened yet, but if it does:

What things would you look out for in the company you are acquiring? Priorities? Anything of note by those who may have done this before? (Lessons learned, frustrations, etc.?)

I figure that the responses would be similar to those regarding building a security department from scratch, but it can't hurt to ask!
LinkedIn - Just mention you're from TE!

Comments

  • SoCalGuy858SoCalGuy858 Member Posts: 150 ■■■□□□□□□□
    Mods: I thought I posted this in the Off Topic forum. Can someone move it, please?
    LinkedIn - Just mention you're from TE!
  • gespensterngespenstern Member Posts: 1,243 ■■■■■■■■□□
    IP subnetting, major PITA during acquisitions, everybody loves dat 192.168.0.0/24 network and even if your org uses rarely used subnets in 10.0.0.0/8 chances are acquired company can also use them and you end up with intersections. So long term solutions here is to reIP them, short term is to use DNS doctoring.

    Another hot issue is security patching. It often gets broken because of various reasons but you'd better fix it. It is a major issue since patches may break functionality but there are often no personnel willing or capable of fixing these issues since many will leave and the once who don't are often not the brightest or haven't dealt with the system in question. So management often pushes not to patch them. But CISO and their folks push to patch them and this fight can go either way, I would personally suggest to patch them as I witnessed very stupid hacks before that could be easily prevented if we patched the systems.

    Before considering patching you need to get an idea on what assets have you acquired. With MS stuff it's easy to get using ADDS and WMI, there are custom scripts that collect information, but there's an awesome tool from MS called MAPT (or MAP?). It goes through all the systems collects info and produces awesome reports.

    It is important because OS patching is obvious, but what about 3rd parties software. I once was in a situation when ColdFusion engine installation was overlooked during acquisition and since this product is very weak security wise some hacker from the internet got in using an unpatched vulnerability in this product. You don't want to be in such a situation.

    Another consideration is domain trusts. There's an argument on if it's worth it or not. Depending on levels of literal trust towards acquired infrastructure people either 1) don't establish trusts at all 2) establish one-way trusts (they trust our forest, our forest doesn't trust them) or 3) full-blown two-way trusts. Third and second are obvious, in case of the first you can rely on Windows credentials manager/windows vault on acquired Windows workstations to store credentials that give access to your forest for employees of acquired company. Don't forget that you can employ selective trusts so you don't trust blindly every account from acquired forest.

    Still, acquired company computers aren't on the same level of trust as your own configuration-wise. Almost always they eventually get reimaged, because you don't trust their config that may contain incompatible settings, stupid configurations, etc., but this process can easily take years. You need to lay out a plan on what should be digested first, what on a later stage, etc. You don't start this process with the most important systems because you need first gauge your ability, measure how this process will go, etc. After successful reimaging first group of servers you can have enough data and confidence on planning digesting their most important systems.

    For the purpose of easier management you may want to immediately add their servers to your SCCM for a) asset information b) security patch management c) software deployment. That's not always an easy thing to do because you can't use SCCM's "push" client installation because their servers/workstations aren't trusted. I usually relied on custom scripts that deploy preconfigured SCCM client to the servers.

    There's a lot more, these are just off the top of my head, sorry, don't have time right now to expand more on this
  • SoCalGuy858SoCalGuy858 Member Posts: 150 ■■■□□□□□□□
    Thanks for the post! These are exactly the kinds of things I'm looking for!
    LinkedIn - Just mention you're from TE!
Sign In or Register to comment.