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!

SSL Wars: The SSL Strikes Back

In my last few posts I reviewed some of the SSL type vulnerabilities. These vulnerabilities were the result of SSL misconfigurations. Today I will address a client side SSL/TLS exploit.

How many people do you know who access secure websites by typing HTTPS://www.securesite.com in the address field of their browser? The vast majority of people just place the website name (www.securesite.com) in the address field of their browser and let the chips fall where they may. So I guess my question would be “How does the browser know whether to send me to a secure site (HTTPS) or send me to an insecure site (HTTP)”? Does the browser see www.securesite.com in the browser and flip a virtual coin to decide whether or not to direct me to an insecure (HTTP) or secure (HTTPS) connection? Does the browser read www.securesite.com and think to itself “I bet that site should be established over a secure connection today,” or does the computer just use magic to decide whether to establish a secure connection or not?

I will now attempt to explain the great mystery and technical awe and wonder of how the browser determines whether to establish a secure or insecure connection... Ready... Here goes: If the type of connection is not specified in the address field of the browser (HTTP or HTTPS), then the connection defaults to being established over HTTP. In other words, if I type www.securesite.com into my browser, the browser will default to HTTP://www.securesite.com. *Whew, That was tough to explain.* So the question is how do I end up using a secure connection (HTTPS) if the browser defaults to a non-secure connection (HTTP)?

In all reality most people only encounter HTTPS through HTTP. In other words, people are directed to secure connections through insecure connections. Secure connections (HTTPS) are generally established through redirects or links.

Let’s discuss how HTTPS is encountered through redirects. Suppose I am the owner of a company which sells bobsleds to people who live in the Sahara desert (I just fired the head of marketing). I set up a website named www.hotsledsforhotclimates.com. In order to purchase a sled we require people to provide SSN, Checking Account Number, and three different credit cards using our website. I have a doctorate degree in quantum cryptography so I know that sending all this sensitive information over an insecure connection like HTTP is not a good idea. I decide that if someone tries to access my webpage through HTTP that they should probably be redirected to a secure connection (HTTPS). “Franz” (A desert dwelling hermit from the Sahara desert) decides he wants to purchase a bobsled in case it snows. Franz has heard that the site www.hotsledsforhotclimates.com has the type of bobsleds he is looking to purchase. Bob opens his browser and types www.hotsledsforhotclimates.com into the address field of his browser. The browser sends the request to HTTP://www.hotsledsforhotclimates.com. The request is sent to my website which promptly tells Franz’s browser that it must use HTTPS to connect to www.hotsledsforhotclimates.com. The web browser is redirected to HTTPS://www.hotsledsforhotclimates.com. Franz purchases his bobsled and the world is right again.

The second way that people generally encounter HTTPS is through links. Suppose that a site is dedicated to the hottest companies who sell bobsleds to people who live in the Sahara desert. Nothing on the website is confidential so the site does not require a secure connection (Everything is sent through HTTP). The site has links which redirects people who wish to purchase one of these bobsleds to hot sleds for hot climates. The link which points to hot sleds for hot climates is HTTPS:// www.hotsledsforhotclimates.com. Franz (Our beloved hermit) is reviewing the site dedicated to the hottest companies who sell bobsleds to people who live in the Sahara desert and decides that he must purchase a bobsled from one of these companies. In a moment of weakness Franz decides to use his children’s college fund to purchase a bobsled (The sleds are very expensive). He selects the link for HTTPS:// www.hotsledsforhotclimates.com and is quickly sent to a secure site where he can purchase the bobsled of his dreams. Franz purchases his bobsled and everyone is happy (except for his poor kids who will now be forced to attend a small community college).

So to reiterate, people encounter HTTPS through HTTP (More specifically, redirects and links). So what is stopping attackers from intercepting all links and redirects which tell the browser to use HTTPS and replace them with links which point to HTTP? Why can’t attackers place themselves between the customer (Franz) and the web site www.hotsledsforhotclimates.com and modify all redirects and links destined for HTTPS and replace them with links to HTTP? What would stop an attacker from setting up an insecure connection with the customer and a secure connection with the website and act as a middleman between them? The answer to these questions is: essentially nothing! In fact, a tool named SSLStrip performs this type of attack with minimal effort.

SSLStrip works as follows. An attacker performs a man in the middle attack to place themselves between the client and the server. Whenever SSLStrip sees links or redirects which try to send the customer to a secure connection (HTTPS), it replaces the links with insecure versions of these links (HTTP). SSLStrip sets up a secure connection with the site HTTPS:// www.hotsledsforhotclimates.com and an insecure connection with the customer HTTP:// www.hotsledsforhotclimates.com.SSLStrip even places a padlock favicon in the corner of the customer’s browser to make them think they are connected over a secure connection. The attacker takes the information sent from the customer (Username, Password, SSN, Credit Cards) and logs them to a file for future review. The attacker then uses their secure connection with the server to forward this information to the web server.

So what should you do in order to prevent falling prey to this attack? First, if you type www.securewebsite.com into your web browser or access a link which redirects to a site requesting sensitive information (Username, Password, SSN, Credit Card, etc), manually verify you are redirected to a secure connection HTTPS://www.securewebsite.com. This can be accomplished by looking at the web address listed in the browser and verifying the address starts with HTTPS. Although this safeguard may make it more difficult for an attacker to exploit this vulnerability, a dedicated attacker using an advanced Homograph attack may still be able to successfully exploit this vulnerability. Second, you can manually type HTTPS:// before the website you are trying to access. This will verify the connection is immediately connected through HTTPS and is never sent through HTTP redirects. Once you access the site through manually placing HTTPS// before the site name, the site can be saved as a bookmark for quick access over SSL in the future.

-Gary McCully

Read more!

Information Security Policies and Procedures, Part 4

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 5 , Part 6


The formatting and structure of documentation may not seem like the most enthralling topic, and in many (most) ways it is not. It is however one of the most important elements of effective documentation. Delivering information in a clear and consistent way is essential to ensure documents are easy to use and effective. From your organization’s logo to the approval of the board, documentation should look, feel, and be official. Even fonts can make a difference. If you work for an organization large enough to have a style guide and/or documentation standards, much of the structure, format, look, fonts, etc. will be laid out for you. For those who are blazing the path, however, you must be prepared to make several decisions prior to developing documentation.

It is almost always easiest to design a template and determine style and formatting before putting the figurative pen to paper (hands to keyboard). (Truth be told, I cannot think of a single example where it would be better to develop documentation before developing a template, but I am doing my best not to speak in absolutes. If you have any examples to prove me wrong, please by all means share them in the comments or email me directly.)

Unfortunately, due to time and other constraints, I will not be going into great detail of the intricacies of creating and formatting templates and using styles. If you plan to have any lengthy involvement in document development, I highly recommend spending some time becoming comfortable with the advanced features of your word processing program of choice. While I think it is safe to say that many feel they are expert users of the Microsoft Office suite, there are many powerful features that many who consider themselves “power users” are unaware of. Get to know the styles, template features, and table structure. Time spent up front creating a bullet proof and consistent template and related style rules will pay immense dividends in saved time and effort down the road.

As our focus in this series is policies and procedures, we will start there. In the header, at minimum include the title, revision number, effective date, and your organization’s logo. The reason for the title should be fairly clear. Including your logo will make the document immediately identifiable as belonging to your organization. The effective date and revision data allow users to identify that they are using the correct version of the document.

In the footers, include copyright information as well as page numbers. Page numbers are important, especially with longer policies and procedures, to ensure that users know that they are looking at a complete policy and not just a page or two.

The footer is also a good place to include the document classification. As we discussed in earlier posts, some policies and procedures will be more sensitive than others. It is important to label documents so that users understand their proper handling. If you do not have an asset classification program, we strongly suggest you implement one as asset classification is one of the main building blocks of an effective information security program. Please feel free to contact SecureState’s Risk Management team for details.

Take care to have consistent header and footer designs across your organization’s documentation. I cannot reiterate enough the importance of consistency.

In our next installment, we will continue on formatting and structure and get into the details of what sections and basic information should be included in every policy and procedure.

Read more!

Hacking Your Location With Facebook Places

Facebook recently released a new feature called "Places" which aims to tap into the growing location based services market made popular by other social networks like FourSquare and Gowalla. Facebook Places allows you to "check-in" to a location with your mobile device. You can check-in with the official Facebook application for the iPhone or Android or you can use the Facebook mobile site: touch.facebook.com. You can use touch.facebook.com if you have a location aware web browser such as Firefox, Opera or Chrome. In this post we will explore what Facebook Places is, how businesses are going to use it, the privacy and security concerns, and how one can fake a location check-in with a few easy steps.

Read more!

The Importance of Validation

A vulnerability assessment is an important element in understanding a company’s threat profile. When performing a vulnerability assessment, it should include more than just running a scan, printing a pretty report and sending it out to a client, management, or administrator. It must also be about confidence and accuracy. What makes you confident in the report you send to a client, your management, or administrator? What makes YOUR report more accurate than others? Validation. What is validation? Validation is testing a vulnerability that has been found. Depending on how far you dive into validation, it can contain many elements of a penetration test. What makes validation most important is identification of false positives. Every vulnerability scanner, no matter how many bells and whistles it has, will produce false positives. There is no scanner on the market that can find every vulnerability and not produce false positives.

Read more!

The DDoS Threat: The New Punctuated Equilibrium

On August 7, 2010, DNS Made Easy underwent an outage that was caused by a Distributed Denial of Service (DDoS) attack. While the outage for many companies was sporadic, it lasted for multiple hours in regions of the west coast of the United States. Over the course of the past eight years, DNS Made Easy has prided themselves on their 100% uptime. A blow like this can affect a company’s public image, hinder their marketing, shift their business strategy, and impact their bottom line. So, how did this happen? Is it preventable? And, what can you do about it? In this situation, it is easy to blame DNS Made Easy and say that they didn’t have the proper security controls in place to withstand this type of attack, but in reality things are not that simple.

Read more!

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!