Re: Microsoft Software Auditing ?

From: Adam Jones (ajones1_at_gmail.com)
Date: 04/14/05

  • Next message: Matthew Cook: "Re: fport on windows 2003 server" 
    Date: Thu, 14 Apr 2005 10:14:23 -0500
To: security-basics@securityfocus.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
    ----------------------------------------------------------------------------

  • Next message: Matthew Cook: "Re: fport on windows 2003 server"

    Relevant Pages

    • Re: IBM/Lenovo Serial Number and Model Type
      ... Both applications are very small executables <20K each that can be set as scheduled tasks to run at any time using any standard Windows scheduler. ... The licensing we offer for the hardware inventory enables the executable to be loaded on each machine and can be set to run at any time the system manager wants to gather the data eg; every 3 or 6 months rather than via daily log files etc. ... The resultant hardware audit and patch results files are unencrypted text files so as to enable loading to any database and can be extracted off the local PC at any point in time so that bandwidth degradation or server utilization loads permit. ... The tools are not interactive and can be set to run and deliver the results on demand or at defined intervals that are prescribed in your own scheduler. ...
      (microsoft.public.sms.inventory)
    • Re: Inventory script question
      ... I ended up writing a VERY simple script to call the program that writes the inventory to the database. ... If you script the polling into the logon script then you get a whopper of a load every morning when people report for work, which is exactly what you said you wanted to avoid. ...
      (microsoft.public.windows.server.scripting)
    • Input from a text file
      ... I have posted the part of an inventory script that connects to WMI. ... I'd like to change it so I don't have to wait for a user to logon for me to update the inventory. ... For Each strComputer In arrComputers ... 'Change this to the UNC path where inventory files should be created ...
      (microsoft.public.scripting.vbscript)
    • Re: Inventory script question
      ... I set my script to Sleep for 60 seconds, and the message that popped up was that this version of the Processor did not support UNC pathing. ... I tried to set the DWORD value to 0 this morning, reset the inventory date, and rebooted the machine... ... We've put it into the test group, and applied it as a GPO... ... Alternatively you can use the WriteLine method of the File System Object to write the same information into your log file. ...
      (microsoft.public.windows.server.scripting)
    • Re: Query to test the existence of a folder
      ... wouldn't you have to compile the SMS_def.mof on all clients anyway so really it is a script, ... I'm no SMS admin. ... I disagree, yes I know you don't like me disagreeing with you, but I am disagreeing anyway:-P ... So if you don't mind to inventory all folders on your systems than this shouldn't be that difficult a mofedit. ...
      (microsoft.public.sms.misc)