|
|
Sponsored Content
Special Forums
Cybersecurity
IT Security RSS
Moving from Compliance to Measurable Security
Post 302295549 by Linux Bot on Sunday 8th of March 2009 08:00:06 PM
03-08-2009
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...
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...
|
|
6 More Discussions You Might Find Interesting
1. UNIX for Advanced & Expert Users
Hello,
I am trying to convince my boss to stop allowing our users to login as root (superuser). Currently our users login to our unix server with their own account, then as needed, they will do an su and put in the root password.
This scares me, for a bunch of reasons. Mainly, one is that we... (1 Reply)
Discussion started by: rwallaceisg
1 Replies
2. UNIX for Dummies Questions & Answers
In different online sources, I found bits and pieces of information about those square and angular brackets and pipes. From what I have read, I can conclude it looks like this:
1. Options outside any brackets are mandatory
2. Options inside these < .. > are mandatory too
3. Options inside ... (4 Replies)
Discussion started by: vkleban
4 Replies
3. Cybersecurity
From the nessus scanner tool report i got below vulnerability
PCI DSS Compliance : Insecure Communication Has Been Detected
http://www.tenable.com/plugins/index.php?view=single&id=56208
As per the description given in above link - I am not able to understand
How to find insecure port... (2 Replies)
Discussion started by: saurabh84g
2 Replies
4. Red Hat
Hi i am in new to Linux world . I have been assigned to a project to find out a tool that will fulfill the PCI compliance for Linux servers for Audit process. anyone have any recommendation on that. Do Rad hat have any native application or plug-ins which we can use for that. (1 Reply)
Discussion started by: sahasuman
1 Replies
5. HP-UX
I need to set password compliance for some servers in my company.
However, the requirements are that we need to set different password policies for 3 different user groups within the company. These are :
System Users: i.e root, etc
Batch/Application Users: oracle, bscs, etc
Standard User:... (0 Replies)
Discussion started by: anaigini45
0 Replies
6. OS X (Apple)
Thanks to all you guys about posix compliance I have learnt an enormous amount over the last few days.
I have written a program that is an Egg Timer with simple animation.
I now realise how sophisticated 'bash' is compared to full posix compliance.
The code below has passed all of the tests from... (11 Replies)
Discussion started by: wisecracker
11 Replies
LEARN ABOUT PLAN9
fsf-funding
FSF-FUNDING(7) GNU FSF-FUNDING(7) NAME
fsf-funding - Funding Free Software DESCRIPTION
Funding Free Software If you want to have more free software a few years from now, it makes sense for you to help encourage people to contribute funds for its development. The most effective approach known is to encourage commercial redistributors to donate. Users of free software systems can boost the pace of development by encouraging for-a-fee distributors to donate part of their selling price to free software developers---the Free Software Foundation, and others. The way to convince distributors to do this is to demand it and expect it from them. So when you compare distributors, judge them partly by how much they give to free software development. Show distributors they must compete to be the one who gives the most. To make this approach work, you must insist on numbers that you can compare, such as, "We will donate ten dollars to the Frobnitz project for each disk sold." Don't be satisfied with a vague promise, such as "A portion of the profits are donated," since it doesn't give a basis for comparison. Even a precise fraction "of the profits from this disk" is not very meaningful, since creative accounting and unrelated business decisions can greatly alter what fraction of the sales price counts as profit. If the price you pay is $50, ten percent of the profit is probably less than a dollar; it might be a few cents, or nothing at all. Some redistributors do development work themselves. This is useful too; but to keep everyone honest, you need to inquire how much they do, and what kind. Some kinds of development make much more long-term difference than others. For example, maintaining a separate version of a program contributes very little; maintaining the standard version of a program for the whole community contributes much. Easy new ports contribute little, since someone else would surely do them; difficult ports such as adding a new CPU to the GNU Compiler Collection con- tribute more; major new features or packages contribute the most. By establishing the idea that supporting further development is "the proper thing to do" when distributing free software for a fee, we can assure a steady flow of resources into making more free software. SEE ALSO
gpl(7), gfdl(7). COPYRIGHT
Copyright (c) 1994 Free Software Foundation, Inc. Verbatim copying and redistribution of this section is permitted without royalty; alter- ation is not permitted. gcc-4.3.0 2007-05-12 FSF-FUNDING(7)