Friday, September 30, 2011

How the RSA Breach May Have Been Prevented


To continue on the earlier entry regarding Advanced Persistent Threats, some interesting information has come out recently about the successful attack earlier this year on RSA, the Security Division of EMC.  Apparently, the massive data theft began with a relatively simple phishing email sent to an EMC employee.  The email contained an Excel spreadsheet that was booby-trapped with a malicious object, which then exploited a zero-day vulnerability in Adobe Flash to install a backdoor on the system.  

What can we learn from this?  Well, for one, it excuses RSA to some degree, since the zero-day flaw couldn’t have been patched at the time.  It also highlights, yet again, the importance of user training and a sound IT Security Policy.  What if this user had been trained on how to recognize a suspicious email?  Maybe the attack would have happened, if not from this user than from another, but maybe it wouldn't.  The attack used complex vectors, but was not in and of itself a complex attack.  As is often the case, training the staff on detecting phishing threats and thwarting social engineering attacks would have gone a long way toward mitigating this threat.  RSA isn't alone in this regard - users will continue to be the weak spot in any organization's security.

This entry was based on information found in the following, excellent articles:

If you don't yet have an IT Security Policy, or would like to update the one you do have, a great site to visit is InstantSecurityPolicy.com, which uses a wizard to customize security policies to your company's needs.  A comprehensive policy, plus user training how to spot threats and use the Internet safely, will go along way in mitigating these inherent risks.

Tuesday, June 7, 2011

APTs: So What if you ARE a Target?

This blog post continues the discussion from last month, which examined Advanced Persistent Threats, or APTs.  You can find it here.

So if leading technology companies can't stop an APT, what chance do you have against defending against it?  The unfortunate answer is: not much.

An interesting article from DarkReading.com discusses what you should know about detecting a targeted attack, and goes over the methodology an attacker might use to probe a company for weaknesses.  Rightfully so, the article discusses the human vulnerabilities inherent to every company, saying: “Detecting attacks attempting to exploit human assets is often nearly impossible without regular training and awareness. You can't install Snort on your CEO and CFO.”  This is a great point – if your company is specifically targeted by an attacker and your network is secure, the attacker will naturally turn to social engineering, custom malware, or spear phishing in an attempt to gain a foothold.  Some tools can offer limited assistance here, but none surpass user awareness.

To that point, you should make an effort to check out the online tools that your users frequent - Facebook, Gmail, Craigslist, and LinkedIn for example.  These all have good resources that explain how to control privacy of information, as well as tips to avoid scams common to these applications.  These pages can typically be located within a few clicks and are well worth the effort to find.  Make it a point to compile and send these tips to your users on a regular basis.

Your users are, by far, your biggest security liability.  Instituting a sound security policy, coupled with user training, is a must.  Your security policy is your IT security playbook: user-oriented policies, and training about these policies, will act to "harden" your users just as you might harden your network perimeter.

If you don't already have a security policy, check out www.InstantSecurityPolicy.com, which can help you obtain a custom set of security policies in minutes.

Tuesday, May 24, 2011

With the Rise of APTs, Security Policies are More Important Than Ever

Recently, much has been made of a "new" attack known as the Advanced Persistent Threat (APT) due to recent attacks on RSA, Google, Adobe Systems, and others.  APTs are not new, but they can be by far the most damaging attack.  So what can you do to stop them?  First let's go over the basics:

Just What Exactly Is an Advanced Persistent Threat?


An APT is by far the most difficult type of attack to stop.  It combines multiple, sometimes zero-day, vulnerabilities, social engineering, spear phishing, and offline techniques into a long-term and carefully crafted attack.  There is an objective to these attacks – they are not smash-and-grab hits where attackers look for anything of value.  Anyone using an APT is after the “crown jewels” of a company: intellectual property, massive stores of customer or credit card data, classified information, product blueprints, source code, etc.  The attacks move laterally through a network, and can be difficult, if not impossible, to detect.  The attacker will have a long-term horizon, sometimes staying in a network for years, searching for its target. 

The good news, if there is any, is that these attacks are relatively rare.  Due to their complexity and cost, targets of APTs seem to be limited to very large corporations and government entities.  These aren’t the script kiddies of old, but sophisticated criminal or governmentally-funded entities, which is exactly what makes these attacks so devastating.  The only way to combat them is to:
  • Institute tight security controls and good coding practices on your public servers.
  • Perform vulnerability assessments to find systems that may allow code injection.
  • Monitor your network with an IDS and review system logs, tracking down any suspicious entries. 
  • Perhaps most importantly: educate your users on secure web and email practices, through the development and implementation of a solid security policy.

Unfortunately, the new challenge of IT Security involves protecting your network from unpredictable and blended threats that can come from anywhere – not just those that come through the front door.  APTs will likely become more prevalent as the costs and complexity of these attacks decrease with advances in technology.

If you don't already have a security policy, check out www.InstantSecurityPolicy.com, which can help you obtain a custom set of security policies in minutes.  Coming soon: "So What if You Are a Target?"

Tuesday, April 13, 2010

Security Policy Review

After the security policy has been in place for some period of time, the company’s information security controls should be audited against the applicable policies. A review process should be developed that is appropriate to the procedures and resources of the company. Make sure that each policy is both A) being followed as per guidelines, and B) still appropriate to the companies situation.

Regularly review the security policy to ensure that it still meets your company’s requirements. Create a process so that the policy is periodically reviewed by the appropriate persons. This should occur both at certain intervals (i.e., once per year), and when certain business changes occur (i.e., the company opens a new location).

During reviews you will likely find that changes need to be made. Often, policy changes will be needed to accommodate changes in the company, security technology, or applicable regulations. Sometimes you will find that the policy is still appropriate for the company, but the users are no longer adhering to the policy. In this case, re-educating your users on the security policy is in order.

Regular policy review, along with taking actions dictated by the review, will ensure that the policy does not grow “stale” and will continue to be a useful management tool for years to come.

Tuesday, February 2, 2010

Security Policy Implementation

Once you’ve created your policy, you need to roll it out to your organization. Too many well-intentioned projects lose steam in this phase, so this step must be well planned and undertaken thoughtfully.


First, and perhaps most importantly, a security policy must be backed by your company’s senior management team. Without their support, the cooperation needed across departments will likely doom the implementation. Department heads must be involved, and specifically, Human Resources and Legal Services must play an integral part.


If the position doesn’t already exist, an Information Security Officer should be designated at your company who is responsible for implementing and managing the security policy. This is sometimes not practical at smaller companies, but regardless, one person, who has the authority to make executive decisions, needs to own and be accountable for your company’s security policy.


Remember that your security policy must be officially adopted as company policy. It should be signed off on and recorded in the same way your company makes any major decision, including full management approval.


Go through each policy and think about how it will be applied within the organization. Make sure that the tools are in place to conform to the policy. For example, if the policy specifies that a certain network be monitored, make sure that monitoring capabilities exist on that network segment. If a policy specifies that visitors must agree to the Acceptable Use Policy before using the network, make sure that there is a process in place to provide visitors with the Acceptable Use Policy.


User education is critical to a successful security policy implementation. A training session should be held to go over the specific policies that will impact users, as well as provide basic information security awareness training. Often, users create security issues because they simply don’t understand that what they are doing is risky or not permitted.


Users must be provided any user-level policies, and must acknowledge in writing that they have read and will adhere to the policies. If possible, coordinate this with Human Resources so that the policies can be included with any other HR documents that require a user signature.


No matter how well thought out, no policy will be 100% applicable for every scenario, and exceptions will need to be granted. Exceptions, however, must be granted only in writing and must be well documented. It should be made clear from the outset that the policy is the official company standard, and an exception will only be granted when there is an overwhelming business need to do so.

Friday, January 8, 2010

Guidelines on Policy Content

When developing content, many go about creating a policy exactly the wrong way. The goal is not to create hundreds of pages of impressive-looking information, but rather to create an actionable security plan. The following guidelines apply to the content of successful IT security policies.

A security policy should be no longer than is absolutely necessary. Some believe that policies are more impressive when they fill enormous binders, or contain hundreds or thousands of policies. In fact the sheer amount of information in those policies is what makes them useless. Brevity is of the utmost importance.

  • A security policy should be written in “plain English.” While, by nature, technical topics will be covered, it is important that the policy be clear and understood by the target audience for that particular policy. There is never room for “consultant-speak” in a security policy. If there is a doubt, the policy should be written so that more people can understand it rather than fewer.
  • A security policy must be consistent with applicable laws and regulations. In some cases there are laws that apply to a company’s security practices, such as those covering encryption. Some states have specific disclosure laws and some industries have specific regulations. Research and become familiar with any regulations or laws that apply to your company’s security controls.

  • A security policy should be reasonable. The point of this process is to create a policy that you can actually use rather than one that makes your company secure on paper but is impossible to implement. Find a middle ground in the balance between security and usability that will work for you.

  • A security policy must be enforceable. A policy should clearly state what actions are permitted and what actions are in violation of the policy. Further, the policy should spell out enforcement options when non-compliance or violations are discovered.


For more information visit www.InstantSecurityPolicy.com.

Thursday, December 3, 2009

Types of Security Policies

Different companies will need different policies for effective security management. Below is a list of standard policies that would make up an organization’s security policy. Some companies may need all these policies, while others need only a handful.

That said, certain policies can reasonably considered “essential” to security management and are applicable to most every company. These are denoted below with an asterisk. By clicking the policy name below, you will be taken to an outline for each policy.

For more information visit www.InstantSecurityPolicy.com.

Tuesday, November 3, 2009

What a Security Policy Should Cover

A security policy should be written so that it can be understood by its target audience (which should be clearly identified in the document). For example, technical policies can by nature be more technical than policies intended for users, which should be written in everyday language. At no point should a security policy use confusing or obscure legal terms.

A security policy should not allow room for misunderstanding so that there is universal understanding of the policy and consistent application of security principles across the company.

A Security policy should have, at minimum, the following sections.

  • Overview: Provides background information on the issue that the policy will address.
  • Purpose: Specifies why the policy is needed.
  • Scope: Lays out exactly who and what the policy covers.
  • Target Audience: Advises for whom the policy is intended.
  • Policies: This is the main section of the document, and provides statements on each aspect of the policy. For example, an Acceptable Use Policy might have individual policy statements relating to Internet use, email use, software installation, network access from home computers, etc.
  • Definitions: For clarity, any technical terms should be defined.
  • Version: To ensure consistent use and application of the policy, include a version number that changes with any changes to the policy.
For more information visit www.InstantSecurityPolicy.com

Tuesday, October 20, 2009

The Security Policy Problem

The process of getting a security policy is difficult, time-consuming, and expensive. You typically have two choices:

  1. Hire a security professional to write a custom policy for your organization.
  2. Try to write your own using resources found on the Internet or purchased guides.

Number one is an expensive proposition – it can cost tens of thousands of dollars, depending on the complexity and number of policies, and take a great deal of time. Number two is impractical – it would take weeks, if not months, of painstaking work to cobble together a policy that will likely not be appropriate for your company. These two reasons deter most security policy projects before they start.

The process of getting a security policy is confusing. As an example, leading security policy experts recommend that a policy have the following components: standards, guidelines, position statements, guiding principles, rules, procedures, and lastly, policies. This jumble of “consultant-speak” is confusing at best, and does not result in a useful management tool.

To be effective, a security policy must be clear and consistent. As important, a security policy should fit into your existing business structure and not mandate a complete, ground-up change to how your business operates.

For more information visit www.InstantSecurityPolicy.com

Sunday, August 30, 2009

Why Have a Security Policy?

It is generally impossible to accomplish a complex task without a detailed plan for doing so. A security policy is that plan, and provides for the consistent application of security principles throughout your company. After implementation, it becomes a reference guide when matters of security arise.

A security policy indicates senior management’s commitment to maintaining a secure network, which allows the IT Staff to do a more effective job of securing the company’s information assets. Ultimately, a security policy will reduce your risk of a damaging security incident.

A security policy can provide legal protection to your company. By specifying to your users exactly how they can and cannot use the network, how they should treat confidential information, and the proper use of encryption, you are reducing your liability and exposure in the event of an incident. Further, a security policy provides a written record of your company’s policies if there is ever a question about what is and is not an approved act.

Security policies are often required by third parties as part of their due diligence process. Some examples of these might be auditors, customers, partners, and investors. Companies that do business with your company, particularly those that will be sharing confidential data or connectivity to electronic systems, will be concerned about your security policy.

Lastly, one of the most common reasons why companies create security policies today is to fulfill regulations and standards that relate to security of digital information. A few of the more commonly encountered are:

  • The PCI Data Security Standard (DSS)
  • The Health Insurance Portability and Accountability Act (HIPAA)
  • The Sarbanes-Oxley Act (SOX)
  • Massachusetts 201 CMR 17.00
  • The ISO family of security standards
  • The Graham-Leach-Bliley Act (GLBA)

All these require, in some form, a written IT security policy.

For more information visit www.InstantSecurityPolicy.com

Monday, July 20, 2009

What is an IT Security Policy?

An IT security policy is a strategy for how your company will implement Information Security principles and technologies. It is essentially a business plan that applies only to the Information Security aspects of a business.

A security policy is different from security procedures, in that a policy will provide both high level and specific guidelines on how your company is to protect its data, but will not specify exactly how that is to be accomplished. This provides leeway to choose which security devices and methods are best for your company and budget. A security policy is technology and vendor independent – its intent is to set policy only, which you can then implement in any manner that accomplishes the specified goals.

A security policy should cover all your company’s electronic systems and data. As a general rule, a security policy would not cover hard copies of company data but occasionally some overlap is inevitable. Where the security policy applies to hard copies of information, this must be specifically stated in the applicable policy.

A security policy must specifically accomplish three objectives:

1) It must allow for the confidentiality and privacy of your company’s information.

2) It must provide protection for the integrity of your company’s information.

3) It must provide for the availability of your company’s information.

This is commonly referred to as the “CIA Triad” of Confidentiality, Integrity, and Availability, an approach which is shared by all major security regulations and standards.

For more information visit www.InstantSecurityPolicy.com

Saturday, June 27, 2009

Starting the Process

There is no right or wrong way to begin the process of developing a security policy. No single policy or security strategy will work for every organization. Contrary to what is advertised on the Internet, there is no generic template that will meet every need. A fantastic policy for Company A might be useless to Company B. A security policy must be a custom document that reflects your company’s environment, and meets its specific security needs.

In fact, a useless Security policy is worse than no policy. Companies that boast of Security Policies thicker than a ream of paper are often the ones that have no idea what those policies say. The false sense of security provided by an ineffective policy is dangerous. The point of a Security policy is not to create “shelfware” that will look good in a binder, but rather to create an actionable and realistic policy that your company can use to manage its security practices.

For more information visit www.InstantSecurityPolicy.com