tvm at a new company

no new problems

i recently started a new job and am faced with the usual: “please set up our scanners and Make Us Secure”, “What Do These Alerts Mean”, etc etc. i keep thinking about the scanning / threat and vulnerability management (TVM) aspect, so i want to write about that. here are a list of questions that i’ve been asking myself, along with some possible answers.

using an existing scanning install or starting over

it may be reasonable to nuke an install if:

times when you definitely should not nuke an install:

those are really the only hard constraints i can think of. everything else seems pretty grey

are naming schemes important enough to spend time on

hard yes. some of the names in use at my new place are frankly hilarious. and bad. “aaah, a scan template called ‘corp users’, what do you suppo - oh, its for scanning production? of course.”

i picked a rough naming scheme template for all objects, and then tweaked it on a per-object-type basis, i.e.:

ProductName - Environment - Geolocation - Data

“search - prod - aus” is pretty straight forward, and then the ‘data’ field can be where you really express differences between the object classes. if it ends up looking a bit different between object classes, that’s ok. the most important thing for naming schemes is consistency to the rules you set. everything else, while still important, is secondary.

a note on scan schedules

think about what a particular scan is trying to accomplish. if the goal of a scan is to get data from corporate servers then a typical overnight maintenance window makes sense.

if the goal is to get data from the entire corporate netblock then scanning over night is probably really stupid, unless the entire company works during that time. after all, most companies are deploying large laptop fleets that all get taken home at the end of the day! instead, you can tackle this by doing one of these:

ok, apparently the title should be “two notes on scans”. if your goal is to scan sensitive production servers make sure you reach out to the ops team that manages those servers. they should know, you should have a paper trail proving you at least made best efforts to communicate, etc.

what other things should I check on