Jaa

Trustworthiness of Information in Audit Records

  • Artikkeli

I get asked quite often "why is the Workstation name missing from some events?" I've explained that elsewhere. But this raises another issue that many of you might not have considered, and I want to take a few minutes to explain.

The Windows Security event log is designed to be as trustworthy as possible, and meets all the Common Criteria audit requirements for audit in our security target in the Controlled Access Protection Profile for EAL4+.

Basically that means that we log all the events that CC says to log with the information that CC says has to be in those events, that we have access controls in place to the log, that we detect log failure conditions and can be configured to prevent auditable activity in those cases, and that our design and development methodologies conform to the relevant CC requirements.

We have several basic strategies for ensuring the trustworthiness of the security log and the data in it:

  • Access control on both the APIs used to log events to the security log, and on the log itself for log access and log management.
  • A trusted path from the security subsystem (LSASS.EXE) to the security event log. By this I mean that we spent significant effort to protect the log from casual tampering; only a determined attacker with administrator credentials could cause the auditing system to malfunction in such a way as to prevent, alter or spoof events.
  • Default access control on the audit APIs to only allow audit generation by code that is isolated from user accounts.
  • Drawing on trusted sources such as system state whenever possible rather than relying on information passed in from APIs that could be called by a non-privileged user.

I want to address the last two points.

It is the case that most auditors (users of the security event log) want the events to be as "high-level" as possible. I know that you want events that say:

"Eric used Excel to change the executive compensation spreadsheet"

and not

"process ID 1289 running in context S-1-5-21-1235-6780-501 performed a WRITE_DATA on \dosdevices\c\shared files\exec_comp.xls".

However the isolation requirement causes us to instrument not in Excel, where we could indeed capture the menu and toolbar actions the user takes, but rather way down deep in the file system, where that information isn't available.

Look at it this way- if Excel could write to the log file, that means that the user running Excel could write to the log file, which means that the log file is no more trustworthy than the user. Obviously this is not desirable if you suspect the user of violating your business policy; the user might just take some action to cover their own tracks.

The sacrifice is that the audit is from the system's point of view, not the user's. This makes it harder to interpret, especially when you have an app like Word or Explorer which has unusual file access semantics. But we source all the information from in the file system where it's trustworthy; we don't depend on anything in the user's context telling us what to put in the audit record.

We often log events that were caused by remote activity. In remote logon cases the Common Criteria require us to include a "station name", if applicable, where the logon request originated. This poses an unusual problem for us. In order to log the remote station name, we need to know it. However we authenticate the user's credentials, not the workstation's, during a user logon event, and Windows supports multiple authentication protocols that can be transported across multiple network protocols.

It is often the case that the network protocol can't tell us the authenticated name of the machine at the other end of the connection (for example, IP). It is also often the case that the authentication protocol has no facility for transporting the station name (for example, Kerberos) or that the authentication protocol doesn't transport the station name securely (for example, NTLM). It's also the case that when we depend on the logon request to carry the station name, and the name is unauthenticated, that the station name is spoofable by a knowledgable attacker at the other end of the connection.

The bottom line is that sometimes to meet the "station name" Common Criteria requirement we were forced to include unauthenticated information ("workstation name") in the audit record.

Another problem is that many of you asked me, quite emphatically, to add IP addresses to Window Security events so that you can correlate these events with network device logs and other information about the network. When I proposed this for Windows Server 2003 there was a very vigorous debate internally because many people on the team were reluctant to add unauthenticated, spoofable information to the security event log.

The utility of the information, coupled with the number and intensity of the requests, won out in the end.

Also, I pointed out that IP address is not very spoofable in authentication traffic. Since the traffic is encrypted, requires a response by the client back to the server, and that response depends on the server's response to the client's initial request, and since all our authentication protocols travel over TCP, the spoofability is very low- an attacker must be in the same collision domain as one of the endpoints or must control an intervening router.

That's just some food for thought.

Comments

  • Anonymous
    October 26, 2006
    I wrote this as an answer for Tom, who emailed me, but I thought I'd share it with everyone. There are