We have all heard the business adage that you cannot manage what you don’t measure. For those in Information Security or Information Technology, this can have far-reaching implications. Without concrete data to query and present, business unit leaders are left wanting. It is difficult to grasp the importance of security or its necessity if there is nothing to back it up. A sound Metrics Program can help.
Read more!
Thursday, October 14, 2010
Thursday, October 7, 2010
The Five-Step Compliance Shuffle
If you are in charge of IT and/or Security and you do not have that compliance and/or auditor twinkle in your eye, you might twinge each time someone says PCI, HIPAA, ISO, GLBA, SOX, or any other regulation or evil acronym that might be thrown your way. Depending on your environment and your experience with compliance, the hardest part is knowing what applies within your organization. If faced with an auditor, or even worse, a court room, you will have to show due diligence and due care. As they used to say at the end of every GI Joe cartoon: “Knowing is half the battle!” Due diligence is just that: knowing, researching, and understanding what regulations apply within your organization and how your organization complies with them. Due care is the act of implementation and remediation of issues found and showing that the proper controls are in place and are effective. Please note that this is a high level methodology to compliance. Additional assessment and expertise may be required depending on the size of the organization and what regulations were found to apply to the organization.
Read more!
Read more!
Thursday, September 16, 2010
Join The Community – Cleveland Security Groups
Say what you like about Cleveland. One thing you cannot debate is Cleveland has a very strong security community. This can clearly be seen in the number of security groups located in the area. In this blog post I simply provide a list of all the security groups I am aware of in the area. I encourage anyone who is interested in security to attend some of these meetings to learn and network with the security community.
Akron Canton ASIS – Local chapter of ASIS International serving the Akron/Canton area. Group primarily focuses on physical security. Meetings generally occur in the mornings over breakfast and cost $10 to $20. Meetings are not open to the public. If you are interested in attending, either join ASIS or contact me and we can discuss having you attend a meeting as my guest.
ASIS Cleveland - Cleveland Chapter of ASIS International. Like the Akron/Canton group, this one also focuses on physical security. Meetings occur over lunch and cost $15. Meetings are not open to the public. If you are interested in attending, either join ASIS or contact me and we can discuss having you attend a meeting as my guest.
Infragard Northern Ohio Chapter - Infragard is an organization sponsored by the FBI that focuses on protecting critical infrastructure. Meetings are free and often occur in the morning. Meetings that are open to the public are held once a quarter. A number of members-only meetings are also held during the year.
Northeast Ohio Information Security Forum - The NEO InfoSec Forum is an independent security group mainly focusing on technical computer security topics. Meetings occur in the evening on the third Wednesday of the month. Meetings are free and open to the public. A free dinner, usually pizza, is provided.
Northeastern Ohio ISACA – Local chapter of ISACA. Their meetings are generally geared toward auditors and are held every month during the day.
Northeastern Ohio ISSA – Local chapter of the Information Systems Security Association (ISSA). Meetings generally occur monthly and focus on a range of information security topics. A number of years ago this chapter of ISSA went dormant. However, the local chapter is now under new leadership and they have been very focused on rebuilding the chapter. If you have not been to a meeting in a few years I recommend checking them out under the new leadership.
Ohio Chapter of the HTCIA - Ohio Chapter of High Technology Crime Investigation Association (HTCIA). This group mainly focuses on computer forensics and investigations.
OWASP Cleveland - Local chapter of the Open Web Application Security Project (OWASP). This group focuses on web application security. Meetings are held quarterly at noon and usually include a free lunch. This is a great meeting to invite your company’s developers to so they can learn about secure coding practices. The Cleveland Chapter of OWASP is also sponsored by SecureState.
Did I miss any? If I did, mention them in the comments.
Read more!
Akron Canton ASIS – Local chapter of ASIS International serving the Akron/Canton area. Group primarily focuses on physical security. Meetings generally occur in the mornings over breakfast and cost $10 to $20. Meetings are not open to the public. If you are interested in attending, either join ASIS or contact me and we can discuss having you attend a meeting as my guest.
ASIS Cleveland - Cleveland Chapter of ASIS International. Like the Akron/Canton group, this one also focuses on physical security. Meetings occur over lunch and cost $15. Meetings are not open to the public. If you are interested in attending, either join ASIS or contact me and we can discuss having you attend a meeting as my guest.
Infragard Northern Ohio Chapter - Infragard is an organization sponsored by the FBI that focuses on protecting critical infrastructure. Meetings are free and often occur in the morning. Meetings that are open to the public are held once a quarter. A number of members-only meetings are also held during the year.
Northeast Ohio Information Security Forum - The NEO InfoSec Forum is an independent security group mainly focusing on technical computer security topics. Meetings occur in the evening on the third Wednesday of the month. Meetings are free and open to the public. A free dinner, usually pizza, is provided.
Northeastern Ohio ISACA – Local chapter of ISACA. Their meetings are generally geared toward auditors and are held every month during the day.
Northeastern Ohio ISSA – Local chapter of the Information Systems Security Association (ISSA). Meetings generally occur monthly and focus on a range of information security topics. A number of years ago this chapter of ISSA went dormant. However, the local chapter is now under new leadership and they have been very focused on rebuilding the chapter. If you have not been to a meeting in a few years I recommend checking them out under the new leadership.
Ohio Chapter of the HTCIA - Ohio Chapter of High Technology Crime Investigation Association (HTCIA). This group mainly focuses on computer forensics and investigations.
OWASP Cleveland - Local chapter of the Open Web Application Security Project (OWASP). This group focuses on web application security. Meetings are held quarterly at noon and usually include a free lunch. This is a great meeting to invite your company’s developers to so they can learn about secure coding practices. The Cleveland Chapter of OWASP is also sponsored by SecureState.
Did I miss any? If I did, mention them in the comments.
Read more!
Thursday, September 9, 2010
SSL Wars: The Return Of The SSLi
The content of my last few posts has looked at SSL implementations and vulnerabilities. Today’s post is no different, as I will be discussing the importance of patching vulnerabilities in specific implementations of SSL. I have always found it ironic when vulnerabilities are discovered in technologies which have the sole purpose of providing security. As of late a couple of interesting SSL vulnerabilities have surfaced which caught my attention. The CVE IDs of the two vulnerabilities I will briefly discuss are CVE-2010-2566 and CVE-2009-2510.
CVE-2010-2566 is a vulnerability found in Microsoft’s Schannel.dll. Per Microsoft’s Security Bulletin Schannel (Secure Channel) is “a Security Support Provider (SSP) that implements the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) Internet standard authentication protocols”. The Schannel vulnerability is a heap based corruption which is the result of “the code that validates client certificate requests sent by the server.” If successfully exploited this vulnerability could lead to remote code execution on the victim’s machines (http://blogs.technet.com/b/srd/archive/2010/08/10/ms10-049-a-remote-code-execution-vulnerability-in-schannel-cve-2010-2566.aspx). In order to exploit this vulnerability, an attacker would need to cause the victim to visit a webpage where the attacker has set up a malicious web server. This vulnerability has been addressed in Microsoft Security Bulletin MS10-049.
We can learn two very important lessons from a vulnerability like this. The first lesson we can learn from this vulnerability is that it is important to apply critical patches as soon as possible. New vulnerabilities are always being discovered and it is critical the patches which remediate these vulnerabilities are applied as soon as possible. The second lesson we can learn from this vulnerability is the fact that there is always a danger when visiting any web site which you do not directly control. Sites which appear shady or have a large number of ads and pop-ups are especially dangerous, but even legitimate sites can be compromised and forced to serve malware to unsuspecting guests. The New York Times fell victim to an attack in which people visiting their website were greeted with a pop-up telling the unsuspecting victim that their machine was infected with Malware and that they should download fake antivirus. Although attacks originating from otherwise reputable websites are not extremely common, it is important to note these kinds of attacks have been found in the wild.
Suppose an attacker were the first one to identify and develop a working exploit for CVE-2010-2566. The attacker could set up a fake website and find ways to entice people into visiting these websites. Upon simply visiting the site, the attacker would have control over the victim’s machine. The scary thought is we are really unsure how many zero days are in the wild. These web servers may be waiting for someone to connect and take control of the victim’s machine.
The second vulnerability I will discuss is CVE-2009-2510. An attack known as the “NULL Prefix Attack” exploits this vulnerability in order to trick a client into connecting to a spoofed site. This vulnerability was first discovered by Moxie Marlinspike and is easily exploitable through his SSLSniff tool (http://www.thoughtcrime.org/software/sslsniff/). This vulnerability exists because of the way most SSL implementations treat the fields in the certificates used by the SSL implementations.
SSL uses certificates which are based on the X.509 standard. X.509 certificates are formatted using ASN.1 notation. All string types in this notation are essentially some variation of PASCAL strings. PASCAL strings are stored in memory as a series of bytes. The length of the string is stored in memory followed by the bytes of the actual string data. Therefore the PASCAL string “hello” would be stored in memory as follows “0x060x680x650x6C0x6C0x6F”. This string would be read as follows:
0x06 = The next six bytes are part of this string
0x68 = h
0x65 = e
0x6C = l
0x6C = l
0x6F = o
This vulnerability is the result of the fact that most SSL implementations treat the X.509 fields as C strings instead of PASCAL strings. These SSL implementations use string parsing functions which treat the X.509 fields as C strings. Unlike PASCAL strings C strings are stored in memory as a series of bytes which indicate the end of the string through a NULL character. The C string “hello” would be stored in memory as follows “0x680x650x6C0x6C0x6F0x00”. This string would be read as follows:
0x68 = h
0x65 = e
0x6C = l
0x6C = l
0x6F = o
0x00 = Null character indicating the end of the string.
Because of the differences in the way strings are stored in memory between C and PASCAL a very interesting exploit which uses this vulnerability has been developed. Suppose I own the domain evilhacker.com. Since I own evilhacker.com I can obtain certificates for this domain signed by a trusted signing authority like VeriSign. Since I own this domain I can also own valid certificates for any sub domain of evilhacker.com like awesome.evilhacker.com, incredible.evilhacker.com or even www.paypal.com\0.evilhacker.com (\0 is the literal constant for the NULL character). Since X.509 fields are formatted with ASN.1 notation, having a NULL character in the Common Name is not a problem. The problem occurs when the web browser treats the Common Name as a C string and tries reading the Common Name field. The web browser would read the certificate’s Common Name all the way up to “\0”; because of this the browser would see the Common Name in the attacker’s certificate as www.paypal.com. The common name is identical to the domain name of the website and the browser will connect to the attacker without giving any error messages to the victim. I will try to give the NULL prefix attack greater context by showing an example of how it can be utilized.
I am an evil hacker who goes by the hacker handle “Cain” and I own the domain evilhacker.com. I decide I would like to use the NULL Prefix Attack to steal victim’s PayPal credentials. I download SSLSniff and have a certificate created for www.paypal.com\0.evilhacker.com. I have the certificate for www.paypal.com\0.evilhacker.com signed by VeriSign and head over to my favorite coffee house in the galaxy . . .Mos Eisley Cantina (Yes. . .In my world they serve coffee here as well). The coffee house has free public Wi-Fi and within minutes I am Man in the Middling the entire coffee house’s traffic. I passively monitor and forward customer traffic waiting for someone to go to www.paypal.com. A man in the coffee house named Belinda is browsing a scented candle website when he finds a cinnamon macadamia chocolate scented candle that he cannot live without. Belinda goes to www.paypal.com to make sure his account information is up to date before making his $5000 candle purchase. Belinda enters “www.paypal.com” in his browser and presses “ENTER”. SSLStrip intercepts the request to PayPal and presents the victim’s web browser with its own certificate of www.paypal.com\0.evilhacker.com. The browser checks the certificate to see if the certificate’s Common Name (www.paypal.com\0.evilhacker.com) is actually the name of the site Belinda typed into his browser (www.paypal.com). Belinda’s browser starts to read the certificate’s Common Name until it reaches the NULL character, at which point the browser believes it has reaches the end of the Common Name. The browser believes my certificate’s Common Name is www.paypal.com, it verifies the certificate has not expired, and it verifies the certificate was signed by a trusted certificate authority (In this case VeriSign). Belinda’s browser creates a secure connection with Cain’s machine believing it to be www.palpal.com. SSLStrip then establishes a secure connection with www.paypal.com. My machine acts as a secure proxy by encrypting all traffic between my machine and Belinda’s machine, decrypting the information on my machine, and forwarding the information over the secure tunnel already established with PayPal. Using this information I go out and buy a new computer with Belinda’s PayPal account.
The CVE-2009-2510 vulnerability teaches us two great lessons. First we can see once again the importance of patching. This vulnerability in the Microsoft CryptoAPI is addressed in Microsoft Security Bulletin MS09-056. Please note that other SSL implementations which are vulnerable to this attack may have a different CVE ID and will require a different patch. The second lesson we can learn from this vulnerability is that there are additional risks associated with connections made over a possible hostile network (Like coffee houses, airports, TOR tunnels, etc). The NULL Prefix Attack could easily be implemented before patches to remediate this vulnerability were available. In addition to the NULL Prefix attack, attackers may implement attacks based on the SSLStrip tool (Addressed in my previous blog), generate self signed certificates pretending to be legitimate sites (Addressed in a different blog), or implement a number of other attacks which are associated Man in the Middle scenarios. There should always be a level of caution when connecting to an un-trusted network.
By Gary McCully, Information Security Staff Consultant
Read more!
CVE-2010-2566 is a vulnerability found in Microsoft’s Schannel.dll. Per Microsoft’s Security Bulletin Schannel (Secure Channel) is “a Security Support Provider (SSP) that implements the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) Internet standard authentication protocols”. The Schannel vulnerability is a heap based corruption which is the result of “the code that validates client certificate requests sent by the server.” If successfully exploited this vulnerability could lead to remote code execution on the victim’s machines (http://blogs.technet.com/b/srd/archive/2010/08/10/ms10-049-a-remote-code-execution-vulnerability-in-schannel-cve-2010-2566.aspx). In order to exploit this vulnerability, an attacker would need to cause the victim to visit a webpage where the attacker has set up a malicious web server. This vulnerability has been addressed in Microsoft Security Bulletin MS10-049.
We can learn two very important lessons from a vulnerability like this. The first lesson we can learn from this vulnerability is that it is important to apply critical patches as soon as possible. New vulnerabilities are always being discovered and it is critical the patches which remediate these vulnerabilities are applied as soon as possible. The second lesson we can learn from this vulnerability is the fact that there is always a danger when visiting any web site which you do not directly control. Sites which appear shady or have a large number of ads and pop-ups are especially dangerous, but even legitimate sites can be compromised and forced to serve malware to unsuspecting guests. The New York Times fell victim to an attack in which people visiting their website were greeted with a pop-up telling the unsuspecting victim that their machine was infected with Malware and that they should download fake antivirus. Although attacks originating from otherwise reputable websites are not extremely common, it is important to note these kinds of attacks have been found in the wild.
Suppose an attacker were the first one to identify and develop a working exploit for CVE-2010-2566. The attacker could set up a fake website and find ways to entice people into visiting these websites. Upon simply visiting the site, the attacker would have control over the victim’s machine. The scary thought is we are really unsure how many zero days are in the wild. These web servers may be waiting for someone to connect and take control of the victim’s machine.
The second vulnerability I will discuss is CVE-2009-2510. An attack known as the “NULL Prefix Attack” exploits this vulnerability in order to trick a client into connecting to a spoofed site. This vulnerability was first discovered by Moxie Marlinspike and is easily exploitable through his SSLSniff tool (http://www.thoughtcrime.org/software/sslsniff/). This vulnerability exists because of the way most SSL implementations treat the fields in the certificates used by the SSL implementations.
SSL uses certificates which are based on the X.509 standard. X.509 certificates are formatted using ASN.1 notation. All string types in this notation are essentially some variation of PASCAL strings. PASCAL strings are stored in memory as a series of bytes. The length of the string is stored in memory followed by the bytes of the actual string data. Therefore the PASCAL string “hello” would be stored in memory as follows “0x060x680x650x6C0x6C0x6F”. This string would be read as follows:
0x06 = The next six bytes are part of this string
0x68 = h
0x65 = e
0x6C = l
0x6C = l
0x6F = o
This vulnerability is the result of the fact that most SSL implementations treat the X.509 fields as C strings instead of PASCAL strings. These SSL implementations use string parsing functions which treat the X.509 fields as C strings. Unlike PASCAL strings C strings are stored in memory as a series of bytes which indicate the end of the string through a NULL character. The C string “hello” would be stored in memory as follows “0x680x650x6C0x6C0x6F0x00”. This string would be read as follows:
0x68 = h
0x65 = e
0x6C = l
0x6C = l
0x6F = o
0x00 = Null character indicating the end of the string.
Because of the differences in the way strings are stored in memory between C and PASCAL a very interesting exploit which uses this vulnerability has been developed. Suppose I own the domain evilhacker.com. Since I own evilhacker.com I can obtain certificates for this domain signed by a trusted signing authority like VeriSign. Since I own this domain I can also own valid certificates for any sub domain of evilhacker.com like awesome.evilhacker.com, incredible.evilhacker.com or even www.paypal.com\0.evilhacker.com (\0 is the literal constant for the NULL character). Since X.509 fields are formatted with ASN.1 notation, having a NULL character in the Common Name is not a problem. The problem occurs when the web browser treats the Common Name as a C string and tries reading the Common Name field. The web browser would read the certificate’s Common Name all the way up to “\0”; because of this the browser would see the Common Name in the attacker’s certificate as www.paypal.com. The common name is identical to the domain name of the website and the browser will connect to the attacker without giving any error messages to the victim. I will try to give the NULL prefix attack greater context by showing an example of how it can be utilized.
I am an evil hacker who goes by the hacker handle “Cain” and I own the domain evilhacker.com. I decide I would like to use the NULL Prefix Attack to steal victim’s PayPal credentials. I download SSLSniff and have a certificate created for www.paypal.com\0.evilhacker.com. I have the certificate for www.paypal.com\0.evilhacker.com signed by VeriSign and head over to my favorite coffee house in the galaxy . . .Mos Eisley Cantina (Yes. . .In my world they serve coffee here as well). The coffee house has free public Wi-Fi and within minutes I am Man in the Middling the entire coffee house’s traffic. I passively monitor and forward customer traffic waiting for someone to go to www.paypal.com. A man in the coffee house named Belinda is browsing a scented candle website when he finds a cinnamon macadamia chocolate scented candle that he cannot live without. Belinda goes to www.paypal.com to make sure his account information is up to date before making his $5000 candle purchase. Belinda enters “www.paypal.com” in his browser and presses “ENTER”. SSLStrip intercepts the request to PayPal and presents the victim’s web browser with its own certificate of www.paypal.com\0.evilhacker.com. The browser checks the certificate to see if the certificate’s Common Name (www.paypal.com\0.evilhacker.com) is actually the name of the site Belinda typed into his browser (www.paypal.com). Belinda’s browser starts to read the certificate’s Common Name until it reaches the NULL character, at which point the browser believes it has reaches the end of the Common Name. The browser believes my certificate’s Common Name is www.paypal.com, it verifies the certificate has not expired, and it verifies the certificate was signed by a trusted certificate authority (In this case VeriSign). Belinda’s browser creates a secure connection with Cain’s machine believing it to be www.palpal.com. SSLStrip then establishes a secure connection with www.paypal.com. My machine acts as a secure proxy by encrypting all traffic between my machine and Belinda’s machine, decrypting the information on my machine, and forwarding the information over the secure tunnel already established with PayPal. Using this information I go out and buy a new computer with Belinda’s PayPal account.
The CVE-2009-2510 vulnerability teaches us two great lessons. First we can see once again the importance of patching. This vulnerability in the Microsoft CryptoAPI is addressed in Microsoft Security Bulletin MS09-056. Please note that other SSL implementations which are vulnerable to this attack may have a different CVE ID and will require a different patch. The second lesson we can learn from this vulnerability is that there are additional risks associated with connections made over a possible hostile network (Like coffee houses, airports, TOR tunnels, etc). The NULL Prefix Attack could easily be implemented before patches to remediate this vulnerability were available. In addition to the NULL Prefix attack, attackers may implement attacks based on the SSLStrip tool (Addressed in my previous blog), generate self signed certificates pretending to be legitimate sites (Addressed in a different blog), or implement a number of other attacks which are associated Man in the Middle scenarios. There should always be a level of caution when connecting to an un-trusted network.
By Gary McCully, Information Security Staff Consultant
Read more!
Tuesday, September 7, 2010
Information Security Policies and Procedures, Part 6
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!
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!
Friday, September 3, 2010
Getting OSSEC To Parse Auditd
“Everyone wants a log
You're gonna love it, log
Come on and get your log
Everyone needs a log
log log log” – Ren and Stimpy
Read more!
You're gonna love it, log
Come on and get your log
Everyone needs a log
log log log” – Ren and Stimpy
Read more!
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!
Subscribe to:
Posts (Atom)
Posts
