Re: Server asset inventory tool

[David Escalante <david.escalante () BC EDU>]

From a network scanning perspective, I agree with Kevin.

Assuming that you surmount Kevin's points, and have a network-derived 
list of all the "servers" associated with your institution, where maybe 
a "server" is anything listening on a well-known port, you still don't 
know what KIND of server it is (e.g. Raspberry Pi vs. HP blade chassis), 
or what software is running on it, beyond whatever banners the network 
software grabbed.  And, more important, you don't know who a given 
server belongs to unless you manage to derive that from the name, the IP 
address, or some other manual process.

Because of all this, server asset inventory tools, including manual 
ones, tend to be incomplete, incorrect, and out of date.  It's not that 
they don't have utility -- they do -- but only if you understand what 
you want the server asset register for and how it'll be maintained. 
Focus on how you'll get accurate and useful data, and maintain that data 
over time, from a process perspective.  If you get that right, it's way 
more important than what s/w you use.
--
David Escalante
P.S. If you're a vendor and reading this, please don't contact me and 
explain how your tool solves any and all difficulties pointed out in 
this thread.  We're not in the market.....

Kevin Wilcox wrote on 4/26/19 4:26 PM:
> On Fri, 26 Apr 2019 at 08:05, Angel Howard 
> <alhoward () georgiasouthern edu <mailto:alhoward () georgiasouthern edu>> 
> wrote:
>
>     We are also using a manual process.  Would love to know what
>     others are using in terms of a solution and how they have
>     automated the process. 
>
>
> We're in the middle of an RFP so I can't speak to specific products 
> but I'll toss out a few things to keep in mind when folks go looking.
>
> o if you have a SecOps person (or persons), they should have access to 
> read your Azure/AWS/ESXi/whatever configs, and all of those have great 
> APIs to list VMs and their info
> o if you have decentralised IT, don't be surprised to have your 
> automated scanner blocked (for malicious activity, connecting on 
> monitored ports, failed logins)
> o you may have internal networks that aren't accessible - and not 
> every product allows scanner proxies or provides an agent
> o several will offer functions that overlap with other tools, e.g., 
> your vulnerability scanner (installed software/versions, users, 
> filesystem info, etc)
>
> This is especially timely for us as we're also simultaneously 
> expanding our SIEM sources and working on EPP/EDR procurement; the 
> question of "wait, what data is available from where and via which 
> API?!" is one that's permanently residing on my tongue these days.
>
> kmw

Attachment: david_escalante.vcf
Description: