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.

Perimeter

2/23/2012
11:23 AM
50%
50%

Five Dangerous Compliance Assumptions

Many businesses fool themselves about their compliance problems

After 20 years of working with clients, I am still left shaking my head at the number of companies that declare with great confidence they are “fully compliant” when it is obvious they are not even close.

I think we all understand that compliance means conforming to applicable rules, typically specifications, policies, standards, or laws. Seems simple enough, right? Apparently not.

I find many organizations, especially those with fewer than 200 employees, that are claiming full compliance but have rarely even read the full requirements. This is particularly true in industries where compliance has no official compliance certification, such as HIPAA. They may have skimmed over a summary of the requirements, usually choosing to ignore certain parts by convincing themselves these rules don’t apply to them. These decisions are often made by a single employee, who then proclaims the company compliant and enables his or her fellow employees to blindly accept, and even promote, this convenient, but false, claim.

Companies that incorrectly claim compliance are usually making too many assumptions, some that benignly support their arguments, but others that dangerously fuel false beliefs concerning these companies’ capabilities or security.

Here are five dangerous compliance assumptions I see frequently:

1. “We’re secure -- that makes us compliant. We use passwords and firewalls.”
Whether I uncover it in an onsite assessment or in casual discussions with management, this belief is surprisingly common. Even if the IT team knows it not to be true, if management “feels safe,” they “feel secure.” It is an easy stretch to assume “feeling” secure means legitimate compliance with meaningful security standards.

2. “The IT manager said we are complaint.“
I think the old Russian proverb addresses this one best: Trust but verify. Every good organization has checks and balances throughout, even small organizations.

Bookkeepers are checked by accountants, who are checked by external CPAs. When I write, I have someone proofread my work and then an editor checks it. Having more than one point of confirmation is critical, as even the best of us can miss something important.

3. “Strong physical security is not really necessary here, we are all trustworthy.”
While that is admirable to think, it is usually just a lazy excuse to avoid restricting access to those who don’t actually need it. Or sometimes it can be a social problem: “Oh, Sally will think we don’t trust her if we restrict her access to the server room or that database.” Security is not about trust. It is about following a process designed to protect everyone, including Sally, and your other employees.

4. “Really complex, frequently changing passwords are the most secure.”
This assumption totally ignores the human component of security. Is a really complex password more secure from hacking tools? Sure. But far more security breaches come from access to passwords written down because they are too complex to remember. I don’t know many people who can remember “Er55%P22eRq12121z,” and to expect anyone to is foolish.

5. “The computer has a login, so it is secure.”
Unrestricted physical server and computer access is incredibly common in small organizations and retails stores. It is not uncommon in medical practices for the server room to be a closet, with the door left open so the equipment won’t overheat. If someone steals the server or a computer, they will then have as much time as they want to bypass your login. Your equipment might be more easily stolen than you realize.

Naturally, there are dozens of dangerous assumptions a company can make -- some more obvious than others. Because compliance requires a specific mindset, including changes to routines and embracing new habits, it can be like eating healthier or getting more regular exercise: We know it is very important, possibly even lifesaving, but often we don’t take action until it’s too late.

Glenn S. Phillips, the president of Forte' Incorporated, works with business leaders who want to leverage technology and understand risks within. Glenn works with business leaders who want to leverage technology and understand the often hidden risks awaiting them. The Founder and Sr. Consultant of Forte' Incorporated, Glenn and his team work with business leaders to support growth, increase profits, and address ... View Full Bio

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 6/1/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-20811
PUBLISHED: 2020-06-03
An issue was discovered in the Linux kernel before 5.0.6. In rx_queue_add_kobject() and netdev_queue_add_kobject() in net/core/net-sysfs.c, a reference count is mishandled, aka CID-a3e23f719f5c.
CVE-2019-20812
PUBLISHED: 2020-06-03
An issue was discovered in the Linux kernel before 5.4.7. The prb_calc_retire_blk_tmo() function in net/packet/af_packet.c can result in a denial of service (CPU consumption and soft lockup) in a certain failure case involving TPACKET_V3, aka CID-b43d1f9f7067.
CVE-2020-13776
PUBLISHED: 2020-06-03
systemd through v245 mishandles numerical usernames such as ones composed of decimal digits or 0x followed by hex digits, as demonstrated by use of root privileges when privileges of the 0x0 user account were intended. NOTE: this issue exists because of an incomplete fix for CVE-2017-1000082.
CVE-2019-20810
PUBLISHED: 2020-06-03
go7007_snd_init in drivers/media/usb/go7007/snd-go7007.c in the Linux kernel before 5.6 does not call snd_card_free for a failure path, which causes a memory leak, aka CID-9453264ef586.
CVE-2020-4026
PUBLISHED: 2020-06-03
The CustomAppsRestResource list resource in Atlassian Navigator Links before version 3.3.23, from version 4.0.0 before version 4.3.7, from version 5.0.0 before 5.0.1, and from version 5.1.0 before 5.1.1 allows remote attackers to enumerate all linked applications, including those that are restricted...