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.
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.
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.
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.