Security audit action list for CIOs
By Ed Tittel
Establishing a proper security posture is
absolutely essential and involves well-known steps of risk assessment, threat
analysis, and formulation of an organizational security policy. Every bit as
important is making sure the security policy evolves with changing needs and
business conditions and keeping barriers to unauthorized entry in place while
countering new threats and vulnerabilities as they arise.
No tool does a
better job of helping to maintain a proper security posture than a security
audit. Security audits come in different strengths and flavors, and each has its
own appropriate uses and frequencies. As a CIO, you should be familiar with each
type. Your security staff (or security vendors, when such functions are
outsourced) should apply these on a regular basis to the premises, systems,
processes, procedures, and networks under their purview.
Vulnerability scan
The vulnerability scan is a type of security audit that
systematically tests for vulnerability to specific well-known attacks,
especially those based on failure to patch or update key software or
infrastructure components and known points of access or attack. Vulnerability
scans may be performed by in-house or out-of-house staff and should be conducted
at least once a month, and immediately after potentially dangerous
vulnerabilities are discovered or become well-known on the
Internet.
Penetration testing
Vulnerability scans
are routinely automated and generally passive in nature, but penetration testing
can attempt to actively compromise system, physical, or procedural security.
It’s a great way to assess security posture, practices, and procedures, but it
is also time-consuming and costly. For many organizations, this is an optional
form of security audit that may or may not be used during annual security audits
or as part of general security reviews. Penetration testing is highly
recommended for environments with stringent security requirements, however
difficult or expensive such testing may be.
Security checklist
review
The security checklist review employs published or publicly
available checklists for specific types of platforms, applications, or services
to make sure that software is up to date, configurations locked down, and
potential points of attack closed. At a minimum, such reviews should be
conducted quarterly and immediately after any new or upgraded installation is
brought online.
Security policy review
A security policy review examines an organization’s security
policy in detail. For example, you might implement this type of review on
software and devices, as described in employee documents, training, and legal
agreements, as implemented in vendor and consulting relationships and
agreements, and so forth, to check that current configurations, implementations,
procedures, processes, and documentation agree with the security policy. Such
reviews should be conducted at least yearly as part of a thorough external
security audit. Whenever systems, processes, or procedures change, at least a
partial policy review should be conducted for those parts of the policy that are
(or might be) affected.
Physical security audit
Either in the wake
of moves, mergers, or acquisitions, or as part of an annual external security
audit (see next item), it’s essential to review physical access controls and
emergency procedures for an organization’s sites, buildings, server and
equipment rooms, and any areas where proprietary assets are stored or used. This
is particularly important for information systems and related assets because
physical access to these items by the wrong person can lead to their theft or
loss.
Annual
external security audit
Routine or
event-driven security audits may be conducted by in-house or out-of-house staff,
but just as external auditors routinely perform annual financial audits, so also
should external security auditors perform annual security audits. In both cases,
such audits provide valuable insights into internal attitudes and practices, as
well as feedback on policies, procedures, and guidelines that govern related
systems.
Event-driven audits
Only by reviewing
and assessing the existing security policy can a CIO really decide what kinds of
security audits should be undertaken and at what frequency. These various
components can then be part of a regular security regimen with a frequency that
varies from annual to monthly. Finally, you can also implement event-driven
audits for security scanning as new vulnerabilities are uncovered or for
security checklist reviews as systems and platforms are updated.