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 compliance. Show all posts
Showing posts with label compliance. 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!
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!
Thursday, August 28, 2008
Dear NERC, CIP needs a protein shake...
We've been posting a lot of information about compliance regulation lately, so I'll just add another scoop to this steamy pile...
The North American Electric Reliability Corporation (NERC) is a self-regulatory (non-governmental) organization subject to oversight by the U.S. Federal Energy Regulatory Commission (FERC). As of June 18, 2007, FERC granted NERC the legal authority to enforce reliability standards with all U.S. users, owners, and operators of the bulk power system, and made compliance with those standards mandatory and enforceable.
The preceding paragraph came pretty much verbatim from the NERC website. Now that we have a little insight on NERC, let's stop FERC'in around and talk about Critical Infrastructure Protection (CIP).
CIP was designed to protect the United States critical infrastructure and features a heavy emphasis on safeguarding critical cyber assets (CCA) that help run the systems that generate electricity and control the transmission of electricity. The CIP standard is broken down into 8 individual requirements (CIP-002 through CIP-009) for various areas of protection or security. Audits for NERC CIP begin July 1, 2009. You might recall a certain blackout of 2003 that affected a large number of northeastern states? Hmmmmmm?? This prompted the NERC CIP standard, much like Enron prompted SOX.
As assessors or auditors, our team works with many different standards and regulations, and we've done a lot of NERC CIP related work with our energy clients over the past year. We've heard multiple complaints from clients about the CIP standard being vague or hazy, and I tend to agree. The clarity on protection levels that are expected are muddy.
As far as standards go, CIP needs a protein shake. We're talking about a standard that's designed to protect some of the country's most critical systems. It NEEDS to be stronger.
And what's with the non-standard terms in the standard? "Cyber"? "Electronic Security Perimeter"?
Really? Who uses those?
Why don't they just throw in "microcomputer" or "World Wide Web"?
While other standards and compliance reg's require penetration testing, CIP only requires vulnerability scanning. Scanning for modems is referenced quite a bit in CIP, but there's practically nothing related to wireless. Sure, there are tons of modems out there, especially in those sectors, but NERC needs to let go of 1996. Check out some of the latest breaches across the country - I can't remember the last time I read a story about a compromise being traced back to a dusty modem. (Calm down, calm down...I know it still happens, just not as frequently.) And what about the exception for nuke plants? Why can't you apply NERC CIP to nuke plants as well? Businesses have to deal with multiple compliance efforts ALL THE TIME. Why wouldn't you use CIP as a "second set of eyes" for those sites?
And one more before I move on to the positives of NERC CIP. The standard isn't a shadow of what other regulations like PCI are requiring. You mean to tell me that the standards for the companies that allow me to turn on my lights are less than those of the companies that want to swipe my plastic?
NEWS FLASH: If the power is off, no one cares about PCI, HIPAA, or SOX.
Why?
Because the 'puters, calculators, and credit card processors don't work so well without power.
On a positive note - NERC CIP outlines a great schedule for compliance, with different progression paths. It's very detailed and could be something that other regulations take note of. The standard also breaks down what can be used as measures to demonstrate compliance, as well as specific levels of non-compliance which act as a nice grading system.
All in all, the standard has some positives but plenty of negatives. In my opinion, it has a long way to go before I stop stocking up on candles.
Read more!
The North American Electric Reliability Corporation (NERC) is a self-regulatory (non-governmental) organization subject to oversight by the U.S. Federal Energy Regulatory Commission (FERC). As of June 18, 2007, FERC granted NERC the legal authority to enforce reliability standards with all U.S. users, owners, and operators of the bulk power system, and made compliance with those standards mandatory and enforceable.
The preceding paragraph came pretty much verbatim from the NERC website. Now that we have a little insight on NERC, let's stop FERC'in around and talk about Critical Infrastructure Protection (CIP).
CIP was designed to protect the United States critical infrastructure and features a heavy emphasis on safeguarding critical cyber assets (CCA) that help run the systems that generate electricity and control the transmission of electricity. The CIP standard is broken down into 8 individual requirements (CIP-002 through CIP-009) for various areas of protection or security. Audits for NERC CIP begin July 1, 2009. You might recall a certain blackout of 2003 that affected a large number of northeastern states? Hmmmmmm?? This prompted the NERC CIP standard, much like Enron prompted SOX.
As assessors or auditors, our team works with many different standards and regulations, and we've done a lot of NERC CIP related work with our energy clients over the past year. We've heard multiple complaints from clients about the CIP standard being vague or hazy, and I tend to agree. The clarity on protection levels that are expected are muddy.
As far as standards go, CIP needs a protein shake. We're talking about a standard that's designed to protect some of the country's most critical systems. It NEEDS to be stronger.
And what's with the non-standard terms in the standard? "Cyber"? "Electronic Security Perimeter"?
Really? Who uses those?
Why don't they just throw in "microcomputer" or "World Wide Web"?
While other standards and compliance reg's require penetration testing, CIP only requires vulnerability scanning. Scanning for modems is referenced quite a bit in CIP, but there's practically nothing related to wireless. Sure, there are tons of modems out there, especially in those sectors, but NERC needs to let go of 1996. Check out some of the latest breaches across the country - I can't remember the last time I read a story about a compromise being traced back to a dusty modem. (Calm down, calm down...I know it still happens, just not as frequently.) And what about the exception for nuke plants? Why can't you apply NERC CIP to nuke plants as well? Businesses have to deal with multiple compliance efforts ALL THE TIME. Why wouldn't you use CIP as a "second set of eyes" for those sites?
And one more before I move on to the positives of NERC CIP. The standard isn't a shadow of what other regulations like PCI are requiring. You mean to tell me that the standards for the companies that allow me to turn on my lights are less than those of the companies that want to swipe my plastic?
NEWS FLASH: If the power is off, no one cares about PCI, HIPAA, or SOX.
Why?
Because the 'puters, calculators, and credit card processors don't work so well without power.
On a positive note - NERC CIP outlines a great schedule for compliance, with different progression paths. It's very detailed and could be something that other regulations take note of. The standard also breaks down what can be used as measures to demonstrate compliance, as well as specific levels of non-compliance which act as a nice grading system.
All in all, the standard has some positives but plenty of negatives. In my opinion, it has a long way to go before I stop stocking up on candles.
Read more!
Friday, August 22, 2008
Regulations Attack
I recently published top eight trends for 08’ (http://www.securestate.com/Pages/Top-8-In-08.aspx), however one topic in particular has caught my attention, why are “Regulations” being attacked?
At DefCon 16 I had the opportunity to meet some really interesting people who had different perspectives on security. However, for the first time in DefCon history (to my knowledge) “Compliance” standards opened the conference Friday morning. I was so excited to hear what the “hackers” thought about PCI, GLBA, HIPAA etc. To my disappointment, the presenter ranted about how compliance doesn’t equal security… DUH! But what they do is provide some value and the value is called “doing something!” Hell, most companies (97%) won’t do anything at all until they are forced!
Even with these standards, millions of records are still being compromised. Let’s rant about companies losing our data, not about how bad the regulations are. Let’s face it, if companies were doing what they should, there wouldn’t be a need for regulations! I am writing an article for Information Week on Malicious Compliance in Distress, which addresses companies doing the bare minimum to become compliant, instead of appropriately securing the data. If you use these regulations as a Minimum Security Baseline, you can always add additional layers of security to these regulations. For example… PCI just calls out not using WEP, but mentions the ability to use WPA and WPA2… however as security professionals we would consider WPA and WPA2 just as bad. So by PCI standards you can be compliant, however not any more secure than if you used WEP. Use the regulations to get a new stronger encryption protocol for your wireless environment.
Let’s not attack the regulations, but the reason why they were developed! View regulations as the minimum standard. If you took a comprehensive approach to security you would comply to all the regulations anyways (ISO 27001 & 27002). So instead of bitching out regulations… use them to get funding and do the right thing :-)
Read more!
At DefCon 16 I had the opportunity to meet some really interesting people who had different perspectives on security. However, for the first time in DefCon history (to my knowledge) “Compliance” standards opened the conference Friday morning. I was so excited to hear what the “hackers” thought about PCI, GLBA, HIPAA etc. To my disappointment, the presenter ranted about how compliance doesn’t equal security… DUH! But what they do is provide some value and the value is called “doing something!” Hell, most companies (97%) won’t do anything at all until they are forced!
Even with these standards, millions of records are still being compromised. Let’s rant about companies losing our data, not about how bad the regulations are. Let’s face it, if companies were doing what they should, there wouldn’t be a need for regulations! I am writing an article for Information Week on Malicious Compliance in Distress, which addresses companies doing the bare minimum to become compliant, instead of appropriately securing the data. If you use these regulations as a Minimum Security Baseline, you can always add additional layers of security to these regulations. For example… PCI just calls out not using WEP, but mentions the ability to use WPA and WPA2… however as security professionals we would consider WPA and WPA2 just as bad. So by PCI standards you can be compliant, however not any more secure than if you used WEP. Use the regulations to get a new stronger encryption protocol for your wireless environment.
Let’s not attack the regulations, but the reason why they were developed! View regulations as the minimum standard. If you took a comprehensive approach to security you would comply to all the regulations anyways (ISO 27001 & 27002). So instead of bitching out regulations… use them to get funding and do the right thing :-)
Read more!
Monday, August 18, 2008
Undercover at Defcon
After having attended yet another Defcon, I find myself a little frustrated. While I am a geek at heart, I am not a Linux chugging, code puking, trench coat wearing, hair dying, multi-pierced hardcore guy like many. But then again, I am not alone. Though many like to think it’s still ‘underground’, it really hasn’t been for quite a while. Security isn’t just an IT thing any more and its gaining ground in the business world. Hence there are many security professionals and vendor in attendance. So this year, I specifically set out to find that business side of security. As to being undercover, no I would not be a winner in the ‘spot the fed’ contest. I am just a security auditor that was hoping to hang out with my coworkers, learn a few things, and do a little networking.
Now I have to preface my story with some important information. Every night typically ended with the sun rising, my buzz fading, and my alarm looming just a few hours away. So perhaps I was a little tired, hung over and grumpy going into each morning – though I’m generally grumpy according to most anyway :) Still, I made my way to the conference, grabbed my new-fangled badge, and hit my first presentation. The abstract was very promising as the presenter alluded to the fact that compliance != (does not equal) security. Certainly he had a strong starting point. But, he tripped coming out of the blocks. The rest of the presentation turned into an angry IT guy condemning every standard, every certification, and pointing out how stupid and useless auditors are.
Now I’ll be the first to say there are many auditors working in areas they should not be. I think we’ve all had to deal with the Big X auditor/kid straight out of college that can’t seem to discuss anything outside the verbiage in his checklist. But it’s just as annoying to have someone unqualified lecturing about compliance. It does not make any sense to compare strength of compliance based on the length of the standard. Nor should you compare an IT standard against a security standard. And you shouldn’t even bring up standards that you don’t even know what the letters stand for. Again, I’ll be glad to raise my hands and tell you all the flaws with all the standards like my recent post on PCI. But I have at least had to actually work with those frameworks. I suppose it’s just a different view when you are subject to them.
During the rest of my Defcon experience, it was also peppered with more compliance bigotry, even from the likes of professors. But that’s not to say there weren’t some great ones too. One was on a new tool to find and perhaps exploit ModBusTCP devices on SCADA systems. That certainly piqued my interest with all the NERC CIP compliance work we are doing. There were a couple different presentations that covered different problems with RFID including devices that go beyond just cloning prox cards but also doing site codes brute force attacks on common card codes. I think the best presentation was ours – only because I got see out head geek get pummeled with lemons for his sins against humanity. Don’t ask :) After all, what happens in Vegas...
Read more!
Now I have to preface my story with some important information. Every night typically ended with the sun rising, my buzz fading, and my alarm looming just a few hours away. So perhaps I was a little tired, hung over and grumpy going into each morning – though I’m generally grumpy according to most anyway :) Still, I made my way to the conference, grabbed my new-fangled badge, and hit my first presentation. The abstract was very promising as the presenter alluded to the fact that compliance != (does not equal) security. Certainly he had a strong starting point. But, he tripped coming out of the blocks. The rest of the presentation turned into an angry IT guy condemning every standard, every certification, and pointing out how stupid and useless auditors are.
Now I’ll be the first to say there are many auditors working in areas they should not be. I think we’ve all had to deal with the Big X auditor/kid straight out of college that can’t seem to discuss anything outside the verbiage in his checklist. But it’s just as annoying to have someone unqualified lecturing about compliance. It does not make any sense to compare strength of compliance based on the length of the standard. Nor should you compare an IT standard against a security standard. And you shouldn’t even bring up standards that you don’t even know what the letters stand for. Again, I’ll be glad to raise my hands and tell you all the flaws with all the standards like my recent post on PCI. But I have at least had to actually work with those frameworks. I suppose it’s just a different view when you are subject to them.
During the rest of my Defcon experience, it was also peppered with more compliance bigotry, even from the likes of professors. But that’s not to say there weren’t some great ones too. One was on a new tool to find and perhaps exploit ModBusTCP devices on SCADA systems. That certainly piqued my interest with all the NERC CIP compliance work we are doing. There were a couple different presentations that covered different problems with RFID including devices that go beyond just cloning prox cards but also doing site codes brute force attacks on common card codes. I think the best presentation was ours – only because I got see out head geek get pummeled with lemons for his sins against humanity. Don’t ask :) After all, what happens in Vegas...
Read more!
Tuesday, July 22, 2008
PCI Compliance: Close but no cigar.
PCI Compliance is on almost everyone's mind and it will continue to grow in popularity as time progresses. Before I start, this is by no means a rant or flaming of the PCI DSS 1.1 standard, in fact, to date the PCI DSS is the most technical security framework really out there to date. There are a lot of positives toward the standard; however it has many shortcomings. I'm not going to list every one, but focus on some of the most pressing issues that we've seen as penetration testers and where the standard really is failing.
First, let’s start with: the standard should never be fully relied upon for organizations overall security posture. A matured security organization typically pulls from many standards like the ISO 27001/27002, NSA IAM, NIST, PCI, etc. One thing that this standard has really pulled through was a start to security in organizations and a start for security to be taken seriously. Generally, banks were the forefront for protecting data due to the sensitive nature of information, and most other organizations security fell in the wind and has since begun to shift in a different direction.
As a penetration tester, and running a team of gifted hackers, we get to see every environment and configuration known to man. Due to PCI's 11.3 "Performing penetration testing at least one a year", we do a variety of penetration testing assessments against PCI Compliant organizations. One of the most alarming statistics is our 63 percent success rate for breaching systems in PCI Compliant organizations. By breaching systems, we're talking about full access to the underlying operating system and potential to further penetrate into the network. The 63 percent doesn't even include access to the back-end databases, login bypasses, and various other issues we find during a pentest.
PCI's 1.1 states in 6.5 to use the OWASP guidelines for securing their systems. PCI 1.1 uses the OWASP 2004 framework for vulnerabilities, which is missing the good ol' malicious file execution amongst others. In addition to this, the ASV scans that need to be performed only check for XSS and SQL Injection. Vulnerability scanners, in general, are pretty rudimentary and basic in vulnerability identification, but only detecting two of the overall top ten is a major issue. In 6.6 a code review or WAF has to be in place, which should hopefully stop SOME of these attacks, but the alarming issue here is we've done successful penetration tests against sites that have undergone a code review, or have a WAF in place and do minor protection against attacks.
WAF are great (if properly configured), don't get me wrong, but they should not be the only layer of defense. Creating a security systems development life-cycle (SSDLC) from the beginning of development and through development and establishing code freezes for security testing before going into production is vital and the preferred method. Web applications have been getting a bum rap and are the major points of entry for external breaches to date. The standard simply states "Installing an application-layer firewall in front of web-facing applications", it does not state anything about allowing exceptions for functionality of the site (and introducing exposures) or hardening techniques. Again, the purpose of the standard was not to secure your systems for you, but at least give you a framework for organizations to implement security.
My next question on the DSS standard is who performs the code reviews looking for these common vulnerabilities? Most VARs have a penetration testing wing, generally consisting of two people that implement product and do penetration testing as a side job (oh and hey, if you buy this product it'll fix your vulnerabilities). These guys generally use tools that don't even touch the web application layer in depth and give false satisfactions and assurance to organizations. There’s no certification process for web applications assessors, it only states "an organization that specializes in application security", if I have Nessus does that make me a specialist in web application security? If I have AppScan, WebInspect, Ounce, Fortify, or any of the others in there, does running a tool make me a specialist?
My last main issue covers the ASV guidelines, quoted directly from the ASV scanning standard:
"Merchants and service providers have the ultimate responsibility for defining the scope of their PCI Security Scan, though they may seek expertise from ASVs for help. If an account data compromise occurs via an IP address or component not included in the scan, the merchant or service provider is responsible. "
We've run into many scenarios where organizations are using this loophole to take systems out of scope for the PCI assessment. While the organization is "responsible" if it becomes compromised, generally the companies we're seeing this as a way to pass the test without ever having any of the security restrictions on the system in place. So as per this statement, a main e-commerce site handling all credit card transactions for the organization can be taken out of scope by the merchant or service provider if they choose. At this point, what is the point in becoming compliant at all? Why study hard for a “C” when you can get an “A” every time without ever studying? “Sure if you get caught cheating its bad, but what’s the payoff, we're never going to get breached!”
To finalize the point I was trying to get out here is organizations are really using this to become "secure", when that really isn't the impact intended. In order for organizations to incorporate security, it has to be a widespread adoption within the organization, pull multiple frameworks and standards, and incorporate them into a regularly tested and updated programs. Relying solely on of PCI compliance and going through the checklist is not going to protect you from a breach by any means.
Read more!
First, let’s start with: the standard should never be fully relied upon for organizations overall security posture. A matured security organization typically pulls from many standards like the ISO 27001/27002, NSA IAM, NIST, PCI, etc. One thing that this standard has really pulled through was a start to security in organizations and a start for security to be taken seriously. Generally, banks were the forefront for protecting data due to the sensitive nature of information, and most other organizations security fell in the wind and has since begun to shift in a different direction.
As a penetration tester, and running a team of gifted hackers, we get to see every environment and configuration known to man. Due to PCI's 11.3 "Performing penetration testing at least one a year", we do a variety of penetration testing assessments against PCI Compliant organizations. One of the most alarming statistics is our 63 percent success rate for breaching systems in PCI Compliant organizations. By breaching systems, we're talking about full access to the underlying operating system and potential to further penetrate into the network. The 63 percent doesn't even include access to the back-end databases, login bypasses, and various other issues we find during a pentest.
PCI's 1.1 states in 6.5 to use the OWASP guidelines for securing their systems. PCI 1.1 uses the OWASP 2004 framework for vulnerabilities, which is missing the good ol' malicious file execution amongst others. In addition to this, the ASV scans that need to be performed only check for XSS and SQL Injection. Vulnerability scanners, in general, are pretty rudimentary and basic in vulnerability identification, but only detecting two of the overall top ten is a major issue. In 6.6 a code review or WAF has to be in place, which should hopefully stop SOME of these attacks, but the alarming issue here is we've done successful penetration tests against sites that have undergone a code review, or have a WAF in place and do minor protection against attacks.
WAF are great (if properly configured), don't get me wrong, but they should not be the only layer of defense. Creating a security systems development life-cycle (SSDLC) from the beginning of development and through development and establishing code freezes for security testing before going into production is vital and the preferred method. Web applications have been getting a bum rap and are the major points of entry for external breaches to date. The standard simply states "Installing an application-layer firewall in front of web-facing applications", it does not state anything about allowing exceptions for functionality of the site (and introducing exposures) or hardening techniques. Again, the purpose of the standard was not to secure your systems for you, but at least give you a framework for organizations to implement security.
My next question on the DSS standard is who performs the code reviews looking for these common vulnerabilities? Most VARs have a penetration testing wing, generally consisting of two people that implement product and do penetration testing as a side job (oh and hey, if you buy this product it'll fix your vulnerabilities). These guys generally use tools that don't even touch the web application layer in depth and give false satisfactions and assurance to organizations. There’s no certification process for web applications assessors, it only states "an organization that specializes in application security", if I have Nessus does that make me a specialist in web application security? If I have AppScan, WebInspect, Ounce, Fortify, or any of the others in there, does running a tool make me a specialist?
My last main issue covers the ASV guidelines, quoted directly from the ASV scanning standard:
"Merchants and service providers have the ultimate responsibility for defining the scope of their PCI Security Scan, though they may seek expertise from ASVs for help. If an account data compromise occurs via an IP address or component not included in the scan, the merchant or service provider is responsible. "
We've run into many scenarios where organizations are using this loophole to take systems out of scope for the PCI assessment. While the organization is "responsible" if it becomes compromised, generally the companies we're seeing this as a way to pass the test without ever having any of the security restrictions on the system in place. So as per this statement, a main e-commerce site handling all credit card transactions for the organization can be taken out of scope by the merchant or service provider if they choose. At this point, what is the point in becoming compliant at all? Why study hard for a “C” when you can get an “A” every time without ever studying? “Sure if you get caught cheating its bad, but what’s the payoff, we're never going to get breached!”
To finalize the point I was trying to get out here is organizations are really using this to become "secure", when that really isn't the impact intended. In order for organizations to incorporate security, it has to be a widespread adoption within the organization, pull multiple frameworks and standards, and incorporate them into a regularly tested and updated programs. Relying solely on of PCI compliance and going through the checklist is not going to protect you from a breach by any means.
Read more!
Subscribe to:
Posts (Atom)
Posts
