The flip-side to your argument is that many of the exploits are found by "bad guys" before they are rediscovered by "good guys".
By definition, the "bad guys" don't typically believe in disclosure as it takes away another one of their 0day toys.
By disclosing weaknesses immediately you allow information owners to take precautions to protect their infrastructure, even if that means making the resource unavailable until a patch is provided by the vendor.
It is naive to believe that only "good guys" find problems. As soon as someone is considerate enough to share the problem, I believe it is in our best interest to be notified of it as soon as possible.
Your layer 7 firewalls, IDS/IPS, etc may work well against automated attacks but will fail against directed malice. If you think otherwise, contact me (PM) and we'll arrange a test of your network.
It's always funny to me to hear the "It's too hard" argument when it comes to Mandatory Access Controls. Quit being a pussy. You either care about security or you don't. You can't have it both ways. You can't say that "our security policy dictates x, y, z" and not provide systems that can actually enforce it.
They also get a bad rap because they don't work:).
It's a pitty they don't teach this stuff in CS: http://www.dyadsecurity.com/papers/rbac.html
http://www.nsa.gov/selinux/papers/inevit-abs.cfm
http://www.acm.org/classics/sep95/
rtsp://media-1.datamerica.com/blackhat/bh-usa-00/v ideo/2000_Black_Hat_Vegas_VK3-Brian_Snow-We_Need_A ssurance-video.rm
http://www.radium.ncsc.mil/tpep/library/rainbow/52 00.28-STD.pdf
http://hissa.ncsl.nist.gov/rbac/paper/rbac1.html
2) Pay the extortion fee Short term solution... long term disaster.
3) Buy lots of bandwidth and beefier equipment that can handle a large number of packets per second and a large number of concurrent connections. This is where you will also want to invest in a DDoS mitigation box like the toplayer etc devices.
This is a costly and time consuming way to go, and you will still have limits of what you can handle. A 100mb/s attack will kill a 10mb/s pipe every time, even with a $1,000,000 attack mitigator in front =).
4) Partner with a DDoS protection service like Prolexic. My company, Dyad Security - http://www.dyadsecurity.com/s_cleanpipe.html is a US reseller for the Prolexic DDoS protection service.
We have the infrastructure in place to eat the attack and keep you online. If you're offline, we can bring you back up very quickly (anywhere from 1-24 hours to get back online).
Re:Don't advertise version number
on
Hardening Apache
·
· Score: 1
That may seem like a reasonable request, but you should know that exploits, especially automated exploits couldn't care less about what version of a service you're claiming to run. They don't even care that it's the right platform.
The attacking system simply establishes a handshake, introduces the stimulus and waits for the response. If they get the desired response (shell, etc), great. If not, oh well, 1 down, 2^32-1 to go:).
Now for the flip side: As an admin, if you knew you were not playing silly cat and mouse games with your banners, you'd be able to quickly determine which systems are still out of date.
And now for something completely different: If you really want a secure user space application environment, you should build on a secure foundation. *BSD, UN*X (Solaris, AIX, HP-UX, etc), Linux, Windows, MacOSX, etc all employ a variation of Discretionary Access Control. DAC systems do not provide you the ability to actually enforce a security policy. Hardening an application on a DAC based foundation is akin to building a fortress on a foundation of sand.
If you require the ability to enforce your security policies, you need to start out with a sane and audited hardware base, and add on to it an OS equipped with mechanisms that provide for granular Mandatory Role Based Access Controls. You may consider the SE Linux project a good place to start.
"Moral The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect."
Basically, the higher of a language you use, the less secure you can possibly be because of all of the implications of trusting trust. If you can't audit it, you can't trust it. End of discussion.
Here is my general view of the "secure programming" world. It goes out to all developers.
Know your tools. Choose them wisely - Low level languages are not the problem; they are the most widely understood. Security is a process not a language. When your code inherits features and functionality that you did not intend, bad things can happen. Sure, we may not have buffer overflows, but if your RPC function allows me to execute any code that I want without overflowing buffers, who cares? Also, with these super portable "sand box" languages, I get to find one hole and exploit it everywhere. If you think Java is the answer, please tell me what language you think Java was written in? Also, please read "Reflections on Trusting Trust" by Ken Thompson.
Seeing the big picture - Peer review is part of the security process; your attackers are becoming very skilled at finding exploitable software bugs using automated tools to help them. Everyone in the development process needs to know the type of application they are developing and the sensitivity levels of the information they are protecting.
Rule of Simplicity - Design for simplicity; add complexity only where you must. Default to Deny, compartmentalization of code is good for more than just limiting security bugs.
Sweat the small stuff - Just because certain attack vectors are obscure does not negate their effectiveness; writing good clean code is safer and more sane than allowing a program to "protect" bad coding practices at execution time. We have seen many examples of how this other type of protection fails.
Don't use your customers as your Q/A staff - The Microsoft Software Release cycle is destroying security from the users and programmers perspective; it causes users to not want to upgrade, and it causes programmers to not want to fix security problems.
Don't build a $100,000 fence for a $1,000 horse - All data is not created equal, don't treat it as such. Let the protection be commensurate with the asset.
Audit trails - Trust with accountability. Every significant access, whether denied or permitted must maintain an audit trail.
For me, the value of a class is not in the test or even the certification at the end. The lasting value is in the knowledge and skill set that you refine and take with you back to your job. I also have made lasting relationships from the classmates, students, and instructors that I've met over the years. All of these mean a lot more
to me than the "e-i-e-i-o" at the end of my name.
I gravitated towards ISECOM'sOPST/OPSA classes because they fill a role I felt was missing in the security class space. Many non-vendor specific
security classes have a very narrow tools based focus. While I agree that knowing how to use your tools in a test is important, I feel knowing why and when to use them is far more important. Knowing the politics involved in testing, going over internationally accepted testing practices, and reviewing regional and national legal regulations are just as much part of the job. These things are not merely important, but are required to be successful in your role as a security tester. In addition to the intensely technical aspects of the testing process, this is what the OPST represents; the "professional" side of security testing. Also, the ISECOM classes teach from ISECOM's Open Source Security Testing Methodology Manual (OSSTMM) which provides a much needed methodical framework to bring a scientific method style to the chaotic world of security testing.
The CEH class represents the other kind of class. One that is "flashy", "fun", "exciting", but not overly useful to the serious professional.
While I have a lot of respect for Clément (one of the instructors for Intense School), I have very little respect for any organization that markets "hacker" classes. This includes the so-called ethical hacking, applied hacking, exposed hacking, grandmother hacking, squirrel hacking, super-duper 3y3 4m 31337 hacking, or any other fancy way of saying "Learn how to think and act like the bad guys".
While choosing where to spend your time and money, consider the community you are aligning with. If you look at ISACA, SANS, ISC2, ISECOM, etc.. they all have a true dedication to security and the betterment of the global information security community. Contrast the value of being affiliated (via education/certification) with any of those organizations over a piece of paper and a cd of toys.
I argue for the right of the "sovereign nations" in California to not pay taxes on their gambling enterprises. This is mostly because of the agreements we've made with the tribes in the past.
However, based on the doublestandard and greed I am seeing by those who run the casino's I'm changing my tune. You can't argue for receiving money from taxes and not pay taxes. If you want the freedom that comes with being a sovereign nation, you get the responsibility too.
Throughout history different types of educational systems have been common.
The rich tend to have a mentor/classics home school education where they learn how to think.
The middle class has had a professional education system (apprenticeships) where they learn when to think.
For many years the poor had very little education. It has been proven that educating even the poor can and does raise the overall standard of living, so many nations will adopt some sort of public schooling for the poor. This education system is geared to teach students *what* to think.
It's the students from the last system that will be working in the lowest of jobs, requiring the most control.
The best way I know to measure something is to test it, and the best methodology I know of to test network security is the Open Source Security Testing Methodology Manual (OSSTMM).
You can download the latest version from http://www.osstmm.org. The latest is 2.0, although the 2.5 version has been slated to come out VERY soon, so check back in the next week or so for the update.
The OSSTMM is the most widely used peer-reviewed "Open Source" security testing methodology in existance. It is contributed to by security testing professionals all over the globe. It is definately worth checking out.
Although the OSSTMM does an excellent job at defining the "What" to do in a security test, ISECOM also has created two courses to teach the "How" and the "Why" in more detail. You can find out more about the OPST (the in the trenches tester/technical course) which teaches how to get the information for an OSSTMM based security test, and the OPSA (manager/analyst) which teaches how to analyze the information and manage the testing team at ISECOM's main site: http://www.isecom.org.
*disclaimer*: I work for a company that is partners with ISECOM.
Best way to measure security is to measure it...
on
Securing Your Network?
·
· Score: 4, Informative
* Disclaimer * - I work for a Security Testing Company.
1st step in security is to perform a risk assessment. The goal of Risk Assessment is to determine if the security controls for a system are fully commensurate with its risks. Without having an understanding of your risk you are unable to determine the proper security policies, procedures, guidelines, and standards to put in place to ensure adequate security controls are implemented. We want to avoid putting a $1000 fence around a $100 horse, but at the same time avoid undue risk.
Once that is completed, you need to create a security policy. This policy is what your company is officially trying to accomplish with it's security initiatives. Until you know what your goals are, any money or time is not going to be well spent.
Once you believe you have your goals from the policy implemented, you may wish to have a Posture Assessment. Posture Assessment is the act of measuring the gap between your information security posture and your information security policy. This is a thorough review of your existing security policies where each stated goal is converted into a test module. Each test is run until a sufficient amount of data is collected to measure the existing posture (The security Posture is what the company is actualy doing).
Assuming the Policy and the Posture match, you may additionaly with to verify that all the bases are covered and request a verification Penetration Test on a specific set of systems with a stated goal for the test, or an out and out Ethical Hack attempt (same idea as a Penetration test, but not as limited in scope). This will uncover holes in not covered by the Security Policy.
You should also consider periodic testing. Some of this should be done internally, some is best to outsource.
A security test is only valid if it is: * Quantifiable -- Can be numerically measured
* Consistent and repeatable -- Two testers would receive the same test results at the same time
* Valid beyond the "now" time frame -- Lasts and remains valid longer than the wet ink on the report
* Based on the merit of the tester and analyst not on brands -- It is based on smarts and not expensive tools
* Thorough -- A complete test where nothing is left untested from the scope
* Compliant to individual and local laws and the human right to privacy -- Puts the protection of personal privacy before corporate data
As a person involved with sales, I value my time. People who do not want to be harrassed should not be called. The only thing it accomplishes is to make them have bad feelings towards your company. That being said, I believe that the industry (telemarketers) should be in favor of these types of lists and make strides to enhance customer loyalty. They should have an industry maintained list, as the penalty for harrassment is loss of sale and bad feelings. A happy customer might tell 2-3 of his closest friends. An upset customer will tell everyone he knows.
2nd point: This is a technology problem, and is best addressed with a technology solution. Making a list of phone numbers not to call seems akin to making a list of IP's not to hack, or email addresses not to spam. Just as I'm sure a hacker would not pay attention to a state run Do Not Hack list, I believe people on the do not call list will continue to get calls, especially considering the massive loopholes in the provision. The only real solution here is to have an enterprising company provide a technology solution (like a firewall and HIDS for your IP at home).
p.s. I would not trust any of the phone companies to do this because they play both sides and pit us against each other.
I am now embarrased by my recent endorcements to buy a Mac. I have convinced family members and friends to buy a mac touting the free software (i applications), and free services (.mac), and the community atmosphear.
Thanks to the recent changes all I can tell them is "It's a nice interface to a Unix OS". That's not compelling enough to spend 2-3x $ on a personal computer.
I have purchased a new TI Notebook, and an iMac. My next home computer purchase will be an Xbox.:).
The problem in my mind when I see these "voluntary" systems in place is where entities request information when they have no reasonable claim to it.
When I signed up for my cable modem for example they insisted that they "needed" my social security number. I told them "no" repeatedly until they said "You either give it to us, or you don't get cable modem access". Since I knew that they had no real need for my SSN I gave them a fake one and got signed up anyway.
Like yourself I believe certain situations call for authentication, but who decides when it is required? And what else are they going to require next?
Are there any plans in the works to create game play networks outside of the MS funded network? Would it even be possible to get your Xbox to work on these alternate networks without modding them?
It would seem to me that the best solution for this problem is for the modded crowd to design their own networks for gameplay. It's been a long time since I've been into online game play (half-life CTF), but even our small servers were listed on websites to attract other players.
We live in a technology world. There is nothing we can't do. Instead of getting mad at MS for enforcing their rules, lets create our own.
I had this happen to me once. As I was being downsized my employeer said something to the effect of "And if we have any problems with Xyz, etc, can we call you?"
I said "Absolutely. My consulting fee is $250/hour. I would be happy to help".
They actually did end up calling me once, and I did happily help them. TANSTAAFL.
The Cliff's Notes version reads as follows: "... the most critical aspect of a security measure is not how well it works but how well it fails."
"... security measures must avoid being subject to single points of failure.... once hackers bypass the firewall, the whole system is often open for exploitation.... Finally, and most important, decisions need to be made by people at close range -- and the responsibility needs to be given explicitly to people, not computers"
"...security schemes should be designed to maximize ductility, whereas they often maximize strength."
"... Secrecy, in other words, is a prime cause of brittleness -- and therefore something likely to make a system prone to catastrophic collapse. Conversely, openness provides ductility."
"... brittleness is an inherent property of airline security."
"... Smart cards would not have stopped the terrorists who attacked the World Trade Center and the Pentagon.... their intentions, not their identities, were the issue."
"[Good Security]'s most important components are almost always human."
"A typical corporate network suffers a serious security breach four to six times a year.... A typical corporate network is hit by such doorknob-rattling several times an hour."
"... murderous adversaries are exactly why we should ensure that new security measures actually make American life safer"
"One key to the success of digital revamping will be a little-mentioned, even prosaic feature: Training the users not to circumvent secure systems."
"...technology can't save you... You always build the system around people"
Slashdot Mirror
The flip-side to your argument is that many of the exploits are found by "bad guys" before they are rediscovered by "good guys".
By definition, the "bad guys" don't typically believe in disclosure as it takes away another one of their 0day toys.
By disclosing weaknesses immediately you allow information owners to take precautions to protect their infrastructure, even if that means making the resource unavailable until a patch is provided by the vendor.
It is naive to believe that only "good guys" find problems. As soon as someone is considerate enough to share the problem, I believe it is in our best interest to be notified of it as soon as possible.
Your layer 7 firewalls, IDS/IPS, etc may work well against automated attacks but will fail against directed malice. If you think otherwise, contact me (PM) and we'll arrange a test of your network.
It's always funny to me to hear the "It's too hard" argument when it comes to Mandatory Access Controls. Quit being a pussy. You either care about security or you don't. You can't have it both ways. You can't say that "our security policy dictates x, y, z" and not provide systems that can actually enforce it.
They also get a bad rap because they don't work :).
v ideo/2000_Black_Hat_Vegas_VK3-Brian_Snow-We_Need_A ssurance-video.rm
http://www.radium.ncsc.mil/tpep/library/rainbow/52 00.28-STD.pdf
http://hissa.ncsl.nist.gov/rbac/paper/rbac1.html
It's a pitty they don't teach this stuff in CS:
http://www.dyadsecurity.com/papers/rbac.html
http://www.nsa.gov/selinux/papers/inevit-abs.cfm http://www.acm.org/classics/sep95/ rtsp://media-1.datamerica.com/blackhat/bh-usa-00/
Say it with me...
t tp://www.nsa.gov/selinux/papers/inevitabilityt p://hissa.ncsl.nist.gov/rbac/paper/rbac1.htmlt p://www.radium.ncsc.mil/tpep/library/rainbow/52 00.28-STD.pdf
DAC is DAC is DAC.
http://www.dyadsecurity.com/papers/rbac.html
h
ht
ht
If you're down, call us - (800) 644-DYAD.
If you just want to talk tech, you can reach me at (949) 394-2033.
1) Go out of business
Obviously not ideal.
2) Pay the extortion fee
Short term solution... long term disaster.
3) Buy lots of bandwidth and beefier equipment that can handle a large number of packets per second and a large number of concurrent connections. This is where you will also want to invest in a DDoS mitigation box like the toplayer etc devices.
This is a costly and time consuming way to go, and you will still have limits of what you can handle. A 100mb/s attack will kill a 10mb/s pipe every time, even with a $1,000,000 attack mitigator in front =).
4) Partner with a DDoS protection service like Prolexic. My company, Dyad Security - http://www.dyadsecurity.com/s_cleanpipe.html is a US reseller for the Prolexic DDoS protection service.
We have the infrastructure in place to eat the attack and keep you online. If you're offline, we can bring you back up very quickly (anywhere from 1-24 hours to get back online).
That may seem like a reasonable request, but you should know that exploits, especially automated exploits couldn't care less about what version of a service you're claiming to run. They don't even care that it's the right platform.
:).
The attacking system simply establishes a handshake, introduces the stimulus and waits for the response. If they get the desired response (shell, etc), great. If not, oh well, 1 down, 2^32-1 to go
Now for the flip side:
As an admin, if you knew you were not playing silly cat and mouse games with your banners, you'd be able to quickly determine which systems are still out of date.
And now for something completely different:
If you really want a secure user space application environment, you should build on a secure foundation. *BSD, UN*X (Solaris, AIX, HP-UX, etc), Linux, Windows, MacOSX, etc all employ a variation of Discretionary Access Control. DAC systems do not provide you the ability to actually enforce a security policy. Hardening an application on a DAC based foundation is akin to building a fortress on a foundation of sand.
If you require the ability to enforce your security policies, you need to start out with a sane and audited hardware base, and add on to it an OS equipped with mechanisms that provide for granular Mandatory Role Based Access Controls. You may consider the SE Linux project a good place to start.
Taken from Reflections on Trusting Trust - Quoting Ken Thompson:
"Moral
The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect."
Basically, the higher of a language you use, the less secure you can possibly be because of all of the implications of trusting trust. If you can't audit it, you can't trust it. End of discussion.
The security testing world actually has a pretty good methodology behind it now.
Check out the Open Source Security Testing Methodology Manual (OSSTMM) from the Institute for Security and Open Methodologies (ISECOM)
Here is my general view of the "secure programming" world. It goes out to all developers.
Know your tools. Choose them wisely -
Low level languages are not the problem; they are the most widely understood. Security is a process not a language. When your code inherits features and functionality that you did not intend, bad things can happen. Sure, we may not have buffer overflows, but if your RPC function allows me to execute any code that I want without overflowing buffers, who cares? Also, with these super portable "sand box" languages, I get to find one hole and exploit it everywhere. If you think Java is the answer, please tell me what language you think Java was written in? Also, please read "Reflections on Trusting Trust" by Ken Thompson.
Seeing the big picture -
Peer review is part of the security process; your attackers are becoming very skilled at finding exploitable software bugs using automated tools to help them. Everyone in the development process needs to know the type of application they are developing and the sensitivity levels of the information they are protecting.
Rule of Simplicity -
Design for simplicity; add complexity only where you must. Default to Deny, compartmentalization of code is good for more than just limiting security bugs.
Sweat the small stuff -
Just because certain attack vectors are obscure does not negate their effectiveness; writing good clean code is safer and more sane than allowing a program to "protect" bad coding practices at execution time. We have seen many examples of how this other type of protection fails.
Don't use your customers as your Q/A staff -
The Microsoft Software Release cycle is destroying security from the users and programmers perspective; it causes users to not want to upgrade, and it causes programmers to not want to fix security problems.
Don't build a $100,000 fence for a $1,000 horse -
All data is not created equal, don't treat it as such. Let the protection be commensurate with the asset.
Audit trails -
Trust with accountability. Every significant access, whether denied or permitted must maintain an audit trail.
I gravitated towards ISECOM's OPST/OPSA classes because they fill a role I felt was missing in the security class space. Many non-vendor specific security classes have a very narrow tools based focus. While I agree that knowing how to use your tools in a test is important, I feel knowing why and when to use them is far more important. Knowing the politics involved in testing, going over internationally accepted testing practices, and reviewing regional and national legal regulations are just as much part of the job. These things are not merely important, but are required to be successful in your role as a security tester. In addition to the intensely technical aspects of the testing process, this is what the OPST represents; the "professional" side of security testing. Also, the ISECOM classes teach from ISECOM's Open Source Security Testing Methodology Manual (OSSTMM) which provides a much needed methodical framework to bring a scientific method style to the chaotic world of security testing.
The CEH class represents the other kind of class. One that is "flashy", "fun", "exciting", but not overly useful to the serious professional. While I have a lot of respect for Clément (one of the instructors for Intense School), I have very little respect for any organization that markets "hacker" classes. This includes the so-called ethical hacking, applied hacking, exposed hacking, grandmother hacking, squirrel hacking, super-duper 3y3 4m 31337 hacking, or any other fancy way of saying "Learn how to think and act like the bad guys".
While choosing where to spend your time and money, consider the community you are aligning with. If you look at ISACA, SANS, ISC2, ISECOM, etc.. they all have a true dedication to security and the betterment of the global information security community. Contrast the value of being affiliated (via education/certification) with any of those organizations over a piece of paper and a cd of toys.
Be sure to whitelist certain "key" addresses. This is the same problem you'll run into with "active" IDS/IPS.
.1 and .3, thus killing all traffic from .2 to the net. etc, etc, etc.
To paraphrase a smart person (can't remember who), when you let the bad guys write your firewall rulesets for you, bad things could happen.
When you actively block things based on preceived bad traffic, you are in essence allowing the bad person to write some rules for you.
Imagine if your attacker knew your default route and sent some spoofed packets to
Best of luck.
But you can't have it both ways.
I argue for the right of the "sovereign nations" in California to not pay taxes on their gambling enterprises. This is mostly because of the agreements we've made with the tribes in the past.
However, based on the doublestandard and greed I am seeing by those who run the casino's I'm changing my tune. You can't argue for receiving money from taxes and not pay taxes. If you want the freedom that comes with being a sovereign nation, you get the responsibility too.
I believe if it is content you are legally entitled to posses you are not breaking the law by downloading it.
That doesn't change the laws that prohibit the person sharing the file from distributing it.
Throughout history different types of educational systems have been common.
The rich tend to have a mentor/classics home school education where they learn how to think.
The middle class has had a professional education system (apprenticeships) where they learn when to think.
For many years the poor had very little education. It has been proven that educating even the poor can and does raise the overall standard of living, so many nations will adopt some sort of public schooling for the poor. This education system is geared to teach students *what* to think.
It's the students from the last system that will be working in the lowest of jobs, requiring the most control.
The best way I know to measure something is to test it, and the best methodology I know of to test network security is the Open Source Security Testing Methodology Manual (OSSTMM).
You can download the latest version from http://www.osstmm.org. The latest is 2.0, although the 2.5 version has been slated to come out VERY soon, so check back in the next week or so for the update.
The OSSTMM is the most widely used peer-reviewed "Open Source" security testing methodology in existance. It is contributed to by security testing professionals all over the globe. It is definately worth checking out.
Although the OSSTMM does an excellent job at defining the "What" to do in a security test, ISECOM also has created two courses to teach the "How" and the "Why" in more detail. You can find out more about the OPST (the in the trenches tester/technical course) which teaches how to get the information for an OSSTMM based security test, and the OPSA (manager/analyst) which teaches how to analyze the information and manage the testing team at ISECOM's main site: http://www.isecom.org.
*disclaimer*: I work for a company that is partners with ISECOM.
* Disclaimer * - I work for a Security Testing Company.
1st step in security is to perform a risk assessment. The goal of Risk Assessment is to determine if the security controls for a system are fully commensurate with its risks. Without having an understanding of your risk you are unable to determine the proper security policies, procedures, guidelines, and standards to put in place to ensure adequate security controls are implemented. We want to avoid putting a $1000 fence around a $100 horse, but at the same time avoid undue risk.
Once that is completed, you need to create a security policy. This policy is what your company is officially trying to accomplish with it's security initiatives. Until you know what your goals are, any money or time is not going to be well spent.
Once you believe you have your goals from the policy implemented, you may wish to have a Posture Assessment. Posture Assessment is the act of measuring the gap between your information security posture and your information security policy. This is a thorough review of your existing security policies where each stated goal is converted into a test module. Each test is run until a sufficient amount of data is collected to measure the existing posture (The security Posture is what the company is actualy doing).
Assuming the Policy and the Posture match, you may additionaly with to verify that all the bases are covered and request a verification Penetration Test on a specific set of systems with a stated goal for the test, or an out and out Ethical Hack attempt (same idea as a Penetration test, but not as limited in scope). This will uncover holes in not covered by the Security Policy.
You should also consider periodic testing. Some of this should be done internally, some is best to outsource.
A security test is only valid if it is:
* Quantifiable
-- Can be numerically measured
* Consistent and repeatable
-- Two testers would receive the same test results at the same time
* Valid beyond the "now" time frame
-- Lasts and remains valid longer than the wet ink on the report
* Based on the merit of the tester and analyst not on brands
-- It is based on smarts and not expensive tools
* Thorough
-- A complete test where nothing is left untested from the scope
* Compliant to individual and local laws and the human right to privacy
-- Puts the protection of personal privacy before corporate data
As a person involved with sales, I value my time. People who do not want to be harrassed should not be called. The only thing it accomplishes is to make them have bad feelings towards your company. That being said, I believe that the industry (telemarketers) should be in favor of these types of lists and make strides to enhance customer loyalty. They should have an industry maintained list, as the penalty for harrassment is loss of sale and bad feelings. A happy customer might tell 2-3 of his closest friends. An upset customer will tell everyone he knows.
2nd point:
This is a technology problem, and is best addressed with a technology solution. Making a list of phone numbers not to call seems akin to making a list of IP's not to hack, or email addresses not to spam. Just as I'm sure a hacker would not pay attention to a state run Do Not Hack list, I believe people on the do not call list will continue to get calls, especially considering the massive loopholes in the provision. The only real solution here is to have an enterprising company provide a technology solution (like a firewall and HIDS for your IP at home).
p.s.
I would not trust any of the phone companies to do this because they play both sides and pit us against each other.
I am now embarrased by my recent endorcements to buy a Mac. I have convinced family members and friends to buy a mac touting the free software (i applications), and free services (.mac), and the community atmosphear.
:).
Thanks to the recent changes all I can tell them is "It's a nice interface to a Unix OS". That's not compelling enough to spend 2-3x $ on a personal computer.
I have purchased a new TI Notebook, and an iMac. My next home computer purchase will be an Xbox.
I've been thinking about doing just that for some time now. Problem is, so far I've not found a place that was over all better.
:).
Out of curiousity, where have you selected to live now?
p.s.
This is not a flame, I really am curious
#!/bin/csh
#
# One Step
# GNU-Darwin auto-installer for OSX
# 0.0.1a6
# proclus (GPL)
# Thu Aug 29 09:47:46 PDT 2002
Wait until it's closer to 1.0 before complaining.
The problem in my mind when I see these "voluntary" systems in place is where entities request information when they have no reasonable claim to it.
When I signed up for my cable modem for example they insisted that they "needed" my social security number. I told them "no" repeatedly until they said "You either give it to us, or you don't get cable modem access". Since I knew that they had no real need for my SSN I gave them a fake one and got signed up anyway.
Like yourself I believe certain situations call for authentication, but who decides when it is required? And what else are they going to require next?
Are there any plans in the works to create game play networks outside of the MS funded network? Would it even be possible to get your Xbox to work on these alternate networks without modding them?
It would seem to me that the best solution for this problem is for the modded crowd to design their own networks for gameplay. It's been a long time since I've been into online game play (half-life CTF), but even our small servers were listed on websites to attract other players.
We live in a technology world. There is nothing we can't do. Instead of getting mad at MS for enforcing their rules, lets create our own.
I had this happen to me once. As I was being downsized my employeer said something to the effect of "And if we have any problems with Xyz, etc, can we call you?"
I said "Absolutely. My consulting fee is $250/hour. I would be happy to help".
They actually did end up calling me once, and I did happily help them. TANSTAAFL.
Robert
The Cliff's Notes version reads as follows:
.... A typical corporate network is hit by such
... You always build the system around
"... the most critical aspect of a security measure is not how well it
works but how well it fails."
"... security measures must avoid being subject to single points of
failure.... once hackers bypass the firewall, the whole system is often
open for exploitation.... Finally, and most important, decisions need to
be made by people at close range -- and the responsibility needs to be
given explicitly to people, not computers"
"...security schemes should be designed to maximize ductility, whereas
they often maximize strength."
"... Secrecy, in other words, is a prime cause of brittleness -- and
therefore something likely to make a system prone to catastrophic
collapse. Conversely, openness provides ductility."
"... brittleness is an inherent property of airline security."
"... Smart cards would not have stopped the terrorists who attacked the
World Trade Center and the Pentagon.... their intentions, not their
identities, were the issue."
"[Good Security]'s most important components are almost always human."
"A typical corporate network suffers a serious security breach four to six
times a year
doorknob-rattling several times an hour."
"... murderous adversaries are exactly why we should ensure that new
security measures actually make American life safer"
"One key to the success of digital revamping will be a little-mentioned,
even prosaic feature: Training the users not to circumvent secure
systems."
"...technology can't save you
people"