Whereas monitoring is a routine general process of watching
the network for potential problems with the network security, auditing is a more
specific test or series of tests on the network to determine the effectiveness
of the security measures, as well as compliance with the policy and any relative
regulations. Auditing, like monitoring, should be specifically defined, and
allowed within the formal security policy.
The random nature of audits as compared to routine monitoring
makes them useful in detecting unauthorized internal activity within the system.
For this reason, audits shouldn’t become routine or scheduled. Much of their
usefulness is diminished if your troublemakers can predict when an audit will
occur.
Shareware tools are available on the Internet and even many
operator-triggered system tests can be automated by the use of scripts.
Checklists of features to audit for many technologies are available on the
various security web sites. Some auditing is low tech. It can be as simple as
periodically reviewing the tape backups to confirm the backup was run when
scheduled, that it covered everything specified, and that the tape has a usable
file. Other reasons for audits might include the following:
-
Any addition to or change to systems in the network. Has the
new system or the change (upgrade) possibly brought with it some unknown
problem? This shouldn’t be an optional audit.
-
Spot checks of policy compliance.
-
Regularly checking password files for compliance with the
password policy.
-
Router and switch configuration compliance to make sure all
appropriate security requirements are included.
Commercial auditing tools or even network intrusion tools
like Cisco Secure Scanner can perform ongoing auditing, including looking for
potential security holes. Some of these tools come from a variety of vendors,
but might only run on certain management stations. This is one area where UNIX
seems to have a clear edge.
p1c1improving