How to FAIL a Security Audit

An unusual title perhaps—but many companies seem to know how to accomplish this feat without any help. The answer is simple: no security policy. Why? Without a security policy you (read your company) might have the most secure system imaginable—but without a policy to “measure it” (i.e., IT security audit), every setting is exactly that—just a setting. I congratulate you on your good guessing.

Commonly, there is either a complete lack of, or very outdated, security policy coupled with a system using 98 percent-plus default settings. In short, there’s no real focus on IT security. And I want to stress that this is for any operating system; for any application.

In short, lacking a recent IT security policy you will fail an IT security audit. (Do not confuse “security assessment” with “security audit.” An assessment can be used to help you prepare for an audit.)

In short, IT systems and applications security mechanisms should be driven by business policy that identifies risks, evaluates the probability and impact of these risks on systems and the business, and defines a “protection” scheme, a.k.a. security requirements. And it should include a section specifying the requirements to determine that it’s all working as intended.

In this sense, audit refers to “an auditor” who comes to inspect your policies, how effective the implementation of that policy meets your goals, as well as industry and legal requirements. I mention this because AIX also has a mechanism named “audit.” Do not confuse the context of audit process with the mechanism and vice versa.

Getting back to our title: “How to FAIL a Security Audit.” The result of an IT audit should also “FAIL” every time there’s no use of an audit mechanism. Likewise, no syslog “active” monitoring is also grounds for a “failed IT audit.” The difference between syslog and audit lies in who and where the decisions are made about what information is reported.

Security Management is a Business Responsibility

Unfortunately, too many people “responsible for the business” see implementing security measures only as an added expense. To them I want to say: “Penny wise is pound foolish.” Many companies never survive a serious security breach. Usually system administrators are aware of common risks, but lack the business perspective to identify business risks. For example, they lack the budget authority to make the time and money expenditures needed to even implement so-called best practice/common sense IT security measures. Result: IT audit FAILURE!

Security Management Is Managing Risk

Business management of security is managing risks. IT systems represent/contain/produce financial assets. That is right, think of automated systems as money! You might be able to survive losing your uninsured wallet and the assets it contains—but could you survive losing all your bank accounts (no/poor security policy is comparable to no insurance/under insured). Yes, there is some cost—but what risks are covered. In short, your security policy should accept risks that have low probability and impact—that you can survive without coverage but be sure you have mechanisms in place to mitigate unacceptable risks. Psst! An unknown risk is an accepted risk!

Be ready! And Be Sensible!

Get started on securing your business! too much insurance can bankrupt you. Do a risk analysis, get started on validating the security of your business. Your first step would be to read your security policy. Yes, you can spend too much, but it seems it is much easier to invest too little!

Start Cooking!

Keep coming back to SecuringAIX. I'll be sharing "recipes" for implementing AIX security mechanisms such as syslog, audit, RBAC, aixpert and trusted execution. Just remember you need to write the menu!

Comments

[Ian]

Why does no one ever mention actually having your security tested? Setting up policies and running syslog and audit are great but without a penetration test is like an untested backup; how do you know that you've closed the right holes and are gathering enough of the right information about breaches?

[Michael Felt]

Hi Ian,

Thanks for your comment. No one mentions it, I expect - because they are concerned about the results - regardless of the results. Saying we are ready or not ready are both inviting to potential attackers.

Currently most assessments I do are concerned with preparing for an audit that will show compliance. These customers are looking to documents such as PCI DSS v2 (see https://www.pcisecuritystandards.org/security_standards/documents.php) to identify the right holes.

Regarding auditors and compliance - too many "pass" audit and syslog if they are both enabled. The additional fact that neither of their configurations could be used effectively for forensics (after the fact) or real-time detection goes unnoticed.

In short, you pose a very valid question. My approach is to start with ensuring there are audit records of key components. Additionally, I start with a wide collection of auditable events. As time passes I filter out events that appear to have neither predictive nor forensic value. There is no "one size fits all" approach. If it were that easy I might not have a job :)