![]() |
Hello and Welcome from United States to the UNIX and Linux Forums! Thank You for Visiting and Joining Our Global Community.
|
|
google unix.com
|
|||||||
| Forums | Register | Forum Rules | Links | Albums | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
More UNIX and Linux Forum Topics You Might Find Helpful
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| A Model-Based Privacy Compliance Checker | iBot | UNIX and Linux RSS News | 0 | 11-26-2008 07:30 AM |
| Inside the SFLC's "Practical Guide to GPL Compliance" | iBot | UNIX and Linux RSS News | 0 | 08-27-2008 04:10 PM |
| ICT Cmte: Thailand?s Cyber Law Compliance Seminar | iBot | Complex Event Processing RSS News | 0 | 06-12-2008 01:50 PM |
| man synopsis standard compliance | vkleban | UNIX for Dummies Questions & Answers | 4 | 12-06-2007 08:18 PM |
| sudo & Sox compliance | rwallaceisg | UNIX for Advanced & Expert Users | 1 | 05-16-2007 06:13 PM |
|
|
LinkBack | Thread Tools | Search this Thread | Rate Thread | Display Modes |
|
|||||
|
Moving from Compliance to Measurable Security
Let’s face it compliance is a good thing. For what ever reason, people left to their own devices will make risky decisions, to lower cost, reduce effort, return a higher profit, or simply make a quick buck. It seems that people will often take the path of least resistance unless they fear it will cause themselves personal pain in the process. Rules are needed to compel people to do what is right or reasonable. A lack of regulation incubates an environment for abuse. If the state of the current economy does not fully illustrate this point then nothing will.
In the information security realm, compliance does have its downside. We end up with people trying to simply check a box by any means necessary. More often than not, the compliance attitude again reflects human nature to reduce cost and personal effort. The detractors for security regulations and compliance activities are quick to point to the mountains of paperwork and systems that abound with weak security as a contrary argument. But, the reality is that once again people will choose a path of least resistance. It’s easier for management to "accept risk" than build security into the system or devote resources to a security program. Many pundits call for "real security", but it is amazing that they typically offer no solid solutions. In fact, it is not clear what this "real security" constitutes. Maybe our way forward can be found through security metrics. We need a method that allows a comparison from one system to another by way of a common baseline. The goal of metrics is to provide a means to quantify the security of a system. The quantification should only include those aspects of the system which can be measured. Beginning with a common baseline, such as NIST 800-53, we can establish a mathematical approach to measure the implementation of each security control within a system. The following is proposed as one method to achieve this capability: Frequency: Establish the number of periods within a cycle of how often the control is implemented, measured, and/or evaluated. For example a control might be measured once a week over a period of a year. Instances: A control can be implemented in many different areas within a system. This measure is the total number of all instances where the control should exist within a system. Confirmations: Performance is measured by counting the number of times the control was confirmed to be implemented on a per instance basis within the system. Deviations: Non-compliance items deviate from the baseline and are used to reduce our performance measure. With these measurable attributes we can affirm: "Real Security" = (Confirmations – Deviations) / (Frequency * Instances) More... |
| Bookmarks |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|