As a security auditor, I can't tell you how many times I've been asked this when talking about compliance. If I only had a nickle for every time someone asked me that question... well... I'd probably want to throw it at the person who just asked me it. This is such a bad question on so many levels and it still frustrates me each time. That being said, I suppose I should answer it here so that maybe, just maybe, they won't ask next time.
My first response is, 'everyone else' is not doing a good job, not enough, and likely the wrong things. For example, take PCI compliance. Even after all this time, only 77% of Level 1 Merchants are compliant. Now if everyone is being as tough as they should be, those merchants are getting fined $25,000 per month and a possibly higher transaction rate. Compliance basically exists because when 'everyone else' was doing what 'everyone else' did, 'everyone' sucked! So somebody had to step in and raise the bar for them. It's like the flock needing a shepherd.
Now imagine that all of sudden you get breached because your 'average' organization is doing things just like 'everyone else,' which isn't enough... do you really want to stand at the podium and state that you didn't do enough because others aren't? Is that really a good, defensible position? On average, the average isn't good. So do you really want to measure yourself against them?
I think it's also ironic when you realize that just prior to this question is the statement made by the same person that "Well, we're unique here at Company X". Of course you are! If not, I can't imagine you'd have differentiators and be unique. There is no reason why that can't be security. It is probably a pretty good reason to not be like 'everyone else'. I'm hoping the next time someone asks me this, they want to know so they can use it for out marketing 'everyone else'.
Read more!
Tuesday, September 9, 2008
Thursday, August 28, 2008
Dear NERC, CIP needs a protein shake...
We've been posting a lot of information about compliance regulation lately, so I'll just add another scoop to this steamy pile...
The North American Electric Reliability Corporation (NERC) is a self-regulatory (non-governmental) organization subject to oversight by the U.S. Federal Energy Regulatory Commission (FERC). As of June 18, 2007, FERC granted NERC the legal authority to enforce reliability standards with all U.S. users, owners, and operators of the bulk power system, and made compliance with those standards mandatory and enforceable.
The preceding paragraph came pretty much verbatim from the NERC website. Now that we have a little insight on NERC, let's stop FERC'in around and talk about Critical Infrastructure Protection (CIP).
CIP was designed to protect the United States critical infrastructure and features a heavy emphasis on safeguarding critical cyber assets (CCA) that help run the systems that generate electricity and control the transmission of electricity. The CIP standard is broken down into 8 individual requirements (CIP-002 through CIP-009) for various areas of protection or security. Audits for NERC CIP begin July 1, 2009. You might recall a certain blackout of 2003 that affected a large number of northeastern states? Hmmmmmm?? This prompted the NERC CIP standard, much like Enron prompted SOX.
As assessors or auditors, our team works with many different standards and regulations, and we've done a lot of NERC CIP related work with our energy clients over the past year. We've heard multiple complaints from clients about the CIP standard being vague or hazy, and I tend to agree. The clarity on protection levels that are expected are muddy.
As far as standards go, CIP needs a protein shake. We're talking about a standard that's designed to protect some of the country's most critical systems. It NEEDS to be stronger.
And what's with the non-standard terms in the standard? "Cyber"? "Electronic Security Perimeter"?
Really? Who uses those?
Why don't they just throw in "microcomputer" or "World Wide Web"?
While other standards and compliance reg's require penetration testing, CIP only requires vulnerability scanning. Scanning for modems is referenced quite a bit in CIP, but there's practically nothing related to wireless. Sure, there are tons of modems out there, especially in those sectors, but NERC needs to let go of 1996. Check out some of the latest breaches across the country - I can't remember the last time I read a story about a compromise being traced back to a dusty modem. (Calm down, calm down...I know it still happens, just not as frequently.) And what about the exception for nuke plants? Why can't you apply NERC CIP to nuke plants as well? Businesses have to deal with multiple compliance efforts ALL THE TIME. Why wouldn't you use CIP as a "second set of eyes" for those sites?
And one more before I move on to the positives of NERC CIP. The standard isn't a shadow of what other regulations like PCI are requiring. You mean to tell me that the standards for the companies that allow me to turn on my lights are less than those of the companies that want to swipe my plastic?
NEWS FLASH: If the power is off, no one cares about PCI, HIPAA, or SOX.
Why?
Because the 'puters, calculators, and credit card processors don't work so well without power.
On a positive note - NERC CIP outlines a great schedule for compliance, with different progression paths. It's very detailed and could be something that other regulations take note of. The standard also breaks down what can be used as measures to demonstrate compliance, as well as specific levels of non-compliance which act as a nice grading system.
All in all, the standard has some positives but plenty of negatives. In my opinion, it has a long way to go before I stop stocking up on candles.
Read more!
The North American Electric Reliability Corporation (NERC) is a self-regulatory (non-governmental) organization subject to oversight by the U.S. Federal Energy Regulatory Commission (FERC). As of June 18, 2007, FERC granted NERC the legal authority to enforce reliability standards with all U.S. users, owners, and operators of the bulk power system, and made compliance with those standards mandatory and enforceable.
The preceding paragraph came pretty much verbatim from the NERC website. Now that we have a little insight on NERC, let's stop FERC'in around and talk about Critical Infrastructure Protection (CIP).
CIP was designed to protect the United States critical infrastructure and features a heavy emphasis on safeguarding critical cyber assets (CCA) that help run the systems that generate electricity and control the transmission of electricity. The CIP standard is broken down into 8 individual requirements (CIP-002 through CIP-009) for various areas of protection or security. Audits for NERC CIP begin July 1, 2009. You might recall a certain blackout of 2003 that affected a large number of northeastern states? Hmmmmmm?? This prompted the NERC CIP standard, much like Enron prompted SOX.
As assessors or auditors, our team works with many different standards and regulations, and we've done a lot of NERC CIP related work with our energy clients over the past year. We've heard multiple complaints from clients about the CIP standard being vague or hazy, and I tend to agree. The clarity on protection levels that are expected are muddy.
As far as standards go, CIP needs a protein shake. We're talking about a standard that's designed to protect some of the country's most critical systems. It NEEDS to be stronger.
And what's with the non-standard terms in the standard? "Cyber"? "Electronic Security Perimeter"?
Really? Who uses those?
Why don't they just throw in "microcomputer" or "World Wide Web"?
While other standards and compliance reg's require penetration testing, CIP only requires vulnerability scanning. Scanning for modems is referenced quite a bit in CIP, but there's practically nothing related to wireless. Sure, there are tons of modems out there, especially in those sectors, but NERC needs to let go of 1996. Check out some of the latest breaches across the country - I can't remember the last time I read a story about a compromise being traced back to a dusty modem. (Calm down, calm down...I know it still happens, just not as frequently.) And what about the exception for nuke plants? Why can't you apply NERC CIP to nuke plants as well? Businesses have to deal with multiple compliance efforts ALL THE TIME. Why wouldn't you use CIP as a "second set of eyes" for those sites?
And one more before I move on to the positives of NERC CIP. The standard isn't a shadow of what other regulations like PCI are requiring. You mean to tell me that the standards for the companies that allow me to turn on my lights are less than those of the companies that want to swipe my plastic?
NEWS FLASH: If the power is off, no one cares about PCI, HIPAA, or SOX.
Why?
Because the 'puters, calculators, and credit card processors don't work so well without power.
On a positive note - NERC CIP outlines a great schedule for compliance, with different progression paths. It's very detailed and could be something that other regulations take note of. The standard also breaks down what can be used as measures to demonstrate compliance, as well as specific levels of non-compliance which act as a nice grading system.
All in all, the standard has some positives but plenty of negatives. In my opinion, it has a long way to go before I stop stocking up on candles.
Read more!
Friday, August 22, 2008
Regulations Attack
I recently published top eight trends for 08’ (http://www.securestate.com/Pages/Top-8-In-08.aspx), however one topic in particular has caught my attention, why are “Regulations” being attacked?
At DefCon 16 I had the opportunity to meet some really interesting people who had different perspectives on security. However, for the first time in DefCon history (to my knowledge) “Compliance” standards opened the conference Friday morning. I was so excited to hear what the “hackers” thought about PCI, GLBA, HIPAA etc. To my disappointment, the presenter ranted about how compliance doesn’t equal security… DUH! But what they do is provide some value and the value is called “doing something!” Hell, most companies (97%) won’t do anything at all until they are forced!
Even with these standards, millions of records are still being compromised. Let’s rant about companies losing our data, not about how bad the regulations are. Let’s face it, if companies were doing what they should, there wouldn’t be a need for regulations! I am writing an article for Information Week on Malicious Compliance in Distress, which addresses companies doing the bare minimum to become compliant, instead of appropriately securing the data. If you use these regulations as a Minimum Security Baseline, you can always add additional layers of security to these regulations. For example… PCI just calls out not using WEP, but mentions the ability to use WPA and WPA2… however as security professionals we would consider WPA and WPA2 just as bad. So by PCI standards you can be compliant, however not any more secure than if you used WEP. Use the regulations to get a new stronger encryption protocol for your wireless environment.
Let’s not attack the regulations, but the reason why they were developed! View regulations as the minimum standard. If you took a comprehensive approach to security you would comply to all the regulations anyways (ISO 27001 & 27002). So instead of bitching out regulations… use them to get funding and do the right thing :-)
Read more!
At DefCon 16 I had the opportunity to meet some really interesting people who had different perspectives on security. However, for the first time in DefCon history (to my knowledge) “Compliance” standards opened the conference Friday morning. I was so excited to hear what the “hackers” thought about PCI, GLBA, HIPAA etc. To my disappointment, the presenter ranted about how compliance doesn’t equal security… DUH! But what they do is provide some value and the value is called “doing something!” Hell, most companies (97%) won’t do anything at all until they are forced!
Even with these standards, millions of records are still being compromised. Let’s rant about companies losing our data, not about how bad the regulations are. Let’s face it, if companies were doing what they should, there wouldn’t be a need for regulations! I am writing an article for Information Week on Malicious Compliance in Distress, which addresses companies doing the bare minimum to become compliant, instead of appropriately securing the data. If you use these regulations as a Minimum Security Baseline, you can always add additional layers of security to these regulations. For example… PCI just calls out not using WEP, but mentions the ability to use WPA and WPA2… however as security professionals we would consider WPA and WPA2 just as bad. So by PCI standards you can be compliant, however not any more secure than if you used WEP. Use the regulations to get a new stronger encryption protocol for your wireless environment.
Let’s not attack the regulations, but the reason why they were developed! View regulations as the minimum standard. If you took a comprehensive approach to security you would comply to all the regulations anyways (ISO 27001 & 27002). So instead of bitching out regulations… use them to get funding and do the right thing :-)
Read more!
Monday, August 18, 2008
Undercover at Defcon
After having attended yet another Defcon, I find myself a little frustrated. While I am a geek at heart, I am not a Linux chugging, code puking, trench coat wearing, hair dying, multi-pierced hardcore guy like many. But then again, I am not alone. Though many like to think it’s still ‘underground’, it really hasn’t been for quite a while. Security isn’t just an IT thing any more and its gaining ground in the business world. Hence there are many security professionals and vendor in attendance. So this year, I specifically set out to find that business side of security. As to being undercover, no I would not be a winner in the ‘spot the fed’ contest. I am just a security auditor that was hoping to hang out with my coworkers, learn a few things, and do a little networking.
Now I have to preface my story with some important information. Every night typically ended with the sun rising, my buzz fading, and my alarm looming just a few hours away. So perhaps I was a little tired, hung over and grumpy going into each morning – though I’m generally grumpy according to most anyway :) Still, I made my way to the conference, grabbed my new-fangled badge, and hit my first presentation. The abstract was very promising as the presenter alluded to the fact that compliance != (does not equal) security. Certainly he had a strong starting point. But, he tripped coming out of the blocks. The rest of the presentation turned into an angry IT guy condemning every standard, every certification, and pointing out how stupid and useless auditors are.
Now I’ll be the first to say there are many auditors working in areas they should not be. I think we’ve all had to deal with the Big X auditor/kid straight out of college that can’t seem to discuss anything outside the verbiage in his checklist. But it’s just as annoying to have someone unqualified lecturing about compliance. It does not make any sense to compare strength of compliance based on the length of the standard. Nor should you compare an IT standard against a security standard. And you shouldn’t even bring up standards that you don’t even know what the letters stand for. Again, I’ll be glad to raise my hands and tell you all the flaws with all the standards like my recent post on PCI. But I have at least had to actually work with those frameworks. I suppose it’s just a different view when you are subject to them.
During the rest of my Defcon experience, it was also peppered with more compliance bigotry, even from the likes of professors. But that’s not to say there weren’t some great ones too. One was on a new tool to find and perhaps exploit ModBusTCP devices on SCADA systems. That certainly piqued my interest with all the NERC CIP compliance work we are doing. There were a couple different presentations that covered different problems with RFID including devices that go beyond just cloning prox cards but also doing site codes brute force attacks on common card codes. I think the best presentation was ours – only because I got see out head geek get pummeled with lemons for his sins against humanity. Don’t ask :) After all, what happens in Vegas...
Read more!
Now I have to preface my story with some important information. Every night typically ended with the sun rising, my buzz fading, and my alarm looming just a few hours away. So perhaps I was a little tired, hung over and grumpy going into each morning – though I’m generally grumpy according to most anyway :) Still, I made my way to the conference, grabbed my new-fangled badge, and hit my first presentation. The abstract was very promising as the presenter alluded to the fact that compliance != (does not equal) security. Certainly he had a strong starting point. But, he tripped coming out of the blocks. The rest of the presentation turned into an angry IT guy condemning every standard, every certification, and pointing out how stupid and useless auditors are.
Now I’ll be the first to say there are many auditors working in areas they should not be. I think we’ve all had to deal with the Big X auditor/kid straight out of college that can’t seem to discuss anything outside the verbiage in his checklist. But it’s just as annoying to have someone unqualified lecturing about compliance. It does not make any sense to compare strength of compliance based on the length of the standard. Nor should you compare an IT standard against a security standard. And you shouldn’t even bring up standards that you don’t even know what the letters stand for. Again, I’ll be glad to raise my hands and tell you all the flaws with all the standards like my recent post on PCI. But I have at least had to actually work with those frameworks. I suppose it’s just a different view when you are subject to them.
During the rest of my Defcon experience, it was also peppered with more compliance bigotry, even from the likes of professors. But that’s not to say there weren’t some great ones too. One was on a new tool to find and perhaps exploit ModBusTCP devices on SCADA systems. That certainly piqued my interest with all the NERC CIP compliance work we are doing. There were a couple different presentations that covered different problems with RFID including devices that go beyond just cloning prox cards but also doing site codes brute force attacks on common card codes. I think the best presentation was ours – only because I got see out head geek get pummeled with lemons for his sins against humanity. Don’t ask :) After all, what happens in Vegas...
Read more!
Friday, August 15, 2008
Elements of a Good Assessor
As assessors, there are some crucial elements that you need to incorporate into your style while you are in front of a client; whether it be the way you present yourself, the way you ask questions, or just the way you collect information. All of these issues can affect the quality of the assessment and how smoothly it performs.
The following are just some quick tips to consider as you are doing your assessment, making it as thorough and as painless as possible.
Be friendly but don’t be their friend.
This is one of the most helpful items that I have taken to heart. As an assessor, you want them to feel comfortable and divulge all information that you want from them. If they feel pressured or backed into a corner, you’ll get only short and sweet answers that, depending on the situation, will not get you the information you’re looking for. Try connecting to them at the beginning of the meeting. Ask them how long they have worked at the company and see where the conversation goes from there. Magically a repore starts to develop and the auditor wall will start to crumble.
Others things to bring up: weather, news (NOT politics), and opinions on technology. Also showing a sincere interest in what they do at their job also helps. People love talking about themselves!
‘May I see an example?’ should be your motto.
People can be a great way of gathering information, but the devil is in the details. Always be in a inquisitive nature and develop an uncomfortable feeling about information when you don’t have documentation to support it.
This is especially important when the client states that they are accomplishing the control or having certain processes around it. Not always, but usually you can trust employees to be honest if they are talking about deficiencies within their processes. The concern grows if they are saying that everything is fine and all of there controls are in place and working correctly. This is a clear sign that you need to gather documentation and further information on the status of findings.
If you get into an audit situation this becomes especially important, as everything typically needs some type of paper trail as to confirm the control is functioning and in place.
If they push back, attack!
Honestly, this should be a red flag while assessing personnel. If you think you’re getting resistance, it could be one of two issues. They could feel uncomfortable about the situation OR they could be concealing something. If they are concealing something, you need to dig even more, ask for examples, and confirm the content with others within the auditing scope.
Don't be afraid to as the same question more than once. For example, asking the configuration manager about pushing code into production might reveal that they have a uniform configuration management tool - and that's the only method of getting code there. Though when talking to the software engineer about this topic, they might reveal that they often put code into production in order to test it first.
I assume you know about assumptions!
Your whole job as an assessor is to gather facts and to interpret to the results - no assumptions included. This is still important even if you are familiar with the environment. Personally, I have to watch out for this if I'm involved with follow-up assessment for organizations. It is very easy to fall into presumptive questions if you knew the answer last year. The problem comes that you do not know if their environment has changed within the last year. Also injection your own presumptions into the assessment could bite you in the end.
Try and look at each assessment engagement as a separate issue. Even if you are familiar with the organization, ask the questions to their personnel again and let them answer the questions.
Let them do the talking.
Bottom line – you don’t get any answers when you’re doing the talking. Setup questions that allow them to describe the situation or process. For example, a closed questions sets up the yes/no answer – like “Do you do this within your process?”. Alternatively you need to ask open questions whereas they are forced to describe the situation from their own point of view - “Can you walk me through how you would typically perform this process?"
If it gets into a complicate section, utilize confirmation questions at the end - example "My understanding of the current situation is like this. Am I correct?". You want to make sure that the findings you are putting down are as accurate as you can record.
Don’t report the findings until the end.
I can’t tell you how many times I get after an interview the question of “So how did I do?”. The best strategy is to just say that you need to look at all of the information holistically before bringing out the findings. Let’s take a couple of scenarios.
Scenario 1 - “Mr. Client, you’re great and I see nothing wrong out of this interview.”
Client is happy that they’ve done their job in your eyes. The person then goes to gloat to his boss on the fine work they’ve done. This is until the next day when you discover a gaping hole in their process that wasn’t discovered until you looked at either the documentation or talked with another person involved. Now you have to retract the statement you did, the client has to retract their statement, and there is a bitter feeling in the air.
Scenario 2 - “ Mr. Client – you have some major deficiencies because of the findings I saw in this particular area.”
Now the client could fight back and try and justify their position, why they didn’t do certain controls, or why they think security is a joke! Additionally if you have to go back to the person to gather more information, they are going to be a closed book for information.
Bottom line – save the findings until the end where you can present all of them in an orderly fashion.
Practice good meeting facilitation.
Lastly, you should always practice good meeting facilitation while you’re performing interviews. Some examples are introductions, setting the tone of the meeting, good time management, keeping proper focus on the objective, and closing the meeting. This is important to ensure that all of the necessary information is gathered within the appropriate time frame.
I’ll elaborate on a future blog as to the details of some of the elements to a meeting and what I like to do to open and close a meeting.
--
Keep in mind that these are all recommendations and general guidelines to an assessment. When the actual work is being performed, you are the general on the ground and no successful battle plan has been followed to the letter and the battle won. Adjust to the changes within the organization and environment and everything will complete successfully!
Read more!
The following are just some quick tips to consider as you are doing your assessment, making it as thorough and as painless as possible.
Be friendly but don’t be their friend.
This is one of the most helpful items that I have taken to heart. As an assessor, you want them to feel comfortable and divulge all information that you want from them. If they feel pressured or backed into a corner, you’ll get only short and sweet answers that, depending on the situation, will not get you the information you’re looking for. Try connecting to them at the beginning of the meeting. Ask them how long they have worked at the company and see where the conversation goes from there. Magically a repore starts to develop and the auditor wall will start to crumble.
Others things to bring up: weather, news (NOT politics), and opinions on technology. Also showing a sincere interest in what they do at their job also helps. People love talking about themselves!
‘May I see an example?’ should be your motto.
People can be a great way of gathering information, but the devil is in the details. Always be in a inquisitive nature and develop an uncomfortable feeling about information when you don’t have documentation to support it.
This is especially important when the client states that they are accomplishing the control or having certain processes around it. Not always, but usually you can trust employees to be honest if they are talking about deficiencies within their processes. The concern grows if they are saying that everything is fine and all of there controls are in place and working correctly. This is a clear sign that you need to gather documentation and further information on the status of findings.
If you get into an audit situation this becomes especially important, as everything typically needs some type of paper trail as to confirm the control is functioning and in place.
If they push back, attack!
Honestly, this should be a red flag while assessing personnel. If you think you’re getting resistance, it could be one of two issues. They could feel uncomfortable about the situation OR they could be concealing something. If they are concealing something, you need to dig even more, ask for examples, and confirm the content with others within the auditing scope.
Don't be afraid to as the same question more than once. For example, asking the configuration manager about pushing code into production might reveal that they have a uniform configuration management tool - and that's the only method of getting code there. Though when talking to the software engineer about this topic, they might reveal that they often put code into production in order to test it first.
I assume you know about assumptions!
Your whole job as an assessor is to gather facts and to interpret to the results - no assumptions included. This is still important even if you are familiar with the environment. Personally, I have to watch out for this if I'm involved with follow-up assessment for organizations. It is very easy to fall into presumptive questions if you knew the answer last year. The problem comes that you do not know if their environment has changed within the last year. Also injection your own presumptions into the assessment could bite you in the end.
Try and look at each assessment engagement as a separate issue. Even if you are familiar with the organization, ask the questions to their personnel again and let them answer the questions.
Let them do the talking.
Bottom line – you don’t get any answers when you’re doing the talking. Setup questions that allow them to describe the situation or process. For example, a closed questions sets up the yes/no answer – like “Do you do this within your process?”. Alternatively you need to ask open questions whereas they are forced to describe the situation from their own point of view - “Can you walk me through how you would typically perform this process?"
If it gets into a complicate section, utilize confirmation questions at the end - example "My understanding of the current situation is like this. Am I correct?". You want to make sure that the findings you are putting down are as accurate as you can record.
Don’t report the findings until the end.
I can’t tell you how many times I get after an interview the question of “So how did I do?”. The best strategy is to just say that you need to look at all of the information holistically before bringing out the findings. Let’s take a couple of scenarios.
Scenario 1 - “Mr. Client, you’re great and I see nothing wrong out of this interview.”
Client is happy that they’ve done their job in your eyes. The person then goes to gloat to his boss on the fine work they’ve done. This is until the next day when you discover a gaping hole in their process that wasn’t discovered until you looked at either the documentation or talked with another person involved. Now you have to retract the statement you did, the client has to retract their statement, and there is a bitter feeling in the air.
Scenario 2 - “ Mr. Client – you have some major deficiencies because of the findings I saw in this particular area.”
Now the client could fight back and try and justify their position, why they didn’t do certain controls, or why they think security is a joke! Additionally if you have to go back to the person to gather more information, they are going to be a closed book for information.
Bottom line – save the findings until the end where you can present all of them in an orderly fashion.
Practice good meeting facilitation.
Lastly, you should always practice good meeting facilitation while you’re performing interviews. Some examples are introductions, setting the tone of the meeting, good time management, keeping proper focus on the objective, and closing the meeting. This is important to ensure that all of the necessary information is gathered within the appropriate time frame.
I’ll elaborate on a future blog as to the details of some of the elements to a meeting and what I like to do to open and close a meeting.
--
Keep in mind that these are all recommendations and general guidelines to an assessment. When the actual work is being performed, you are the general on the ground and no successful battle plan has been followed to the letter and the battle won. Adjust to the changes within the organization and environment and everything will complete successfully!
Read more!
Wednesday, August 13, 2008
Defcon – "And this is very illegal! So the following material is for educational use only."
I’m not a hacker, but I live with them. I took the pilgrimage to Defcon, attended by many of the world's best-known security experts, and felt much like the kid reporter in the movie “Almost Famous.” Among other (sometimes bewildering) presentations, Defcon showcases demonstrations of the latest discovered weaknesses in computer systems.
The big brew-haha this year was “The Anatomy of a Subway Hack” of the Boston T that got blocked. A federal judge ordered three college students to cancel a Sunday presentation where they planned to show security flaws in the automated fare system used by Boston's subway. I wouldn’t have thought this was any different than the presentation the SecureState team gave where we released various new tools, including SA Exploiter. However I guess when one of your slides proclaims: "And this is very illegal! So the following material is for educational use only," it draws attention to you.
At SecureState, we believe everyone (most especially those organizations trying to protect themselves) should have access to all information available. The belief is if you hide the findings (zero-day exploits) it’s not going to stop the bad guys who have the time and incentive to find the vulnerabilities themselves. It just keeps the good guys on the forefront.
Many organizations without the resources to properly research the latest and greatest vulnerabilities use penetrations tests to get the results of the research with the ability to see how it affects them specifically. Penetration tests are the foundation of security since you don’t know what you don’t know. Thus, keeping security problems secret, or the “Security through obscurity” idea, doesn’t protect the businesses relying on those systems.
In short, our goal at SecureState is to make security better. We don’t look to disclose things that can hurt people. That’s especially true if there is nothing they can do about it. Releasing exploits and tools gives researchers and ethical hackers the opportunity to learn from the experience we have, gives organizations a better idea about the attacks that are possible, and the steps they need to take to prevent them. The bottom line is that while there are risks, the public good is better served by having knowledge freely available. Besides, H4CK3RS are people too.
Read more!
The big brew-haha this year was “The Anatomy of a Subway Hack” of the Boston T that got blocked. A federal judge ordered three college students to cancel a Sunday presentation where they planned to show security flaws in the automated fare system used by Boston's subway. I wouldn’t have thought this was any different than the presentation the SecureState team gave where we released various new tools, including SA Exploiter. However I guess when one of your slides proclaims: "And this is very illegal! So the following material is for educational use only," it draws attention to you.
At SecureState, we believe everyone (most especially those organizations trying to protect themselves) should have access to all information available. The belief is if you hide the findings (zero-day exploits) it’s not going to stop the bad guys who have the time and incentive to find the vulnerabilities themselves. It just keeps the good guys on the forefront.
Many organizations without the resources to properly research the latest and greatest vulnerabilities use penetrations tests to get the results of the research with the ability to see how it affects them specifically. Penetration tests are the foundation of security since you don’t know what you don’t know. Thus, keeping security problems secret, or the “Security through obscurity” idea, doesn’t protect the businesses relying on those systems.
In short, our goal at SecureState is to make security better. We don’t look to disclose things that can hurt people. That’s especially true if there is nothing they can do about it. Releasing exploits and tools gives researchers and ethical hackers the opportunity to learn from the experience we have, gives organizations a better idea about the attacks that are possible, and the steps they need to take to prevent them. The bottom line is that while there are risks, the public good is better served by having knowledge freely available. Besides, H4CK3RS are people too.
Read more!
Thursday, August 7, 2008
Data Classification - Time to catch up
After 12 years of protecting U.S. Government’s most sensitive and classified resources, data, personnel, and facilities, I have learned a great number of things. The television show 60 Minutes can do a year's worth of episodes purely on the mismanagement of funding alone at one unnamed facility that I worked at. Argue what you may about the U.S. Government, its spending habits, its leaders, its policies, its “big brother” mentality, or whatever else irks you, but know this: The U.S. Government is the king of data classification. It is better than everyone, including every business you have ever worked for: Fortune 500 companies, financial institutions, manufacturing businesses, utility companies, healthcare facilities, and retail industries.
How does one begin to protect information? Classify it. In order to determine necessary controls and measures that are required to protect information, we must first understand the value of that information. Once the value is understood, we can then determine the impact it will have if it becomes lost or compromised. Will its loss bankrupt our business? Will its compromise put us on the front page of the newspaper? This impact, in turn, determines how it must be protected.
There are dozens of different classifications used in the government. They include Top Secret, Secret, Confidential, Sensitive But Unclassified, , Export Controlled, Limited Distribution, and Restricted Data just to name a few. To take it one step further, the U.S. Government applies handling instructions (like NOFORN or ORCON) and a “Need-To-Know” philosophy to all of its information, meaning that even if I have a Top Secret clearance, I only have access to information that is required for me to fulfill the duties and responsibilities of my position.
Each of these classifications is assigned based on the value of the information and each different classification has it own individual set of instructions for proper handling and safeguarding the information. The higher the value of the data, the more stringent the controls are to protect it.
If your organization doesn’t classify its data, you are most likely not protecting it at a level commensurate to its value, and therefore make it vulnerable to loss or compromise. In data classification, the government reigns. Everyone else, including you, can’t keep up.
Read more!
How does one begin to protect information? Classify it. In order to determine necessary controls and measures that are required to protect information, we must first understand the value of that information. Once the value is understood, we can then determine the impact it will have if it becomes lost or compromised. Will its loss bankrupt our business? Will its compromise put us on the front page of the newspaper? This impact, in turn, determines how it must be protected.
There are dozens of different classifications used in the government. They include Top Secret, Secret, Confidential, Sensitive But Unclassified, , Export Controlled, Limited Distribution, and Restricted Data just to name a few. To take it one step further, the U.S. Government applies handling instructions (like NOFORN or ORCON) and a “Need-To-Know” philosophy to all of its information, meaning that even if I have a Top Secret clearance, I only have access to information that is required for me to fulfill the duties and responsibilities of my position.
Each of these classifications is assigned based on the value of the information and each different classification has it own individual set of instructions for proper handling and safeguarding the information. The higher the value of the data, the more stringent the controls are to protect it.
If your organization doesn’t classify its data, you are most likely not protecting it at a level commensurate to its value, and therefore make it vulnerable to loss or compromise. In data classification, the government reigns. Everyone else, including you, can’t keep up.
Read more!
Subscribe to:
Posts (Atom)
Posts
