Object Access Limitations. . .

While offering some visibility, there are limitations to object access monitoring.

If your organization has to comply with industry regulations such as GLBA, HIPAA, or Sarbanes Oxley, you know that maintaining data security and privacy are important, and one of the ways you can accomplish that is with object access auditing. As a managed security service provider, we are very familiar with the pros and cons of object access auditing.  With object access auditing set up, attempts to access or modify monitored files is logged, typically like this:

Jan 7 15:15:40: bjones performed action ReadData on E:\Company_Drive\filename_01.xlsx
——
Jan 7 15:15:40: bjones performed action ReadData on E:\Company_Drive\filename_02.xlsx
——
Jan 7 15:15:43: bjones performed action ReadData on E:\Company_Drive\filename_03.xlsx
——
Jan 7 15:15:49: bjones performed action ReadData on E:\Company_Drive\filename_04.xlsx
——
Jan 7 15:15:49: bjones performed action ReadData on E:\Company_Drive\filename_05.xlsx

Collecting all this data is only one part of the puzzle, however. How do we know when we should be concerned? Are user bjones’ actions here suspicious, or can we assume that bjones is a legitimate user going about his business?

Finding the answer may require additional knowledge. A check of the schedule will reveal if bjones was scheduled to work on the 7th, and a look at logon failures can show if the account may have been broken into. This need for extra information means object access reports on their own are not indicative of malicious behavior, but rather they are part of wider incident investigations that involve other contextual clues.

An added difficulty when trying to sort through the noise is that suspicious looking reports can be generated by the operating system automatically, simply because the user opened a directory. In the example above, it appears that user bjones copied a number of files—a potentially malicious act. Unfortunately with object access, just highlighting or right-clicking one of those files by accident can sometimes look identical to opening it and Windows does not distinguish between any of the “Read” actions.

This means that read actions alone do not contain enough information by themselves to be used without some other type of data, like a write action to another directory or some other type of complementary data from another log.

Because of these limitations, object access as it is currently implemented does not work as a data exfiltration control in and of itself, it just remains a piece of the data exfiltration puzzle.

Article written by Matt Jolley.  Beyond writing for the infotex blog, Matt is a Data Security Analyst for the infotex NOC.