Re: Microsoft Software Auditing ?

[Adam Jones <ajones1 () gmail com>]

> That I have to disagree with. If I understood the OP right, he just
> wanted to inventory the software (rightfully) installed on the system.
> Since there is software that comes as a standalone executable so it
> won't show up anywhere. How would one inventory this kind of software
> w/o scanning for executables?

In that respect scanning it makes more sense, although I still think
that it would be better to use an auditing tool instead of relying on
a script to handle the process.
> These may be an issue, but require users to have write-access (which
> they shouldn't). Overwritten executables will most likely be detected by
> comparing the file's hash against a known-good baseline. The other two
> may be a problem, but AFAICS only if users are allowed to write files.
> If one just wants to take inventory of the installed software I don't
> consider this an issue.

AFAIK you are right about the write-access requirements. I believe I
mentioned later that auditing the system for a better user rights
assignment scheme would be more productive, which would obviously
include restricting write access. I think what I was really getting at
was advocating using an already made solution instead of writing a
script to do it, as the time invested would not really be worth it.
> CRC is neither intended nor appropriate for detecting wilful/malicious
> manipulations of files. You need to use other hashes (at least MD5) for
> that purpose.
Yeah, that was my goof. I would love to claim that I was busy and
mixed up my acronyms. In reality though the CRC comment was me
thinking more about the time required to do the task than how the task
would be best accomplished. IIRC MD5 and stronger take more time to
generate anyways, which could add to the time invested in the project.

> > There are applications that will detect NTFS alternate data streams,
> > those would probably need to be run as a second scan of the system.
> True, but only if you want to detect malicious changes to the system.
There are only two reasons I can think of to keep a record of
executables on the system: tracking malicious changes and tracking
documented/undocumented changes made with a patch. Both require
essentially the same record-keeping. I guess I assumed that in looking
to keep these records the OP was also looking to be able to audit for
malicious changes.

Really my point was that creating this kind of documentation via a
script developed in-house is not a worthwhile investment of time. A
lot of auditing tools were suggested at the start of this thread, and
I wanted to illustrate where they may do a better job than a homemade
script could. In addition documentation of this kind is time consuming
and prone to quickly being rendered unreliable.

-Adam

---------------------------------------------------------------------------
Earn your MS in Information Security ONLINE
Organizations worldwide are in need of highly qualified information security
professionals.  Norwich University is fulfilling this demand with its MS in
Information Security offered online.  Recognized by the NSA as an
academically excellent program, NU offers you the opportunity to earn your
degree without disrupting your home or work life.

http://www.msia.norwich.edu/secfocus_en
----------------------------------------------------------------------------