Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives  Connecting marketers to our tech communities.
SPONSORED BY
8/17/2017
09:00 AM
Raymond Pompon
Raymond Pompon
Partner Perspectives
Connect Directly
Twitter
RSS
50%
50%

How to Avoid the 6 Most Common Audit Failures

In a security audit, the burden is on you to provide the evidence that you've done the right things.

I’ve been through quite a few audits over the years, including a number of failures detailed recently by experienced auditor, Kyle Robinson of Grant Thornton. Here are six ways Robinson spells out to avoid these common audit failures.

Audit Failure #1 - Poor prioritization from the Top
A big part of a CISO’s job is to ensure alignment of the security program with the organization’s objectives. This is a two-way street: the program must be right for the organization, and the organization must feel right about the program. Security programs that are forced down the throat of the organization end up being spit back out. For a CISO, this means discovering what an organization values and then explaining cyber risks and controls in those terms. If the CISO can tie risk, and consequently the audit program, to what the organization cares about, then getting buy-in is easy.

Audit Failure #2 - Lack of Documentation
In an audit, the burden is on you to provide the evidence that you’ve done the right things. There is no presumption of innocence, and auditors rarely take you at your word. If you did not document something, then an auditor will assume you didn’t do it. Documentation shows consistency (We’ve done it this way every time.) and constancy (We’ve been doing it that way for years.). It also creates a pathway for training and automation as things are clearly spelled out as opposed to being known only to one key person (who will soon be quitting).

Luckily documentation isn’t hard to do if you write it as you go along. Start with high-level policies describing your intentions, write standards to define how things should be done, and then procedures to describe how they will be implemented.

Audit Failure #3 - Human Error Compounded by too many Manual Processes
Wherever humans are involved, mistakes and oversights will happen. It’s folly to assume otherwise. There are two simple techniques to manage this: reduced scope and defense-in-depth.

For audits, the scope is everything. If something is not in scope, the auditor will not need to look at it. For example, by leveraging the principle of least privilege you could remove administrator rights from everyone except a handful of IT professionals who absolutely need it. Then you have fewer people who need to be background checked, use strong authentication, and follow change controls. Fewer moving parts, fewer chances of failures.

Defense-in-depth means adding additional controls to back up the controls that could fail. A common audit failing is the admin not disabling a user on that user’s last day. A secondary control could be added for periodic review of users to HR records to ensure accounts match up.

Audit Failure #4 - Weak or Missing Risk Assessment
Since everything you do in security should be based on risk, a complete risk assessment is a must. But, what is a good risk assessment? Some people confuse a list of failure scenarios with a risk assessment. Stating that a DDoS attack could cripple your organization is not a risk statement, it is a statement of impact. Risk statements must include probabilities of occurrence of the threat such as: “It is highly likely in the next year that we will experience a DDoS attack that cripples our Internet services.” Conversely, the chance of a threat occurring alone is not a risk statement. Receiving lots of password guessing attacks against your SSH services is not a risk. However, if you say “there is a high likelihood of an SSH attack succeeding with an attacker gaining access to confidential data,” that is an actionable risk statement. I have discussed this in more depth in Can Your Risk Assessment Stand Up Under Scrutiny?

Audit Failure #5 -  Internal Assessment too Self-Congratulatory
One of the principal tenets of security is to assume breach, which means to expect your security system to fail at some point and plan accordingly. A corollary to that concept is to assume control failure. It’s one thing to deploy a control like a new security policy or strong authentication. It’s another for it to be used properly to reduce risk and meet audit objectives. The best way to know if it is functioning properly is to test it regularly. This is where you can leverage internal auditors, external consultants, vulnerability scanners, and penetration testers. Any large system is going to have occasional lapses, so follow up and keep improving. It’s better for you to test something and find it failing than for an auditor or attacker to do the same.

Audit Failure #6 - Misunderstanding that some Audits are Ongoing
Many people assume they have a single audit once a year and that’s the only time they need to have their security program running properly. Putting aside the huge security risk this creates, you can also consider this a significant compliance risk. Even if an organization is currently subjected to only periodic point-in-time audits, there is the ever-growing likelihood that unexpected audits and assessments could suddenly spring up.

The FTC has become notorious for performing pop quizzes for U.S. organizations with potential security problems. Many business contracts and third-party agreements often contain “right to audit” clauses that allow business partners to conduct or demand independent assessments of security programs. I’ve seen contractual clauses that only give the audited organization 48 hours warning before the audit team arrives onsite with their checklists and magnifying glasses. With the prevalence of third-party security failures and regulatory guidance regarding testing them, these are only going to increase. It’s safe to assume that even if you aren’t being audited now, you will be soon.

Get the latest application threat intelligence from F5 Labs.

 

Raymond Pompon is a Principal Threat Researcher Evangelist with F5 labs. With over 20 years of experience in Internet security, he has worked closely with Federal law enforcement in cyber-crime investigations. He has recently written IT Security Risk Control Management: An ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Major Brazilian Bank Tests Homomorphic Encryption on Financial Data
Kelly Sheridan, Staff Editor, Dark Reading,  1/10/2020
Exploits Released for As-Yet Unpatched Critical Citrix Flaw
Jai Vijayan, Contributing Writer,  1/13/2020
Microsoft Patches Windows Vuln Discovered by the NSA
Kelly Sheridan, Staff Editor, Dark Reading,  1/14/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Post a Comment
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-3686
PUBLISHED: 2020-01-17
openQA before commit c172e8883d8f32fced5e02f9b6faaacc913df27b was vulnerable to XSS in the distri and version parameter. This was reported through the bug bounty program of Offensive Security
CVE-2019-3683
PUBLISHED: 2020-01-17
The keystone-json-assignment package in SUSE Openstack Cloud 8 before commit d7888c75505465490250c00cc0ef4bb1af662f9f every user listed in the /etc/keystone/user-project-map.json was assigned full "member" role access to every project. This allowed these users to access, modify, create and...
CVE-2019-3682
PUBLISHED: 2020-01-17
The docker-kubic package in SUSE CaaS Platform 3.0 before 17.09.1_ce-7.6.1 provided access to an insecure API locally on the Kubernetes master node.
CVE-2019-17361
PUBLISHED: 2020-01-17
In SaltStack Salt through 2019.2.0, the salt-api NEST API with the ssh client enabled is vulnerable to command injection. This allows an unauthenticated attacker with network access to the API endpoint to execute arbitrary code on the salt-api host.
CVE-2019-19142
PUBLISHED: 2020-01-17
Intelbras WRN240 devices do not require authentication to replace the firmware via a POST request to the incoming/Firmware.cfg URI.