Perimeter
4/11/2012
11:14 AM
Connect Directly
RSS
E-Mail
50%
50%

Be Ready To Clean Up That Mess

Compliant systems do more than prevent problems -- they help solve problems that happen

In our assessment and consulting projects, we often find clients who see compliant systems as those with the best wall of protection, like a great castle surrounded by the seas and cliffs. Granted, great security is wonderful. But it is not the end of the story; security alone will not make your organization compliant.

If you dig into any of the various laws and regulations that require compliance in various industries, you'll find they do not assume secure systems can never be breached. Full, impenetrable security is never the final metric of compliance. Secure systems are very important, but the ability to detect problems and address them is also critical.

In Kelly Jackson Higgins' recent Dark Reading article, "Damage Mitigation As The New Defense," Dave Piscitello, senior security technologist for ICANN, shared the current security reality: "Organizations that are only now coming to the realization that their network perimeters have been compromised are late to the game," he said. "The criminal application of collected/exfiltrated data is now such an enormous problem that it's impossible to avoid."

If your security and compliance efforts are focused primarily on preventing breaches and leaks, then you'll be woefully unprepared to properly respond when things go wrong. Compliant systems include processes and procedures for checking the security and steps for a prompt response.

The day after a data breach goes public or the CEO asks where the data went is not the day you want to be developing a response plan on the fly. Any unplanned, impromptu responses can even contribute to making the problem worse.

Any company or IT leadership that believes their security is complete and total has yet to face reality. They're living on borrowed time. As the old saying goes, "The problem with making systems foolproof is that fools are so darn ingenious." And so are those with ill intent.

Today's reality is that we can never make a system completely secure and still reasonable to use. There are simply too many continually evolving threats to ever be prepared to stop them all. Proper detection and response are not reactions -- they are processes that can be defined and documented.

Can you plan a response for every possible problem? Of course not. Smart plans include a framework of response steps with room to adjust the plan as necessary for specific situations. That's more than just good response planning -- that's good business planning.

Assuming you'll never be attacked, hacked, breached, or betrayed is not only naive, it is arrogant and risky for your organization and career. A strong compliance program understands that the world is always evolving, and therefore so must our processes for both security and for problem response.

Glenn S. Phillips, the president of Forte' Incorporated, works with business leaders who want to leverage technology and understand risks within. He is the author of the book Nerd-to-English and you can find him on twitter at @NerdToEnglish.

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

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-2595
Published: 2014-08-31
The device-initialization functionality in the MSM camera driver for the Linux kernel 2.6.x and 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, enables MSM_CAM_IOCTL_SET_MEM_MAP_INFO ioctl calls for an unrestricted mmap interface, which all...

CVE-2013-2597
Published: 2014-08-31
Stack-based buffer overflow in the acdb_ioctl function in audio_acdb.c in the acdb audio driver for the Linux kernel 2.6.x and 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to gain privileges via an application that lever...

CVE-2013-2598
Published: 2014-08-31
app/aboot/aboot.c in the Little Kernel (LK) bootloader, as distributed with Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to overwrite signature-verification code via crafted boot-image load-destination header values that specify memory ...

CVE-2013-2599
Published: 2014-08-31
A certain Qualcomm Innovation Center (QuIC) patch to the NativeDaemonConnector class in services/java/com/android/server/NativeDaemonConnector.java in Code Aurora Forum (CAF) releases of Android 4.1.x through 4.3.x enables debug logging, which allows attackers to obtain sensitive disk-encryption pas...

CVE-2013-6124
Published: 2014-08-31
The Qualcomm Innovation Center (QuIC) init scripts in Code Aurora Forum (CAF) releases of Android 4.1.x through 4.4.x allow local users to modify file metadata via a symlink attack on a file accessed by a (1) chown or (2) chmod command, as demonstrated by changing the permissions of an arbitrary fil...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.