A vulnerability assessment is an important element in understanding a company’s threat profile. When performing a vulnerability assessment, it should include more than just running a scan, printing a pretty report and sending it out to a client, management, or administrator. It must also be about confidence and accuracy. What makes you confident in the report you send to a client, your management, or administrator? What makes YOUR report more accurate than others? Validation. What is validation? Validation is testing a vulnerability that has been found. Depending on how far you dive into validation, it can contain many elements of a penetration test. What makes validation most important is identification of false positives. Every vulnerability scanner, no matter how many bells and whistles it has, will produce false positives. There is no scanner on the market that can find every vulnerability and not produce false positives.
Read more!
Friday, August 20, 2010
Tuesday, August 17, 2010
The DDoS Threat: The New Punctuated Equilibrium
On August 7, 2010, DNS Made Easy underwent an outage that was caused by a Distributed Denial of Service (DDoS) attack. While the outage for many companies was sporadic, it lasted for multiple hours in regions of the west coast of the United States. Over the course of the past eight years, DNS Made Easy has prided themselves on their 100% uptime. A blow like this can affect a company’s public image, hinder their marketing, shift their business strategy, and impact their bottom line. So, how did this happen? Is it preventable? And, what can you do about it? In this situation, it is easy to blame DNS Made Easy and say that they didn’t have the proper security controls in place to withstand this type of attack, but in reality things are not that simple.
Read more!
Read more!
Information Security Policies and Procedures, Part 3
This is part of an ongoing series on documentation development. Please be sure to read the previous posts in this series.
Part 1 , Part 2 , Part 4 , Part 5 , Part 6
While we are still at the beginning stages of preparing to develop policies, procedures, and related documentation, it is important to mention a few things not to do.
Do Not Repurpose/Borrow the Work of Others
Search engines are great, and place a vast body of human knowledge at your fingertips. This vast knowledge often includes the intellectual property of others. Finding policies on the internet and using control H to place your organization’s name in place of another is not only wrong, it is also ineffective. Even if you have policies examples available that are not covered by copyright, they still will not cover everything you need in most situations. Every organization is unique, and as such has unique policy and procedure requirements. By all means, scour the web, libraries, desk drawers, etc. for policies to get ideas for format, structure, and things to include. But be sure to create your own intellectual property.
Do Not Ignore the Input of Others
No doubt you are an expert in your chosen field. However, developing policies and procedures is best done with the input of others. Be sure to speak with the Human Resources department about Acceptable Use, System Access, and other cross functional policies. Talk to your receptionist or security guards to get another perspective for Physical Security and Visitor policies. And certainly, wherever possible seek direction from whoever will be tasked with approving the policies. I am sure you get the idea; I could go on ad infinitum listing people who you should involve in policy creation.
Do Not Overcomplicate Things
I have never been accused of using too few words. However, when writing policies, be sure to be clear and concise. Don’t use two sentences where one will do. (Save that for blogs.) Of course it follows that you need to be thorough enough to make certain that your audience understands what the policy is saying. Finding the perfect balance is never easy, but if you are cognizant of this issue, you will likely be okay. Just remember, there is a reason Hemingway didn’t write policies.
Do not Forget the Audience
There are policies and procedures that will be distributed companywide, and others that will stay within IT. While IT procedures may be filled with the intricacies of required network logging, general policies will need to be geared toward a more general audience.
Do Not Get Stuck in the Weeds
Don’t let small issues derail your documentation project. Keep writing. There will always be debates about minutiae; note these for later resolution and move on. These decisions will need to be made prior to final approval and distribution, but they shouldn’t stop your progress.
Do not Confuse Policies with Procedures
As we discussed in a previous installment, policies and procedures have significant differences. One practical reason to separate policies and procedures involves the approval process. While policies generally go through an approval workflow that includes executive management, many times procedures (especially highly technical IT procedures) can be updated less formally. If procedural steps are embedded in policies, you could find yourself seeking executive approval each time you change software vendors or process minutiae. We will discuss this more in later installments.
In our next installment of this series, we will cover basic document formatting and structure. (Don’t worry; it is not as dry as it sounds.)
Read more!
Part 1 , Part 2 , Part 4 , Part 5 , Part 6
While we are still at the beginning stages of preparing to develop policies, procedures, and related documentation, it is important to mention a few things not to do.
Do Not Repurpose/Borrow the Work of Others
Search engines are great, and place a vast body of human knowledge at your fingertips. This vast knowledge often includes the intellectual property of others. Finding policies on the internet and using control H to place your organization’s name in place of another is not only wrong, it is also ineffective. Even if you have policies examples available that are not covered by copyright, they still will not cover everything you need in most situations. Every organization is unique, and as such has unique policy and procedure requirements. By all means, scour the web, libraries, desk drawers, etc. for policies to get ideas for format, structure, and things to include. But be sure to create your own intellectual property.
Do Not Ignore the Input of Others
No doubt you are an expert in your chosen field. However, developing policies and procedures is best done with the input of others. Be sure to speak with the Human Resources department about Acceptable Use, System Access, and other cross functional policies. Talk to your receptionist or security guards to get another perspective for Physical Security and Visitor policies. And certainly, wherever possible seek direction from whoever will be tasked with approving the policies. I am sure you get the idea; I could go on ad infinitum listing people who you should involve in policy creation.
Do Not Overcomplicate Things
I have never been accused of using too few words. However, when writing policies, be sure to be clear and concise. Don’t use two sentences where one will do. (Save that for blogs.) Of course it follows that you need to be thorough enough to make certain that your audience understands what the policy is saying. Finding the perfect balance is never easy, but if you are cognizant of this issue, you will likely be okay. Just remember, there is a reason Hemingway didn’t write policies.
Do not Forget the Audience
There are policies and procedures that will be distributed companywide, and others that will stay within IT. While IT procedures may be filled with the intricacies of required network logging, general policies will need to be geared toward a more general audience.
Do Not Get Stuck in the Weeds
Don’t let small issues derail your documentation project. Keep writing. There will always be debates about minutiae; note these for later resolution and move on. These decisions will need to be made prior to final approval and distribution, but they shouldn’t stop your progress.
Do not Confuse Policies with Procedures
As we discussed in a previous installment, policies and procedures have significant differences. One practical reason to separate policies and procedures involves the approval process. While policies generally go through an approval workflow that includes executive management, many times procedures (especially highly technical IT procedures) can be updated less formally. If procedural steps are embedded in policies, you could find yourself seeking executive approval each time you change software vendors or process minutiae. We will discuss this more in later installments.
In our next installment of this series, we will cover basic document formatting and structure. (Don’t worry; it is not as dry as it sounds.)
Read more!
Thursday, August 12, 2010
XFS 101: Cross-Frame Scripting Explained
Cross-Frame Scripting (XFS) is an attack related to cross-site scripting (XSS) and is commonly misunderstood from both offensive and defensive standpoints. This blog’s aim is to clear up confusion regarding what it means, what vulnerability it is exploiting, and a survey of suggested fixes available.
XFS exploits a bug in specific browsers that allows a parent frame to be exposed to events in an embedded iFrame inside of it. The exposure is limited to events only, and does not give full JavaScript cross domain access. Several examples exist illustrating the sniffing of keystrokes from an embedded iFrame (usually a login page) to an attacker controlled resource such as a remote Web server using an XML HttpRequest (XHR) surreptitiously in the background. This effectively provides a means to silently steal credentials being typed into the embedded iFrame by the victim. This attack in no way allows full JavaScript execution despite being similar to XSS.
Read more!
XFS exploits a bug in specific browsers that allows a parent frame to be exposed to events in an embedded iFrame inside of it. The exposure is limited to events only, and does not give full JavaScript cross domain access. Several examples exist illustrating the sniffing of keystrokes from an embedded iFrame (usually a login page) to an attacker controlled resource such as a remote Web server using an XML HttpRequest (XHR) surreptitiously in the background. This effectively provides a means to silently steal credentials being typed into the embedded iFrame by the victim. This attack in no way allows full JavaScript execution despite being similar to XSS.
Read more!
Tuesday, August 10, 2010
Information Security Policies and Procedures, Part 2
This is part of an ongoing series on documentation development. Please be sure to read the previous posts in this series.
Part 1 , Part 3 , Part 4 , Part 5 , Part 6
Knowing which policies are necessary in your environment can be a challenge. Most organizations will have at least some formalized policies. Many of these are in response to legal requirements (HR policies) or specific incidents. After someone leaves their laptop in the car trunk for 6 hours on a 100 degree day, a policy on the care of equipment is generally issued.
With policies and procedures, it is essential to be proactive rather than reactive. In the case of the melted laptop, it would be far better to have instituted a policy regarding equipment care prior to the incident. That may be a simplistic scenario where the company is out a thousand dollars for a laptop, but it illustrates a point. This proactive posture becomes far more important when applied to more complex situations. What if, instead of being out a thousand dollars for a laptop, you were instead out tens or hundreds of thousands of dollars in fines after a cardholder data breach? Or worse, in the case of HIPAA, you find yourself with tremendous legal bills or in jail. (I am aware that is an extreme case, but it is illustrative of my point.)
As far as information security, every organization will have a unique set of foundational policies. Although there will be many that are common to all organizations, the unique qualities of each organization call for custom policies. How then, do we determine what basic policies we need? I have found that one of the simplest ways to determine which policies are essential is to look at all applicable regulations, laws, standards, and contracts and perform a gap assessment. For example, if you are subject to the PCI DSS, a good way to start is to take a copy of the standard and identify every place where a policy or procedure is required. PCI requires a policy on visitors to your facilities. As such, part of being compliant with PCI will be developing a visitor policy per the specific requirements of the standard. An important caveat: having a policy in place does not equal compliance.
An auditor will not only look for the policy, they will also look for evidence that the policy is enforced. So, for our example of a visitor policy, the auditor will want to see associated visitor logs and will check to see if they are issued a visitor badge per the policy. Careful readers will note that I slipped in mention of another document, the visitor log. In many cases, documentation leads to more documents. In this case, you will also likely need to develop training and awareness programs. Procedures for the receptionist to follow will help ensure that they are correctly logging visitors. An awareness program allows employees to understand that the policy exists as well as the rationale behind the policy.
As you move through the standard or regulation identifying where documentation is necessary, keep a list of what policies address which sections. At the conclusion of the gap assessment of the applicable regulations and compliances, you will have a firm understanding of what policies and related documentation are necessary. Keep in mind that in addition, it is important to review contractual obligations. These contractual obligations generally exist between you and your clients, vendors, and other service providers. Involving your legal department is always recommended.
In the next part of this series we will cover some of the pitfalls to avoid.
Read more!
Part 1 , Part 3 , Part 4 , Part 5 , Part 6
Knowing which policies are necessary in your environment can be a challenge. Most organizations will have at least some formalized policies. Many of these are in response to legal requirements (HR policies) or specific incidents. After someone leaves their laptop in the car trunk for 6 hours on a 100 degree day, a policy on the care of equipment is generally issued.
With policies and procedures, it is essential to be proactive rather than reactive. In the case of the melted laptop, it would be far better to have instituted a policy regarding equipment care prior to the incident. That may be a simplistic scenario where the company is out a thousand dollars for a laptop, but it illustrates a point. This proactive posture becomes far more important when applied to more complex situations. What if, instead of being out a thousand dollars for a laptop, you were instead out tens or hundreds of thousands of dollars in fines after a cardholder data breach? Or worse, in the case of HIPAA, you find yourself with tremendous legal bills or in jail. (I am aware that is an extreme case, but it is illustrative of my point.)
As far as information security, every organization will have a unique set of foundational policies. Although there will be many that are common to all organizations, the unique qualities of each organization call for custom policies. How then, do we determine what basic policies we need? I have found that one of the simplest ways to determine which policies are essential is to look at all applicable regulations, laws, standards, and contracts and perform a gap assessment. For example, if you are subject to the PCI DSS, a good way to start is to take a copy of the standard and identify every place where a policy or procedure is required. PCI requires a policy on visitors to your facilities. As such, part of being compliant with PCI will be developing a visitor policy per the specific requirements of the standard. An important caveat: having a policy in place does not equal compliance.
An auditor will not only look for the policy, they will also look for evidence that the policy is enforced. So, for our example of a visitor policy, the auditor will want to see associated visitor logs and will check to see if they are issued a visitor badge per the policy. Careful readers will note that I slipped in mention of another document, the visitor log. In many cases, documentation leads to more documents. In this case, you will also likely need to develop training and awareness programs. Procedures for the receptionist to follow will help ensure that they are correctly logging visitors. An awareness program allows employees to understand that the policy exists as well as the rationale behind the policy.
As you move through the standard or regulation identifying where documentation is necessary, keep a list of what policies address which sections. At the conclusion of the gap assessment of the applicable regulations and compliances, you will have a firm understanding of what policies and related documentation are necessary. Keep in mind that in addition, it is important to review contractual obligations. These contractual obligations generally exist between you and your clients, vendors, and other service providers. Involving your legal department is always recommended.
In the next part of this series we will cover some of the pitfalls to avoid.
Read more!
Monday, August 9, 2010
A Week of Security in Vegas: Black Hat, Bsides, & Defcon
Towards the end of summer each year the information security world descends on Las Vegas for a week of training, discussion and the disclosure of a year’s worth of quiet research. I’ve been attending off and on for years, and was joined this year by several of my new SecureState co-workers from Profiling and Risk Management.
The week started off with the biggest, and most expensive of the 3 events: Black Hat Las Vegas. This is the original and largest of the Black Hat events held around the world each year, and it has often been a forum for disclosing some of the most cutting-edge and impactful research within Information Security. The biggest talk this year hands down was Barnaby Jack’s presentation on compromising Automatic Teller Machines. Barnaby had attempted to give a similar presentation in 2009, but his employer pulled the presentation after pressure was applied from some unnamed ATM manufacturers. After changing employers and adding several new ATM machines to his collection, Barnaby was back this year to give a live demo of local and remote compromise of two different ATMs.
Read more!
The week started off with the biggest, and most expensive of the 3 events: Black Hat Las Vegas. This is the original and largest of the Black Hat events held around the world each year, and it has often been a forum for disclosing some of the most cutting-edge and impactful research within Information Security. The biggest talk this year hands down was Barnaby Jack’s presentation on compromising Automatic Teller Machines. Barnaby had attempted to give a similar presentation in 2009, but his employer pulled the presentation after pressure was applied from some unnamed ATM manufacturers. After changing employers and adding several new ATM machines to his collection, Barnaby was back this year to give a live demo of local and remote compromise of two different ATMs.
Read more!
Thursday, August 5, 2010
Moving To The Cloud Primer
Everywhere you look, there are articles, research and analysis on the topic of cloud computing. It has even been termed, “the most significant shift in information technology in our lifetimes.” The positive aspects are exciting and offer many benefits, including access to applications, storage for legacy data, and powerful computer processing -all with the click of a mouse. For companies that want to avoid purchasing entire systems of IT software and hiring the talent to operate and secure them, this option may seem very tempting. One common concern that should be analyzed and researched thoroughly is the issue of security in cloud computing. Any future cloud user should gather as much information as possible about their potential cloud provider before sending any data to the cloud.
For instance, it would be wise to ask any potential cloud provider how they protect against malicious insider activity. One question that should be submitted is if a provider conducts background checks on all relevant employees. Nothing like sending PII to a cloud provider that lacks knowledge on who is working for them. Additionally, questions on employee monitoring, access determination, and audit trails would also be appropriate. Some providers may not want to divulge such technical information. If the cloud provider does not want to provide such information, ask if they have any monitoring and access control policies and procedures in place. If they don’t, tell them to create some and make it part of the service contract. One way or another, you’re going to want to be protected.
For those cloud providers that are providing Software as a Service where all development is handled on the provider side, questions on the system development lifecycle would apply. For example, customers will want to know if the cloud provider has incorporated security into their SDLC. Also, see if the future cloud provider takes into consideration the OWASP Cloud Top 10 during the development cycle. Lastly, ask the provider if they follow Cloud Security Alliance guidance for critical focus areas. If the cloud provider answers in the negative or has no idea what you’re talking about, it may be best to look for another provider.
As touched on above, some cloud computing companies practice the “security by obscurity” method, which will usually exacerbate the fears of the company seeking cloud services. It is a fine line to walk, because the cloud computing company does not want to divulge too much information, which could compromise their security from malicious attackers. However they should want to be as transparent as possible to their potential clients. Try to find a cloud computing company that offers voluntary monthly or quarterly security reports. This report will show the client what issues the company is addressing, without broadcasting information that compromises their security posture.
What other types of data are being stored by the cloud provider? Do they allow data that may be malicious code, spamming data or information related to criminal activity? In multi-tenant environments “Innocent” data can be located on the same shared infrastructure as “Malicious” data. This should be investigated thoroughly before choosing a cloud provider. Specific questions about strict registration and validation processes and ongoing monitoring of network traffic before, after and during storage and use should be the norm. Besides, if the provider accepts unscrupulous clients and the provider’s defense in depth as well as compartmentalization is weak, what’s to stop a malicious tenant from accessing your data?
Before utilizing any cloud services, customers should conduct an internal assessment for any regulatory compliance complications. Many regulations demand that certain classes of data not be intermingled with other, less sensitive data, such as on multi-tenant shared servers or databases. Additionally, data retention laws vary among countries, with data limits on what can be stored, and for how long being heavily regulated in some countries. Some countries even make it unlawful for some data to be transferred to foreign cloud providers. When the data is no longer needed, most retention laws will require the cloud provider to wipe the data clean before being sent to the pool. Can your cloud provider provide this service? Also, many regulations or standards require some sort of logging as well as log reviewing to be conducted in order to be compliant (PCI Anybody). However, most cloud provider logs are internal and access to these logs by customers or auditors may be difficult. As a result, this type of scenario would make complying with such regulation or standard nearly impossible. Consequently, a compliance impact assessment should be carried out before moving to the cloud.
In conclusion, there are many concerns that companies must consider before utilizing the Cloud. The concerns highlighted in this blog post are only the tip of the iceberg. Therefore, a proper assessment of any cloud provider is warranted for any organization planning a move to the cloud.
Read more!
For instance, it would be wise to ask any potential cloud provider how they protect against malicious insider activity. One question that should be submitted is if a provider conducts background checks on all relevant employees. Nothing like sending PII to a cloud provider that lacks knowledge on who is working for them. Additionally, questions on employee monitoring, access determination, and audit trails would also be appropriate. Some providers may not want to divulge such technical information. If the cloud provider does not want to provide such information, ask if they have any monitoring and access control policies and procedures in place. If they don’t, tell them to create some and make it part of the service contract. One way or another, you’re going to want to be protected.
For those cloud providers that are providing Software as a Service where all development is handled on the provider side, questions on the system development lifecycle would apply. For example, customers will want to know if the cloud provider has incorporated security into their SDLC. Also, see if the future cloud provider takes into consideration the OWASP Cloud Top 10 during the development cycle. Lastly, ask the provider if they follow Cloud Security Alliance guidance for critical focus areas. If the cloud provider answers in the negative or has no idea what you’re talking about, it may be best to look for another provider.
As touched on above, some cloud computing companies practice the “security by obscurity” method, which will usually exacerbate the fears of the company seeking cloud services. It is a fine line to walk, because the cloud computing company does not want to divulge too much information, which could compromise their security from malicious attackers. However they should want to be as transparent as possible to their potential clients. Try to find a cloud computing company that offers voluntary monthly or quarterly security reports. This report will show the client what issues the company is addressing, without broadcasting information that compromises their security posture.
What other types of data are being stored by the cloud provider? Do they allow data that may be malicious code, spamming data or information related to criminal activity? In multi-tenant environments “Innocent” data can be located on the same shared infrastructure as “Malicious” data. This should be investigated thoroughly before choosing a cloud provider. Specific questions about strict registration and validation processes and ongoing monitoring of network traffic before, after and during storage and use should be the norm. Besides, if the provider accepts unscrupulous clients and the provider’s defense in depth as well as compartmentalization is weak, what’s to stop a malicious tenant from accessing your data?
Before utilizing any cloud services, customers should conduct an internal assessment for any regulatory compliance complications. Many regulations demand that certain classes of data not be intermingled with other, less sensitive data, such as on multi-tenant shared servers or databases. Additionally, data retention laws vary among countries, with data limits on what can be stored, and for how long being heavily regulated in some countries. Some countries even make it unlawful for some data to be transferred to foreign cloud providers. When the data is no longer needed, most retention laws will require the cloud provider to wipe the data clean before being sent to the pool. Can your cloud provider provide this service? Also, many regulations or standards require some sort of logging as well as log reviewing to be conducted in order to be compliant (PCI Anybody). However, most cloud provider logs are internal and access to these logs by customers or auditors may be difficult. As a result, this type of scenario would make complying with such regulation or standard nearly impossible. Consequently, a compliance impact assessment should be carried out before moving to the cloud.
In conclusion, there are many concerns that companies must consider before utilizing the Cloud. The concerns highlighted in this blog post are only the tip of the iceberg. Therefore, a proper assessment of any cloud provider is warranted for any organization planning a move to the cloud.
Read more!
Subscribe to:
Posts (Atom)
Posts
