For FIM software:
Try to modify some components of the FIM software to see whether it can protect itself from being changed.
On systems with UFS/ZFS or VxFS, try to create some hidden setuid files or device files, and check whether the FIM software can detect these files.
Try to create some setuid files with multi-line names, and check whether the FIM software can properly detect all setuid files.
Try to create some setuid files and device files under /var/tmp, check to see whether the FIM software can detect these files.
For privilege delegation software:
If you have a script that can use the PD software to run as root, try to modify the script, and see whether the PD software can detect the script has been changed.
For a program that you can use the PD software to run as root, if it accepts an environment variable, try to assign a very long string to the variable and pass them to the PD software to run the program as root, to see whether it can cause problems. For better test of this capability, you should develop a simple C program.
Try to run view under PD software, and see whether you can escape from view command and run other commands as root.
For remote task automation software:
To see whether the software can protect the secret info used for remote login authentication from root copy attack or the attacks listed below.
For capabilities to combat secret info (such as password/passphrase/key) stealing attacks:
On system with dtrace/ProbeVue, copy the program to a different name, and run a script using that one as interpreter, and see whether the security software can detect it.
Use system call tracer to attach to the security software process, to see whether it can protect the secret info from being stolen.
On AIX, when security software is running, run trace to see if the software can detect it.
On Linux system, try to run a SystemTap script, and run your security software, to see whether it can detect the possible threat, as malicious person could use SystemTap script to steal sensitive info from your process,
With multiple terminals, run the security software that will ask user to input secret info, to see if it can remind user to check whether the number of terminal sessions match with user's expected number, provide user the info for detecting TTY key logger.
On newer versions of Linux, try to run a Kprobe or Uprobe script to see if the security software can detect that.
Run a debugger program to attach to security which is asking user to input secret info, check whether it can detect that in real-time.
After you entered password/passphrase/key to security process, try to save a core for the process, and run
$ strings core_file | grep "secret_info_you_entered"
to see if it will get the secret_info.
When the security software is waiting you to input secret info, run a
# sleep 60 </dev/mem
or
# sleep 60 </proc/PID/mem
Here the PID is the security software's process id.
To see whether it can detect the memory snooper.
When the security software is waiting you to input secret info, run a
# sleep 60 </dev/pts/n, here the /dev/pts/n is the tty device of the security software is running on.
To see whether the software can detect the TTY snooper.
For software that will use 2nd program to get password/passphrase/key from user, try to replace that 2nd program, and see whether you can get user entered secret info and the software is not able to detect such threat. Such as the one used by ssh and sudo in X-window environment.