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 3 , Part 4 , Part 5
Knowing Your Audience
A natural human behavior is assuming that the majority of the world’s people are similar to us; similar in thoughts, assumptions, knowledge, opinions etc. Psychologists may see this as the consensus effect, a form of cognitive bias. If you love ballet, you likely assume that far more people also like it than actually do.
What does this have to do with documentation?
When creating the various types of documentation, it is important to know your audience and understand their comprehension of the topic. In many cases, things that are second nature to you will be completely foreign to the majority of the world. If you are reading this, chances are you know what https means, but there are many people who only know that it sometimes goes in front of a web address, if they even know that.
For general distribution documentation, including companywide policies, you generally want to stay around a fifth grade reading level. (If you want to know why, fire up your favorite search engine and enter “reading comprehension levels of college graduates.”) Of course, nothing is ever that easy, because on the other side of the coin you want to make sure that you aren’t talking down to certain audiences. If you are creating a highly technical specification to be used solely by engineers, you can leave out the explanations of basic math.
Also keep in mind that the same word or abbreviation can have multiple meaning to multiple audiences. DC? To tech folks, that is the datacenter. If you work in a warehouse, it is the distribution center. Electricians will take it as Direct Current. To generation Y, DC is a shoe company, and to their parents it is a comic book company. DC is also shorthand for the District of Columbia. The list could go on and on, and that is just one example. So be certain to explain any abbreviations or acronyms the first time you use them within each document.
We must also consider not just denotation, but also connotation, especially in view of the vast range of connotations a general audience may have. The right amount of detail is essential. This becomes even more important when users may not be native speakers of English.
Writing to the correct audience is one of the most important elements of creating effective documentation. If the documentation is too technical for the audience, they will not understand it and likely not read it. Conversely, if the documentation is too simple for the audience, they may skim over important points.
In the next installment, we will discuss some of the intricacies of language. Should you read it, or must you read it?
Read more!
Showing posts with label Information Security. Show all posts
Showing posts with label Information Security. Show all posts
Tuesday, September 7, 2010
Monday, August 30, 2010
Information Security Policies and Procedures, Part 5
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 3 , Part 4 , Part 6
In this installment, we will discuss fonts, and then move on to additional structural elements necessary in documentation, starting with policies.
Does the font matter? Certainly. As I mentioned in a previous post, if your organization has a corporate style guide, the font and document layout is likely already determined. However, if you are blazing a trail through the documentation, you will need to choose a font. If you are planning on distributing hard copies of your documents, a Serif font is easiest on the eyes. For documentation meant to be viewed on a monitor, a Sans Serif font is best. Of course, rare is the document that is viewed in one format only. Lucky for us, Microsoft has come up with a font designed to be easy to read both on screen and when printed; this font is Calibri.
Side Note: Serif? Sans Serif? Seriously? For those of you who are not familiar with typography, serif fonts are those with serifs, the little embellishments on the letters. Think Times New Roman. Sans Serif, as students of French will note, are fonts without serifs. Perhaps the best known example, at least to a generation raised with computers, is Arial. If you have any confusion, type a few letters in Arial and Times New Roman and compare them side by side. (In case you don’t think typography is cool, read Steve Jobs’ 1995 commencement address to Stanford “I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can’t capture, and I found it fascinating.”) So when you refer to your documentation as a work of art, Mr. Jobs may concur.
Before we get too far down the road into typography (kerning anyone?), let’s move on to some additional structural elements necessary in documentation, starting with policies. In addition to the elements discussed in previous posts, policies need a few standard sections.
These sections include purpose, scope, policy details, and enforcement. You may also wish to include a section with definitions or relevant standards/laws.
The purpose section should include information about why the policy is necessary. You may also wish to add some information about how the issue was dealt with historically. It is also a great place to reiterate some company values. An example is “To ensure compliance with (regulation) and create a more secure environment, this company has implemented this policy…“ Some policies will require a paragraph to get the point across, while others may only need a line or two.
The scope is generally fairly straightforward. To whom does the policy apply? Employees? Contractors? Visitors? To what facilities does this policy apply? To what systems? And so on and so forth.
The policy details section is one into which we will take a much deeper dive in a future post. For now, just know that this section enumerates the rules of the policy. It may also refer to related procedures.
The Enforcement section is where you outline the consequences for non compliance. Is it up to and including termination? A written warning? Be sure to involve HR and Legal in this part.
As we continue in this series, we will expound on each of these areas. Hopefully by now you are feeling more comfortable with documentation development. Please feel free to email me any questions or ask them in the comments section below.
In the next installment, we will discuss knowing your audience.
Read more!
Part 1 , Part 2 , Part 3 , Part 4 , Part 6
In this installment, we will discuss fonts, and then move on to additional structural elements necessary in documentation, starting with policies.
Does the font matter? Certainly. As I mentioned in a previous post, if your organization has a corporate style guide, the font and document layout is likely already determined. However, if you are blazing a trail through the documentation, you will need to choose a font. If you are planning on distributing hard copies of your documents, a Serif font is easiest on the eyes. For documentation meant to be viewed on a monitor, a Sans Serif font is best. Of course, rare is the document that is viewed in one format only. Lucky for us, Microsoft has come up with a font designed to be easy to read both on screen and when printed; this font is Calibri.
Side Note: Serif? Sans Serif? Seriously? For those of you who are not familiar with typography, serif fonts are those with serifs, the little embellishments on the letters. Think Times New Roman. Sans Serif, as students of French will note, are fonts without serifs. Perhaps the best known example, at least to a generation raised with computers, is Arial. If you have any confusion, type a few letters in Arial and Times New Roman and compare them side by side. (In case you don’t think typography is cool, read Steve Jobs’ 1995 commencement address to Stanford “I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can’t capture, and I found it fascinating.”) So when you refer to your documentation as a work of art, Mr. Jobs may concur.
Before we get too far down the road into typography (kerning anyone?), let’s move on to some additional structural elements necessary in documentation, starting with policies. In addition to the elements discussed in previous posts, policies need a few standard sections.
These sections include purpose, scope, policy details, and enforcement. You may also wish to include a section with definitions or relevant standards/laws.
The purpose section should include information about why the policy is necessary. You may also wish to add some information about how the issue was dealt with historically. It is also a great place to reiterate some company values. An example is “To ensure compliance with (regulation) and create a more secure environment, this company has implemented this policy…“ Some policies will require a paragraph to get the point across, while others may only need a line or two.
The scope is generally fairly straightforward. To whom does the policy apply? Employees? Contractors? Visitors? To what facilities does this policy apply? To what systems? And so on and so forth.
The policy details section is one into which we will take a much deeper dive in a future post. For now, just know that this section enumerates the rules of the policy. It may also refer to related procedures.
The Enforcement section is where you outline the consequences for non compliance. Is it up to and including termination? A written warning? Be sure to involve HR and Legal in this part.
As we continue in this series, we will expound on each of these areas. Hopefully by now you are feeling more comfortable with documentation development. Please feel free to email me any questions or ask them in the comments section below.
In the next installment, we will discuss knowing your audience.
Read more!
Tuesday, August 17, 2010
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!
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!
Tuesday, August 3, 2010
Information Security Policies and Procedures, Part 1
Note: This is part of an ongoing series on documentation development. Please be sure to read the previous posts in this series.
Part 2 , Part 3 , Part 4 , Part 5 , Part 6
Policy writing can be a daunting task, and one for which many are not overly enthused. However, Policies and Procedures are an integral part of any information security program. Not only do they provide direction and accountability, many specific policy elements are a requirement of specific laws, regulations, and/or standards. In this multipart series, I will work to help you become comfortable writing policies and their associated procedures.
Before we get started, there are a few things that are important to know.
Policy sets are different in each environment. With information security, the number of policies as well as the breadth of each policy will vary depending on the complexity of the environment as well as the sensitivity and criticality of the information. There are other factors that will affect information security policy development as well. For example, it is common that some of the elements of an Acceptable Use Policy will already be covered in basic HR policies and employee handbooks. It is essential that different departments work together to ensure that policies work in concert and do not contradict each other.
It is also essential to determine the audience for any given policy. For most users, the Acceptable Use Policy will determine the rules for their access. Network Security Policies, Access Control Policies, and System Access Logging and Maintenance Policies will have IT departments as their audience. It is also important to note that certain policies may be confidential according to an asset classification program. A Network Security Policy delineating requirements for protections such as connection restrictions or intrusion protection and detection may be valuable for an attacker. It is vital to consider business need to know when distributing policies.
The Differences Between Policies, Procedures, and Standards
It is important to understand the differences between a policy, procedure, and standard, and the functions of each. Policies delineate the laws for an organization. Procedures and standards describe how to implement policies. A simple analogy is that of a red light. The policy, or law, requires that drivers come to a complete stop at any and all red lights. The procedure, however, will describe how to depress the brake, operate the clutch, etc. The standard would describe what types of brakes and tires are appropriate. An exception process would describe the circumstances under which the policy may be violated--in this example, an emergency vehicle.
In the next part of this series, we will discuss how to determine which policies are necessary for your environment.
Part 2 , Part 3 , Part 4
Read more!
Part 2 , Part 3 , Part 4 , Part 5 , Part 6
Policy writing can be a daunting task, and one for which many are not overly enthused. However, Policies and Procedures are an integral part of any information security program. Not only do they provide direction and accountability, many specific policy elements are a requirement of specific laws, regulations, and/or standards. In this multipart series, I will work to help you become comfortable writing policies and their associated procedures.
Before we get started, there are a few things that are important to know.
Policy sets are different in each environment. With information security, the number of policies as well as the breadth of each policy will vary depending on the complexity of the environment as well as the sensitivity and criticality of the information. There are other factors that will affect information security policy development as well. For example, it is common that some of the elements of an Acceptable Use Policy will already be covered in basic HR policies and employee handbooks. It is essential that different departments work together to ensure that policies work in concert and do not contradict each other.
It is also essential to determine the audience for any given policy. For most users, the Acceptable Use Policy will determine the rules for their access. Network Security Policies, Access Control Policies, and System Access Logging and Maintenance Policies will have IT departments as their audience. It is also important to note that certain policies may be confidential according to an asset classification program. A Network Security Policy delineating requirements for protections such as connection restrictions or intrusion protection and detection may be valuable for an attacker. It is vital to consider business need to know when distributing policies.
The Differences Between Policies, Procedures, and Standards
It is important to understand the differences between a policy, procedure, and standard, and the functions of each. Policies delineate the laws for an organization. Procedures and standards describe how to implement policies. A simple analogy is that of a red light. The policy, or law, requires that drivers come to a complete stop at any and all red lights. The procedure, however, will describe how to depress the brake, operate the clutch, etc. The standard would describe what types of brakes and tires are appropriate. An exception process would describe the circumstances under which the policy may be violated--in this example, an emergency vehicle.
In the next part of this series, we will discuss how to determine which policies are necessary for your environment.
Part 2 , Part 3 , Part 4
Read more!
Friday, May 7, 2010
Two Thumbs Up for These Security Podcasts
It may be cliché but security is an ever-changing world. I am often asked how I keep up to date on the latest security trends and news in this rapidly changing world. The two primary tools I use to do this are security podcasts and Twitter. Being a consultant I spend a lot of time on the road and have long periods of free time while driving or flying to clients’ sites. While on the road, or during my daily commute, I fill those open hours by listening to podcasts. I am going to discuss the security podcasts I listen to, with a short description of each one. In a future post I’ll discuss how I use Twitter to keep in touch with the security community and stay on top of emerging trends.
ASIS Security Management Podcast is a monthly podcast containing highlights from the ASIS Security Management magazine. The magazine and podcast tend to be heavily focused on physical security, but there is some information security mixed in also. This is a great podcast if you want to learn more about physical security.
Crypto-Gram Security Podcast is simply Bruce Schneier’s monthly Crypto-Gram newsletter read aloud by Dan Henage. If you don’t have time to read the printed version of Crypto-Gram, this is a great way to keep up to date on a fascinating newsletter. If you haven’t read the Crypto-Gram newsletter you owe it to yourself to check out this podcast. I leave every podcast thinking about a security problem or issue in a new way.
CyberSpeak is a podcast focused on forensics. It is hosted by two formal federal agents who have spent their careers doing data forensics work. This show covers everything from basic to cutting edge forensic techniques. Whether you are a novice in forensics or an experienced forensics examiner, you will learn something from each episode.
Eurotrash Security Podcast comes to us from a band of security professionals and hackers based in Europe. This is one of the few podcasts that covers information security from a European point of view, so it is curious to see how security concerns over there line up and differ from the concerns in the States.
Exotic Liability Podcast is often offensive, usually informative, but always a fun time. This podcast is definitely not safe for work. So be careful where you listen to it. I recommend skipping this podcast if you are offended at obscene language and concepts. Topics usually focus on penetration testing and social engineering. The hosts also have some entertaining war stories about penetration testing.
OWASP Security Podcast focuses on all aspects of web application security. Many of the episodes are short interviews with experts in this field. This podcast is a wonderful way to learn about or keep on top of web application security topics.
Network Security Podcast is a weekly security news podcast covering new stories from the previous week. This show covers all aspects of security. The hosts comment on the news stories, often adding insight which makes the program well worth the listen.
PaulDotCom Security Weekly focuses on the technical side of security. Shows usually include a technical segment, new stories from the previous week, and interviews with special guests. If you want to learn more about the technical side of security this is a podcast you must check out. They also provide very detailed show notes which can be helpful when trying to implement an attack discussed on the show. An episode of PaulDotCom Security Weekly often is broken into two parts and the entire weekly show usually runs two to three hours. If I am running short on podcast time in a week, I also will use the show notes to determine what topics are of interest so I can fast forward to that portion of the podcast.
Risky Business is a news show which focuses on security from down under. The host of the show, Patrick Gray, does a very good job of explaining security concepts and concerns. Patrick also has a good handle on the importance of balancing security with business requirements, something many security folks forget. Because of these two factors, this is a great show for someone just getting into security.
SANS Audio Cast is a short weekly newscast produced by SANS. Episodes tend to be ten to fifteen minutes long so it is a great way to quickly catch up on the hot security news from the previous week. Even if I am running behind on podcasts, I try to listen to this one the week it is released while the information is still fresh.
SecuraBit Podcast is a security news podcast that focuses on technical security topics. I mainly listen to SecuraBit for the special guests they have, who tend to be big names in the security community.
Security Justice is hands down the best security podcast ever made. This monthly podcast covers a variety of security topics but tends to lean more toward physical security and the convergence of physical and logical security. This also is the only security podcast recorded live in a bar. Because this podcast is recorded in a bar, expect bar like language that may not be safe for work. Also in the interest of full disclosure, I should state the author of this post is also a co-host on this show so his views of the show are most likely biased.
Social Media Security Podcast focuses on the security concerns related to social media sites such as Facebook, Twitter, MySpace, and LinkedIn. The team that runs socialmediasecurity.com hosts the show. This podcast is a great way to learn about the threats in the emerging area of social media. The show also provides great case studies and stories that can be used for end user education and awareness training.
Social-Engineering.org Podcast is a monthly podcast focusing on social engineering. Produced by the team that run social-engineering.org, the podcast covers a number of topics related to social engineering. This podcast brings in some amazing guests. At first the guest’s or show topic’s relationship to social engineering might not be clear, but hang in there and the team always ties in how they relate. At its roots this podcast is about how to influence people, which is an important skill for any security professional to have. So even if you are not interested in social engineering, I still recommend you check out a few episodes of this podcast.
The Southern Fried Security Podcast looks at security from the CSO and management level, which is a welcome change from the often technical-heavy security podcasts. The podcast focuses on integrating security into a business and the importance of balancing the business needs with security. Most security professionals have a hard time achieving this balance, so do your self a favor and listen to at least a few episodes of this podcast.
If any of these podcasts sound interesting to you, I recommend you download a few episodes and give them a listen.
What security podcasts do you listen to? Any podcast you think I should start listening to? If so, tell me why in the comments.
Read more!
ASIS Security Management Podcast is a monthly podcast containing highlights from the ASIS Security Management magazine. The magazine and podcast tend to be heavily focused on physical security, but there is some information security mixed in also. This is a great podcast if you want to learn more about physical security.
Crypto-Gram Security Podcast is simply Bruce Schneier’s monthly Crypto-Gram newsletter read aloud by Dan Henage. If you don’t have time to read the printed version of Crypto-Gram, this is a great way to keep up to date on a fascinating newsletter. If you haven’t read the Crypto-Gram newsletter you owe it to yourself to check out this podcast. I leave every podcast thinking about a security problem or issue in a new way.
CyberSpeak is a podcast focused on forensics. It is hosted by two formal federal agents who have spent their careers doing data forensics work. This show covers everything from basic to cutting edge forensic techniques. Whether you are a novice in forensics or an experienced forensics examiner, you will learn something from each episode.
Eurotrash Security Podcast comes to us from a band of security professionals and hackers based in Europe. This is one of the few podcasts that covers information security from a European point of view, so it is curious to see how security concerns over there line up and differ from the concerns in the States.
Exotic Liability Podcast is often offensive, usually informative, but always a fun time. This podcast is definitely not safe for work. So be careful where you listen to it. I recommend skipping this podcast if you are offended at obscene language and concepts. Topics usually focus on penetration testing and social engineering. The hosts also have some entertaining war stories about penetration testing.
OWASP Security Podcast focuses on all aspects of web application security. Many of the episodes are short interviews with experts in this field. This podcast is a wonderful way to learn about or keep on top of web application security topics.
Network Security Podcast is a weekly security news podcast covering new stories from the previous week. This show covers all aspects of security. The hosts comment on the news stories, often adding insight which makes the program well worth the listen.
PaulDotCom Security Weekly focuses on the technical side of security. Shows usually include a technical segment, new stories from the previous week, and interviews with special guests. If you want to learn more about the technical side of security this is a podcast you must check out. They also provide very detailed show notes which can be helpful when trying to implement an attack discussed on the show. An episode of PaulDotCom Security Weekly often is broken into two parts and the entire weekly show usually runs two to three hours. If I am running short on podcast time in a week, I also will use the show notes to determine what topics are of interest so I can fast forward to that portion of the podcast.
Risky Business is a news show which focuses on security from down under. The host of the show, Patrick Gray, does a very good job of explaining security concepts and concerns. Patrick also has a good handle on the importance of balancing security with business requirements, something many security folks forget. Because of these two factors, this is a great show for someone just getting into security.
SANS Audio Cast is a short weekly newscast produced by SANS. Episodes tend to be ten to fifteen minutes long so it is a great way to quickly catch up on the hot security news from the previous week. Even if I am running behind on podcasts, I try to listen to this one the week it is released while the information is still fresh.
SecuraBit Podcast is a security news podcast that focuses on technical security topics. I mainly listen to SecuraBit for the special guests they have, who tend to be big names in the security community.
Security Justice is hands down the best security podcast ever made. This monthly podcast covers a variety of security topics but tends to lean more toward physical security and the convergence of physical and logical security. This also is the only security podcast recorded live in a bar. Because this podcast is recorded in a bar, expect bar like language that may not be safe for work. Also in the interest of full disclosure, I should state the author of this post is also a co-host on this show so his views of the show are most likely biased.
Social Media Security Podcast focuses on the security concerns related to social media sites such as Facebook, Twitter, MySpace, and LinkedIn. The team that runs socialmediasecurity.com hosts the show. This podcast is a great way to learn about the threats in the emerging area of social media. The show also provides great case studies and stories that can be used for end user education and awareness training.
Social-Engineering.org Podcast is a monthly podcast focusing on social engineering. Produced by the team that run social-engineering.org, the podcast covers a number of topics related to social engineering. This podcast brings in some amazing guests. At first the guest’s or show topic’s relationship to social engineering might not be clear, but hang in there and the team always ties in how they relate. At its roots this podcast is about how to influence people, which is an important skill for any security professional to have. So even if you are not interested in social engineering, I still recommend you check out a few episodes of this podcast.
The Southern Fried Security Podcast looks at security from the CSO and management level, which is a welcome change from the often technical-heavy security podcasts. The podcast focuses on integrating security into a business and the importance of balancing the business needs with security. Most security professionals have a hard time achieving this balance, so do your self a favor and listen to at least a few episodes of this podcast.
If any of these podcasts sound interesting to you, I recommend you download a few episodes and give them a listen.
What security podcasts do you listen to? Any podcast you think I should start listening to? If so, tell me why in the comments.
Read more!
Monday, September 21, 2009
Using SWOT to Evaluate Your Security Posture
Because the value of security is based on what is prevented, or doesn’t happen, it can be difficult to quantify. One simple way to evaluate your security needs can be with a SWOT analysis modified for security. Almost all of us are familiar with the SWOT analysis- it is business 101. For those who are not, it as an analysis of Strengths, Weaknesses, Opportunities, and Threats. When you are trying to get buy in and the resulting budget for security initiatives, the SWOT analysis lets you speak in the language that executives understand.
The exercise is most effective when combined with the systems approach. Without getting into the details, basically you need to clearly define the security objectives before completing the SWOT analysis.
Objectives can be anything from supporting the organization’s financial goals to protecting client information. If you can put dollar amounts to the categories, you are a step ahead.
Strengths
It is helpful to start with the good. What are the organizations security strengths? For smaller organizations, a strength may be the very fact that they are small, and thus fairly easy to secure. Maybe the organization already has a “security culture” with security embedded. Often, an organization’s strengths present an easy opportunity to increase security. By building on or positively modifying existing controls, security can usually be increased.
Weaknesses
Weakness can be broad or specific. A general lack of a security program or culture is a weakness, but is not defined enough to guide action. Look for specific areas. For example, not having a patch management program in place is a definite weakness. But organizations lacking a robust patch management process have a great opportunity to increase security. We see organizations fall prey to vulnerabilities that would not have been able to be exploited if they had a proper patch management program. Implementing a patch management program may involve spending some money, but it is a small price compared to remediating damage caused by an exploited vulnerability.
Many weaknesses are highly technical in nature. Lack of logging or change management are weaknesses that likely will take significant effort to fix. Articulating the weakness presented by not having systems like this in place and the strengths from implementing them is important to get management to approve the effort. Once again, putting dollar amounts on the costs of a successful exploitation of a vulnerability is paramount.
Another weakness that is especially common in today’s economy is a lack of funds. It can be tough to get buy in for initiatives without ample funding, but for organizations with cash flow problems, the expenses resulting from a security breach may be enough to put them out of business for good. That is a point that if properly articulated, should sway even the most security adverse executive.
Opportunities
Opportunities are generally fairly distinct. Does the organization have funds for security allocated, but not spent? Are logging systems in place, but not used? Do robust security policies exist, but have never been distributed? Think of driving around without buckling the seatbelt. Simply buckling your seatbelt costs nothing, doesn’t take much effort, and instantly and vastly improves safety. Opportunities are low hanging fruit that you can’t afford not to take advantage of. The best part is that taking advantage of most opportunities doesn’t require management approval or any significant spending.
Threats
Many threats, especially from a security perspective, are fairly easy to delineate. If the organization is subject regulations such as PCI DSS, HIPAA or SOX, the cost of non compliance can be astronomical. The costs of reputational damage often far outweigh the fines for non compliance. And the fines for non compliance are stiff.
How do I get started?
A good template in MS Word format for a SWOT analysis can be found here: http://www.zeltser.com/sans/isc/swot-matrix-template.doc
The best place to start is with an assessment. Many times organizations have trouble assessing their own security because they are too close to it, or lack the time or expertise. An experienced outside assessor will have seen countless situations and levels of security, and will be able to help with all four areas of the SWOT analysis.
If an assessment is not possible, a brainstorming session can be good for getting most of the fields started. The more people you can involve in the brainstorming sessions the better, and be sure to include front line employees if possible. They are often aware of the issues that exist in an organization, but lack the proper channels of communication to get to executives.
This is definitely an exercise worth your time and effort. The sooner you get started, the sooner you can approach executive management and get started on increasing security.
Read more!
The exercise is most effective when combined with the systems approach. Without getting into the details, basically you need to clearly define the security objectives before completing the SWOT analysis.
Objectives can be anything from supporting the organization’s financial goals to protecting client information. If you can put dollar amounts to the categories, you are a step ahead.
Strengths
It is helpful to start with the good. What are the organizations security strengths? For smaller organizations, a strength may be the very fact that they are small, and thus fairly easy to secure. Maybe the organization already has a “security culture” with security embedded. Often, an organization’s strengths present an easy opportunity to increase security. By building on or positively modifying existing controls, security can usually be increased.
Weaknesses
Weakness can be broad or specific. A general lack of a security program or culture is a weakness, but is not defined enough to guide action. Look for specific areas. For example, not having a patch management program in place is a definite weakness. But organizations lacking a robust patch management process have a great opportunity to increase security. We see organizations fall prey to vulnerabilities that would not have been able to be exploited if they had a proper patch management program. Implementing a patch management program may involve spending some money, but it is a small price compared to remediating damage caused by an exploited vulnerability.
Many weaknesses are highly technical in nature. Lack of logging or change management are weaknesses that likely will take significant effort to fix. Articulating the weakness presented by not having systems like this in place and the strengths from implementing them is important to get management to approve the effort. Once again, putting dollar amounts on the costs of a successful exploitation of a vulnerability is paramount.
Another weakness that is especially common in today’s economy is a lack of funds. It can be tough to get buy in for initiatives without ample funding, but for organizations with cash flow problems, the expenses resulting from a security breach may be enough to put them out of business for good. That is a point that if properly articulated, should sway even the most security adverse executive.
Opportunities
Opportunities are generally fairly distinct. Does the organization have funds for security allocated, but not spent? Are logging systems in place, but not used? Do robust security policies exist, but have never been distributed? Think of driving around without buckling the seatbelt. Simply buckling your seatbelt costs nothing, doesn’t take much effort, and instantly and vastly improves safety. Opportunities are low hanging fruit that you can’t afford not to take advantage of. The best part is that taking advantage of most opportunities doesn’t require management approval or any significant spending.
Threats
Many threats, especially from a security perspective, are fairly easy to delineate. If the organization is subject regulations such as PCI DSS, HIPAA or SOX, the cost of non compliance can be astronomical. The costs of reputational damage often far outweigh the fines for non compliance. And the fines for non compliance are stiff.
How do I get started?
A good template in MS Word format for a SWOT analysis can be found here: http://www.zeltser.com/sans/isc/swot-matrix-template.doc
The best place to start is with an assessment. Many times organizations have trouble assessing their own security because they are too close to it, or lack the time or expertise. An experienced outside assessor will have seen countless situations and levels of security, and will be able to help with all four areas of the SWOT analysis.
If an assessment is not possible, a brainstorming session can be good for getting most of the fields started. The more people you can involve in the brainstorming sessions the better, and be sure to include front line employees if possible. They are often aware of the issues that exist in an organization, but lack the proper channels of communication to get to executives.
This is definitely an exercise worth your time and effort. The sooner you get started, the sooner you can approach executive management and get started on increasing security.
Read more!
Friday, May 15, 2009
Security Assessments: Cheaper Not Always Better
In today's economy, money is obviously tight. As Ken pointed out in his blog post "Economy bad… breaches go up!", companies should be spending MORE money on assessments, not cutting back in the area. With that being said, here is some insight from a penetration tester who hacks daily on some of the things I've seen on the front lines...
So your company decides it is time to have a penetration test performed...whether it is an annual pen test, an RFP that was put out, or for some other reason, that reason for performing one may vary is outside the scope of this blog post. The number one factor for *many* people on anything is budget. Money makes this world go around. The root cause of cybercrime is money. Why do criminals steal SSN's and account numbers? To obtain money in the end. Since everyone seems to be short on budget these days, choosing the least expensive security assessor is not always the best way to go. In fact, the majority of the time I've seen it to turn out poorly much of the time. Of course, there are many things that factor into it. Some of these would be which assessors were considered for the work, how many there were in the running, etc.
To put things into perspective, here are some of things to consider when looking to have an information security assessment performed:
1. [insert large popular assessor name here] gives us a discount each year, and they told us we were good.
Does bigger always mean better? No. We can go back and look at several data breaches, especially those involving PCI data to see that large/well-known assessors had signed off on the companies that were broken into as being compliant despite not having fulfilled all of the requirements of the PCI DSS.
2. I used the local ISP, they are cheap and right here in my backyard.
That's great that they are local, but they are an ISP. They provide your Internet connection, and most likely don't specialize in security. At the end of the day, do you think they could tell you more about the latest attack trends out there or MPLS and OC45's?
3. We took the low bid on our RFP, and the assessor didn't break in for the internal penetration test...
This came from a multi-billion dollar company and the RFP included extensive internal penetration testing. If the penetration testing team does not break in on the internal network, their skills are quite questionable. The internal network is usually the squishy center of the network whereas the external facing portion is usually hardened. Unless it is a network with crazy security controls in place such as some government networks or other extremely confidential networks, there will be vulnerabilities present. The success rate of the assessor for breaking in might be a good thing to ask when shopping around.
4. For our last "penetration test", the vendor asked for a domain administrator account.
Are you kidding me?! Anyone can run nessus with credentials and reformat the report to look differently. A penetration test should be treated as if it were a real attack. What does this mean? This means that externally, the only information given should be the company or organization name. We can safely assume at the very least level that is what an attacker might have. For internal penetration tests, have the penetration testing team simply plug into the network and start from there. You shouldn't always have to give them an IP address, have them test out your NAC(network access control) perhaps, or even have them do a physical pen test to attempt to physically penentrate the building and do it all as if they are a true criminal targetting the organization. Whatever the scenario is, using a domain administrator account or any other credentialed automated scan is NOT a penetration test. A "vulnerability assessment" is running automated tools to identify vulnerabilities. When performing a penetration test, running such "noisy" tools will obviously get detected. A penetration test involves manual attacks targetting specific systems that in the end, will allow for unauthorized access. Don't get me wrong, automated vulnerability scanners are great for say, checking systems for the latest patches, but a vulnerability assessment does not equal a penetration test. I see this presented on many security assessors websites, and I am in disbelief every time. Be aware of what the security assessor is proposing in their statement of work.
There are tons of assessors out there. How do you know which are the best choice? Obviously price is a major factor, and when choosing, there are other things to consider too. What all does the vendor do? Do they perform penetration tests, sell products, do implementations, manage those solutions, and even support them? Can you trust them to not have a biased or swayed opinion or report if they have a financial interest in fixing what they found, selling you new products, as well as implementation and support of them? If the vendor conducting your testing does "everything" for you, the end all be all solution provider, they probably are not. Everyone says they can do everything, however it has been shown that once you "do everything", you become a generalist, and start to lack expertise in what you used to be good at. Ask for resumes or individual expertise for assessors that will be on the assessment team performing work for you. Someone who hacks all day every day versus your local ISP is going to be a no-brainer on what the outcome will be. Your local computer shop probably advertises building PC's, wireless networks, doing security, etc. Again, you may want to question any vendor that says they can do everything, and limit your selection to vendors that only do security assessments as their specialty.
Whether you choose SecureState or another security assessor for your assessments, remember that cheaper does not always mean better.
Read more!
So your company decides it is time to have a penetration test performed...whether it is an annual pen test, an RFP that was put out, or for some other reason, that reason for performing one may vary is outside the scope of this blog post. The number one factor for *many* people on anything is budget. Money makes this world go around. The root cause of cybercrime is money. Why do criminals steal SSN's and account numbers? To obtain money in the end. Since everyone seems to be short on budget these days, choosing the least expensive security assessor is not always the best way to go. In fact, the majority of the time I've seen it to turn out poorly much of the time. Of course, there are many things that factor into it. Some of these would be which assessors were considered for the work, how many there were in the running, etc.
To put things into perspective, here are some of things to consider when looking to have an information security assessment performed:
1. [insert large popular assessor name here] gives us a discount each year, and they told us we were good.
Does bigger always mean better? No. We can go back and look at several data breaches, especially those involving PCI data to see that large/well-known assessors had signed off on the companies that were broken into as being compliant despite not having fulfilled all of the requirements of the PCI DSS.
2. I used the local ISP, they are cheap and right here in my backyard.
That's great that they are local, but they are an ISP. They provide your Internet connection, and most likely don't specialize in security. At the end of the day, do you think they could tell you more about the latest attack trends out there or MPLS and OC45's?
3. We took the low bid on our RFP, and the assessor didn't break in for the internal penetration test...
This came from a multi-billion dollar company and the RFP included extensive internal penetration testing. If the penetration testing team does not break in on the internal network, their skills are quite questionable. The internal network is usually the squishy center of the network whereas the external facing portion is usually hardened. Unless it is a network with crazy security controls in place such as some government networks or other extremely confidential networks, there will be vulnerabilities present. The success rate of the assessor for breaking in might be a good thing to ask when shopping around.
4. For our last "penetration test", the vendor asked for a domain administrator account.
Are you kidding me?! Anyone can run nessus with credentials and reformat the report to look differently. A penetration test should be treated as if it were a real attack. What does this mean? This means that externally, the only information given should be the company or organization name. We can safely assume at the very least level that is what an attacker might have. For internal penetration tests, have the penetration testing team simply plug into the network and start from there. You shouldn't always have to give them an IP address, have them test out your NAC(network access control) perhaps, or even have them do a physical pen test to attempt to physically penentrate the building and do it all as if they are a true criminal targetting the organization. Whatever the scenario is, using a domain administrator account or any other credentialed automated scan is NOT a penetration test. A "vulnerability assessment" is running automated tools to identify vulnerabilities. When performing a penetration test, running such "noisy" tools will obviously get detected. A penetration test involves manual attacks targetting specific systems that in the end, will allow for unauthorized access. Don't get me wrong, automated vulnerability scanners are great for say, checking systems for the latest patches, but a vulnerability assessment does not equal a penetration test. I see this presented on many security assessors websites, and I am in disbelief every time. Be aware of what the security assessor is proposing in their statement of work.
There are tons of assessors out there. How do you know which are the best choice? Obviously price is a major factor, and when choosing, there are other things to consider too. What all does the vendor do? Do they perform penetration tests, sell products, do implementations, manage those solutions, and even support them? Can you trust them to not have a biased or swayed opinion or report if they have a financial interest in fixing what they found, selling you new products, as well as implementation and support of them? If the vendor conducting your testing does "everything" for you, the end all be all solution provider, they probably are not. Everyone says they can do everything, however it has been shown that once you "do everything", you become a generalist, and start to lack expertise in what you used to be good at. Ask for resumes or individual expertise for assessors that will be on the assessment team performing work for you. Someone who hacks all day every day versus your local ISP is going to be a no-brainer on what the outcome will be. Your local computer shop probably advertises building PC's, wireless networks, doing security, etc. Again, you may want to question any vendor that says they can do everything, and limit your selection to vendors that only do security assessments as their specialty.
Whether you choose SecureState or another security assessor for your assessments, remember that cheaper does not always mean better.
Read more!
Friday, March 6, 2009
Firewall Ruleset Review
I’ve done a lot of firewall ruleset reviews for companies large and small. There is a pattern forming in almost every firewall I’ve seen.
Bad management.
It’s not about blaming people though. The economy is in the sewer and layoffs plague every company across the planet. Most every security team is dealing with tons of ongoing work to stay secure and low budgets and resources to get the job done.
The firewall rule sets I’ve seen range from 50 lines to 10,000+ lines. Some are so complex that we schedule a week of work to audit and determine what can be taken out, what needs to stay and what shouldn’t have been there in the first place.
Let’s face it; many firewalls have dead rules, non-existent networks and “permit any” rules. Those are the low lying fruit that we look for first and when fixed, automatically increase security surrounding the attached networks.
Any access list that ends in “permit ip any any” is wasted CPU power and increased RAM usage. Why make your firewall go thru all of those rules if you permit everything at the end anyways? Not to mention, if you’re going to do that, you could have saved yourself hundreds or thousands of dollars and just gotten a router and used static routes to forward traffic. But in the security world that isn’t an option.
Too often we see timeout settings that are too large, insecure protocols being used and lack of ingress or egress rules. The worst cases are the firewalls that are built backwards (a whole slew of deny statements followed by a permit any statement).
Overall, the largest issue is lack of egress filtering. Time and time again, we run into this. And in many of our assessments we capitalize on this. In both Social Engineering attacks and Penetration tests we are able to accomplish many tasks by using these lax rules. Even if you aren’t worried about the next major virus or worm, you should care in not helping spread the infection. Close your doors and be a good neighbor!
All of these issues add up to the sum of bad network security which is caused by bad management. There needs to be process and documentation of all rules and configuration settings within a configuration. Asking “Hey Chuck, there’s a strange rule in here, did you do that?” doesn’t count as documentation either.
At the end of the day, if you skip on a little security here and a little security there, what’s the point of implementing high dollar equipment? If you’re going to implement your firewall properly you should have dedicated process behind the ruleset. Justify every rule, every business segment, set it, and forget it. There should be no need to constantly be modifying your firewall. I can see the need if you’re installing a new server or software package, but adding and dropping lines daily or even weekly is not efficient use of anyone’s time.
The moral of the story is, if you are making constant changes, have bad rules, or an insecure configuration, then you should start over and build your configuration properly. A regular audit of the firewall ruleset is always a good idea and should be budgeted for. Put in the proper change control, documentation and justification, and you will be amazed how much more secure your network will become.
Read more!
Bad management.
It’s not about blaming people though. The economy is in the sewer and layoffs plague every company across the planet. Most every security team is dealing with tons of ongoing work to stay secure and low budgets and resources to get the job done.
The firewall rule sets I’ve seen range from 50 lines to 10,000+ lines. Some are so complex that we schedule a week of work to audit and determine what can be taken out, what needs to stay and what shouldn’t have been there in the first place.
Let’s face it; many firewalls have dead rules, non-existent networks and “permit any” rules. Those are the low lying fruit that we look for first and when fixed, automatically increase security surrounding the attached networks.
Any access list that ends in “permit ip any any” is wasted CPU power and increased RAM usage. Why make your firewall go thru all of those rules if you permit everything at the end anyways? Not to mention, if you’re going to do that, you could have saved yourself hundreds or thousands of dollars and just gotten a router and used static routes to forward traffic. But in the security world that isn’t an option.
Too often we see timeout settings that are too large, insecure protocols being used and lack of ingress or egress rules. The worst cases are the firewalls that are built backwards (a whole slew of deny statements followed by a permit any statement).
Overall, the largest issue is lack of egress filtering. Time and time again, we run into this. And in many of our assessments we capitalize on this. In both Social Engineering attacks and Penetration tests we are able to accomplish many tasks by using these lax rules. Even if you aren’t worried about the next major virus or worm, you should care in not helping spread the infection. Close your doors and be a good neighbor!
All of these issues add up to the sum of bad network security which is caused by bad management. There needs to be process and documentation of all rules and configuration settings within a configuration. Asking “Hey Chuck, there’s a strange rule in here, did you do that?” doesn’t count as documentation either.
At the end of the day, if you skip on a little security here and a little security there, what’s the point of implementing high dollar equipment? If you’re going to implement your firewall properly you should have dedicated process behind the ruleset. Justify every rule, every business segment, set it, and forget it. There should be no need to constantly be modifying your firewall. I can see the need if you’re installing a new server or software package, but adding and dropping lines daily or even weekly is not efficient use of anyone’s time.
The moral of the story is, if you are making constant changes, have bad rules, or an insecure configuration, then you should start over and build your configuration properly. A regular audit of the firewall ruleset is always a good idea and should be budgeted for. Put in the proper change control, documentation and justification, and you will be amazed how much more secure your network will become.
Read more!
Friday, January 16, 2009
SecureState Attends PCI Compliance Seminar with ISACA
Craig Monastra of Sterling Jewelers with Brian Telesz and Nicole McClain of SecureState
Today, ISACA’s membership—more than 86,000 strong worldwide—is characterized by its diversity. Members live and work in more than 160 countries and cover a variety of professional IT-related positions inlcuding but not limited to IS auditor, consultant, educator, IS security professional, regulator, chief information officer and internal auditor.
SecureState's Brian Telesz and Nicole McClain (pictured above with Craig Monastra of Sterling Jewelers) attended the most recent ISACA seminar at Harry's Steakhouse for good food and a great presentation on PCI Compliance. Keynote speaker was Lisa Peterson of Progressive Insurance.
The Information Systems Audit and Control Association is primarily focused on promoting quality IS audit and governance education to its members. The IS audit profession is based and dependent upon technological expertise. With Audit and Compliance being one of SecureState’s four divisions of expertise its helps our consultants and directors keep abreast on the latest hot topics, concerns and trends in the IT audit world. SecureState is a leader in the Audit and Compliance world. We engage in many different environments such as finance, insurance, manufacturing, retail and energy which gives us a very diverse expertise in the many compliances and security regulations that companies need to adhere to.
In addition to the importance of Audit and Compliance, SecureState belongs to the local chapter and attends the monthly meetings to keep SecureState in front our current and prospective clients who are members. We will also speak and present at these monthly meetings which helps educate ISACA chapter members on what SecureState sees out in the field during engagements and clarify and educate on IT audit issues.
Would you like SecureState to speak at your next event? Contact SecureState at 800.903.6264 for more information.
SecureState's Brian Telesz and Nicole McClain (pictured above with Craig Monastra of Sterling Jewelers) attended the most recent ISACA seminar at Harry's Steakhouse for good food and a great presentation on PCI Compliance. Keynote speaker was Lisa Peterson of Progressive Insurance.
The Information Systems Audit and Control Association is primarily focused on promoting quality IS audit and governance education to its members. The IS audit profession is based and dependent upon technological expertise. With Audit and Compliance being one of SecureState’s four divisions of expertise its helps our consultants and directors keep abreast on the latest hot topics, concerns and trends in the IT audit world. SecureState is a leader in the Audit and Compliance world. We engage in many different environments such as finance, insurance, manufacturing, retail and energy which gives us a very diverse expertise in the many compliances and security regulations that companies need to adhere to.
In addition to the importance of Audit and Compliance, SecureState belongs to the local chapter and attends the monthly meetings to keep SecureState in front our current and prospective clients who are members. We will also speak and present at these monthly meetings which helps educate ISACA chapter members on what SecureState sees out in the field during engagements and clarify and educate on IT audit issues.
Would you like SecureState to speak at your next event? Contact SecureState at 800.903.6264 for more information.
Read more!
Wednesday, December 24, 2008
Security Stuck at the Kids Table?
Where does the Security Department reside at your organization?
I am sure many readers with first answer this question with, “What Security Department?” That is a fair answer for many organizations out there in the real world and for those of you that answered the question that way, I feel sorry for you and your organization... It is only a matter of time before you end up on the front page on the newspaper with a headline reading something like, “Hacker Breaches Company ABC, takes 100,000 Social Security Numbers” or “Insider Steals 20,000 Credit Card Numbers from Company XYZ.” Trust me, I have seen it before. It is only a matter of time.
For the rest of you, where does Security sit? Under the Director of IT? Under the Chief Information Officer? How about under the Audit Department? While there are advantages to each, the disadvantages far outweigh the benefits.
Let’s examine.
Under the Director of IT: Last time I checked, the IT department’s main concern is the availability of resources and data. As a security guy, I really don’t care about availability. If our network is unavailable, we are secure. As such, every decision I make in the best interest of security is going to be analyzed based on the effects of availability, and if these decisions conflict with their goals, they are not going to go far.
Under the CIO: Same problems as above and also include problems with lack of funding, lack of power (i.e. the ability to make decisions and have them implemented), and lack of representation in senior management.
Under the Audit Department: Who is an auditor’s on friend? Another auditor! Okay, so that wasn’t a good joke, but there is truth to it. Most people don’t like auditors and being stuck under that department makes others think Security is one of them. Therefore, everyone from the bottom to the top will be generally “on guard” when you come around and resistant to your goals because of it.
So where is the best place for Security to sit? At the same level as the CIO, but independent from them. Security should be its own Department and have its own voice in the Senior Management circle. They should have their own budget and the ability to defend all decisions made in the best interest of security without being kyboshed before it makes it to the C-level.
In a world with increasingly more stringent regulations and compliances (i.e. PCI, HIPAA, SOX, GLBA), and more sophisticated hackers and hacking techniques, it’s time to move Security where it rightfully belongs, at the adult table.
Read more!
I am sure many readers with first answer this question with, “What Security Department?” That is a fair answer for many organizations out there in the real world and for those of you that answered the question that way, I feel sorry for you and your organization... It is only a matter of time before you end up on the front page on the newspaper with a headline reading something like, “Hacker Breaches Company ABC, takes 100,000 Social Security Numbers” or “Insider Steals 20,000 Credit Card Numbers from Company XYZ.” Trust me, I have seen it before. It is only a matter of time.
For the rest of you, where does Security sit? Under the Director of IT? Under the Chief Information Officer? How about under the Audit Department? While there are advantages to each, the disadvantages far outweigh the benefits.
Let’s examine.
Under the Director of IT: Last time I checked, the IT department’s main concern is the availability of resources and data. As a security guy, I really don’t care about availability. If our network is unavailable, we are secure. As such, every decision I make in the best interest of security is going to be analyzed based on the effects of availability, and if these decisions conflict with their goals, they are not going to go far.
Under the CIO: Same problems as above and also include problems with lack of funding, lack of power (i.e. the ability to make decisions and have them implemented), and lack of representation in senior management.
Under the Audit Department: Who is an auditor’s on friend? Another auditor! Okay, so that wasn’t a good joke, but there is truth to it. Most people don’t like auditors and being stuck under that department makes others think Security is one of them. Therefore, everyone from the bottom to the top will be generally “on guard” when you come around and resistant to your goals because of it.
So where is the best place for Security to sit? At the same level as the CIO, but independent from them. Security should be its own Department and have its own voice in the Senior Management circle. They should have their own budget and the ability to defend all decisions made in the best interest of security without being kyboshed before it makes it to the C-level.
In a world with increasingly more stringent regulations and compliances (i.e. PCI, HIPAA, SOX, GLBA), and more sophisticated hackers and hacking techniques, it’s time to move Security where it rightfully belongs, at the adult table.
Read more!
Tuesday, December 23, 2008
Economy bad… breaches go up!
Cut jobs, layoff people, hell don’t buy coffee, but don’t spend less on assessments during a down economy!
Contrary to popular belief during a down economy it is crucial that companies maintain an assessment program. Based on an article I recently wrote for law.com... when the economy is bad (which appears to be the case for 2009) the chance for theft of corporate assets increases. Based on the fraud triangle below are three areas that if aligned a person is willing to steal, commit fraud or worse.
Getting budget gets tougher and tougher when you don’t know what the real risks are. Hence, next year (2009), spend money on a risk assessment. Yes risk assessments cost more, but they identify more risk and more importantly map the business requirements to those risks. Now you are telling the board or CEO of the risks, not just the results of a penetration test. This is key; we as security practitioners do not want to hold the risk!
Over the past several years I have noticed an increase in January/February breaches and hacking activity. While I can not statistically back up this observation, I can guarantee you that with a down economy and the holiday season, people will have more free time. Especially kids that are off from school, this is an ideal time to try some new hacks out, maybe the latest version of FastTrak.
Read more!
Contrary to popular belief during a down economy it is crucial that companies maintain an assessment program. Based on an article I recently wrote for law.com... when the economy is bad (which appears to be the case for 2009) the chance for theft of corporate assets increases. Based on the fraud triangle below are three areas that if aligned a person is willing to steal, commit fraud or worse.
- Rationalization- The day an employee starts they start to rationalize… I worked all weekend and no one else was here… especially my boss!
- Pressure- Given the economy this is an understatement; pressure is all over the place. With one in five homes being foreclosed on it’s a safe bet that one of your employees will have financial pressure.
- Opportunity- Probably the only area that we can actual control. Taking away or reducing the opportunity is key. Assessments are actually the lowest cost solution to identify the risky areas.
Getting budget gets tougher and tougher when you don’t know what the real risks are. Hence, next year (2009), spend money on a risk assessment. Yes risk assessments cost more, but they identify more risk and more importantly map the business requirements to those risks. Now you are telling the board or CEO of the risks, not just the results of a penetration test. This is key; we as security practitioners do not want to hold the risk!
Over the past several years I have noticed an increase in January/February breaches and hacking activity. While I can not statistically back up this observation, I can guarantee you that with a down economy and the holiday season, people will have more free time. Especially kids that are off from school, this is an ideal time to try some new hacks out, maybe the latest version of FastTrak.
Read more!
Wednesday, November 12, 2008
And You Thought Graphics Cards Were Just For Gaming
I have always been a fan of the latest and greatest hardware and always been amazed on how fast new hardware is getting. Well now the Security field is going to have to start worrying about how this hardware is being leveraged to crack passwords. The Nvidia Corporation has harnessed the functionality of the C programming language and integrated it with their newest GPU’s to form the CUDA Technology.
In Fact, even the Lenovo T60 and T61’s are loaded with Nvidia Quadro graphics cards that can run CUDA software. There are even Python bindings for CUDA and many other languages may enter this arena. Applications for Fluid Dynamics, Digital Media, Electronic Design, Finance, Game Physics, Audio and Video, and many more have already been developed and more are on the way.
What I mentioned before is about Information Security. There is also software released to take advantage of “password recovery” and it is stunningly fast. Modern dual-core CPU’s such as the Intel Core 2 Duo and the AMD Athlon X2’s are able to test approximately 2 trillion passwords in about 3 days whereas CUDA based “Password Recovery” software can do 55 trillion in the same time frame. That is almost 25 times faster!
The reason these new cards are able to run software like this is because these new generation chips, named the G80 series, are able to compute fixed-point operations. The new Nvidia GTX 280 Graphics card boasts 1GB of 1100 MHz GDDR3 memory on a 512-bit path with 240 processing cores (actually called ALU’s) running at 600-650 MHz at a cost of $450/card.
Nvidia says the card is able to reach close to 1 Teraflop (Trillions of floating point operations per second) of compute capability. The first super computer to reach the 1 Teraflop barrier was in December of 1997 and was the size of a mid-sized house. It was 76 computer cabinets holding 9072 Pentium Pro Processors. (http://www.sandia.gov/media/online.htm) You can check back at http://www.top500.org/ for the fastest super computers in the world.
So with these Desktop Super-Computers doing tasks that multi-million dollar Teraflop computers are capable of, what if someone found a way to harness this technology to crack passwords in your organization? Or if they captured enough data and were able to un-encrypt classified data? How about AES-256 bit encrypted hard drives? Let’s look at it this way. Most likely your company’s password complexity is too weak. The only way to make it harder (still not impossible) is to force your users to use long pass-phrases, strengthen your domain policies and provide user awareness training.
The thing that makes this CUDA Technology so fast is that threads are able to communicate. These 240 cores work in tandem using Parallel Data Cache (A.K.A. shared memory http://www.beyond3d.com/content/articles/12/3) which saves clock cycles since it isn’t going all the way out to the card’s GDDR memory for additional data or temporary storage. Additionally, with the current Nvidia software and the proper hardware configuration, you can strap 1-4 of those cards to a quad core CPU and have an absolutely amazing system that could reach the 2 TeraFLOP range. And if that isn’t enough, Nvidia allows their consumers to over clock within the Nvidia Control Panel software.
One company has already gone the distance to “recover” passwords. Elcomsoft makes a software package that allows up to 10,000 distributed client workstations to “recover strong encryption keys” with each client having up to 4 GPU’s each. What government agency or research lab wouldn’t want something as powerful as that? The software is capable of “recovering” MS Office 97-07 passwords, Zip and RAR passwords, MS Money, Open Documents, all PGP passwords, Personal Information Exchange certificates - PKCS #12 (.PFX, .P12), Adobe Acrobat PDF, Domain Cached Credentials, Unix passwords, Intuit Quicken Passwords, MD5 Hashes, Oracle Passwords and WEP, WPA and WPA2 Passwords. (http://www.elcomsoft.com/edpr.html) Many of those operations are considered to be “GPU Accelerated” Options.
According to Elcomsoft’s own press release "Elcomsoft Distributed Password Recovery allows using laptop, desktop or server computers equipped with supported Nvidia video cards to break Wi-Fi encryption up to 100 times faster than by using CPU only." The software is said to support ATI Graphics cards early next year. I would find it only a matter of time until the underground community uses this technology to crack DRM as well as other cryptographic enabled media. (http://www.elcomsoft.com/pr.html)
Remember, this technology doesn’t have to be used in just password “recovery.” (http://www.nvidia.com/object/cuda_home.html#) There is such a large amount of science and technology that will benefit from this. Mathematics, Digital media, Programming and best of all, Games.
Read more!
In Fact, even the Lenovo T60 and T61’s are loaded with Nvidia Quadro graphics cards that can run CUDA software. There are even Python bindings for CUDA and many other languages may enter this arena. Applications for Fluid Dynamics, Digital Media, Electronic Design, Finance, Game Physics, Audio and Video, and many more have already been developed and more are on the way.
What I mentioned before is about Information Security. There is also software released to take advantage of “password recovery” and it is stunningly fast. Modern dual-core CPU’s such as the Intel Core 2 Duo and the AMD Athlon X2’s are able to test approximately 2 trillion passwords in about 3 days whereas CUDA based “Password Recovery” software can do 55 trillion in the same time frame. That is almost 25 times faster!
The reason these new cards are able to run software like this is because these new generation chips, named the G80 series, are able to compute fixed-point operations. The new Nvidia GTX 280 Graphics card boasts 1GB of 1100 MHz GDDR3 memory on a 512-bit path with 240 processing cores (actually called ALU’s) running at 600-650 MHz at a cost of $450/card.
Nvidia says the card is able to reach close to 1 Teraflop (Trillions of floating point operations per second) of compute capability. The first super computer to reach the 1 Teraflop barrier was in December of 1997 and was the size of a mid-sized house. It was 76 computer cabinets holding 9072 Pentium Pro Processors. (http://www.sandia.gov/media/online.htm) You can check back at http://www.top500.org/ for the fastest super computers in the world.
So with these Desktop Super-Computers doing tasks that multi-million dollar Teraflop computers are capable of, what if someone found a way to harness this technology to crack passwords in your organization? Or if they captured enough data and were able to un-encrypt classified data? How about AES-256 bit encrypted hard drives? Let’s look at it this way. Most likely your company’s password complexity is too weak. The only way to make it harder (still not impossible) is to force your users to use long pass-phrases, strengthen your domain policies and provide user awareness training.
The thing that makes this CUDA Technology so fast is that threads are able to communicate. These 240 cores work in tandem using Parallel Data Cache (A.K.A. shared memory http://www.beyond3d.com/content/articles/12/3) which saves clock cycles since it isn’t going all the way out to the card’s GDDR memory for additional data or temporary storage. Additionally, with the current Nvidia software and the proper hardware configuration, you can strap 1-4 of those cards to a quad core CPU and have an absolutely amazing system that could reach the 2 TeraFLOP range. And if that isn’t enough, Nvidia allows their consumers to over clock within the Nvidia Control Panel software.
One company has already gone the distance to “recover” passwords. Elcomsoft makes a software package that allows up to 10,000 distributed client workstations to “recover strong encryption keys” with each client having up to 4 GPU’s each. What government agency or research lab wouldn’t want something as powerful as that? The software is capable of “recovering” MS Office 97-07 passwords, Zip and RAR passwords, MS Money, Open Documents, all PGP passwords, Personal Information Exchange certificates - PKCS #12 (.PFX, .P12), Adobe Acrobat PDF, Domain Cached Credentials, Unix passwords, Intuit Quicken Passwords, MD5 Hashes, Oracle Passwords and WEP, WPA and WPA2 Passwords. (http://www.elcomsoft.com/edpr.html) Many of those operations are considered to be “GPU Accelerated” Options.
According to Elcomsoft’s own press release "Elcomsoft Distributed Password Recovery allows using laptop, desktop or server computers equipped with supported Nvidia video cards to break Wi-Fi encryption up to 100 times faster than by using CPU only." The software is said to support ATI Graphics cards early next year. I would find it only a matter of time until the underground community uses this technology to crack DRM as well as other cryptographic enabled media. (http://www.elcomsoft.com/pr.html)
Remember, this technology doesn’t have to be used in just password “recovery.” (http://www.nvidia.com/object/cuda_home.html#) There is such a large amount of science and technology that will benefit from this. Mathematics, Digital media, Programming and best of all, Games.
Read more!
Subscribe to:
Posts (Atom)
Posts
