Keystroke auditing on OpenVMS Integrity v8.3-1H1

[Steve Reece_3]

Hiya,

We presently have AUDIT installed on our VMS systems to take logs of keystrokes from privileged users and other users that have access to a VMS prompt. This is a requirement for company auditing purposes.

Does anyone have any ideas of other tools that are available that can do logging of keystrokes on VMS for auditing?

What I'm specifically interested in is the keystrokes that the users put into the VMS system, not necessarily the response from the system. We also still want the input even if the terminal is set /NOECHO

Thanks in advance

Steve

[Jon Pinkley]

Steve,

It isn't clear to me if there is a problem with AUDIT, or if you are looking for a cheaper alternative.

Does AUDIT have the capability to log /input ?

My opinion is that keystroke logging by itself is of limited use from an auditing standpoint. A knowledgeable user with privilege and malicious intent, can disguise what they are doing with command files and other techniques. The point being that keystrokes alone are not sufficient. They can be useful for debugging and for determining what was being done when other auditing events occurred.

Jon

[Steve Reece_3]

Hi Jon,

We're evaluating options now that we're planning the move to Integrity. We don't just use keystroke logging/auditing, we use other things too, such as the auditing within VMS. The keystroke logging/auditing is but one of the tools that's necessary with corporate standards

Steve

[EWL · Accepted solution]

Hey Steve

We use Peek and Spy for the exact same thing. Works great.

[Steve Reece_3]

Do you have a web reference for Peek and Spy please?

Thanks
Steve

[Volker Halle]

Steve,

how about:

http://www.networkingdynamics.com/TheVmsStore.htm

Look at Peek & Spy and KeyCapture

Volker.

[John Gillings]

Steve,

I'm not a huge fan of keystroke logging. Who's going to read it?

The "poor man's" keystroke log is fairly simple. Arrange for the user to login to one username, which does a SET HOST/LOG to a second username (or system).

Ideally use two systems. The "audit" system has two network adapters. Users on one side, and "audited" system on the other. That way there's no physical path between the users and the audited system, except via the audit system. The users also have no non-captive access to the audit system, so even privileged users can't mess with the audit logs.

Give the users a captive account on the audit system with no password. The LOGIN procedure generates a log file name, then:

$ SET HOST/LOG


Note the username is SYS$INPUT for the SET HOST command. This will pass the username to the target system.

The user will therefore see only one "Username:" prompt and one "Password:" prompt. Whatever welcome message or LOGIN.COM output you generate will appear between the prompts.

On the audited system, have the SYLOGIN procedure check the source of all logins. Anything not from the audit system is immediately logged out.

I don't think this will capture /NOECHO input, but it's simple to setup and needs no special privileges or non-standard privileged code.

[Steve Reece_3]

I'm not a great fan either John, but audit requirements are audit requirements so it's not even worth having that argument with management.

Steve

[Jon Pinkley]

Here are some things you should check if you are using any of the terminal logging or keystroke logging utilities, especially if they are being used for auditing purposes.

Does it handle large QIO operations to TCPIP services TNA (Telnet) devices?

Does it survive a disconnect/reconnect on a VTA terminal?

Does it provide secure logging (at least for non-privileged users)? As John Gillings said, if the logging is being done on the same system as the privileged users being monitored, I am not aware of any way to guarantee that the logs will be valid. In other words, a user with CMKRNL privilege can compromise the logging.

Does it have the ability to post process the output to clean up the rubout processing? This makes the output easier to read, but may also hide some info.

[Ian Miller.]

System Detective does session logging and more

http://www.pointsecure.com/products/sys_det.aspx

[Steve Reece_3]

Does anyone have any direct experience of support and development of KeyCapture? Any idea whether there's a reasonable amount of development work happening or whether it's a team of one guy somewhere with an old VAX or Alpha maintaining the code?

Thanks

Steve

[Jon Pinkley]

Steve,

I don't have any direct experience with support/development of KeyCapture.

My guess is that none of these three commercial products have a large development group, and I would be surprised if any had more than one primary developer/maintainer for the products. I also doubt that there are many HP engineers dedicated to the VMS terminal driver.

I would guess that all the products that are logging on the node being monitored are intercepting the traffic between the terminal port/class interface via the GETNXT/PUTNXT routine pointers in the terminal UCB (UCB$L_TT_GETNXT/UCB$L_TT_PUTNXT). At least that is the most direct (most efficient) approach that I am aware of. Just for reference, PUTNXT is used for terminal input (it puts into the typeahead buffer); GETNXT is for terminal output (gets the next character or string (burst) to output to the user's terminal.)

In my opinion, the most important question is how well the design is documented by/for the product developers/supporters and how cleanly written the code is. This will determine how easily a new person will be able to support the product. Unfortunately, I know of no way to determine this from the outside, as the code is proprietary and closed source.

One indicator is the quality of the external product documentation. Another is how long it took each vendor to release an IA64 version of the product after OpenVMS IA64 became available. Although this is an indirect indicator, it is an externally visible indicator of the vendor's ability/desire to support the VMS market. Since these products are using internal features of VMS that are not in end user documentation, it implies that the vendors need access to the VMS source code listings (or at least a contact in VMS engineering that can provide select information).

Jon

[Rick Lade]

I have direct experience with KeyCapture v5.2.05 that is running on two AlphaServers clustered together. It has been invaluable in monitoring password changes which are normally blocked in SET HOST/LOG files and other AUDITing programs. It even works with terminals set to /NOECHO. Email me or give me a call if you want to talk personally about the product.

Rick Lade

[Brian Schenkenberger]

steve wrote:

>Does anyone have any direct experience of
>support and development of KeyCapture? Any
>idea whether there's a reasonable amount of
>development work happening or whether it's
>a team of one guy somewhere with an old VAX
>or Alpha maintaining the code?

I have VAXen, Alphas and Integritys. ;)

What seems to be the issue with AUDIT. If you really need the /NOECHO in the AUDIT log, that can be enabled. However, I think you will find with the other loggers -- as they intercept using the same patented approach -- that the keystrokes are missing from their logs as well.

Make the case to ProvN and it will become.

[P Muralidhar Kini]

Hi Steve,

You can try out the Key Capture tool.

Check the following link -
* Key Capture
http://openvmsalpha.com/75/key-capture/

Key Capture is a OpenVMS tool for logging/aduting the keyboard input for
a set of users. This should give you the feature that you are looking for.

The link mentions that the Key Capture is availble in ALPHA versions.
The Itanium version is yet to be released. Not sure if the IA64 version
has been released.

Hope this helps.

Regards,
Murali