Risk Assessments – the core of any good security plan

June 4th, 2010

There is a common misconception that the aim of IT security is to apply a “perfect” set of procedures for protecting information. Perfection is an impossible goal and your plans should reflect this. The aim of your plan is not about perfection, it’s about being able to properly recognize the weaknesses in your organization and take steps to mitigate against them. The risk assessment is the cornerstone of this approach.

I won’t go into the minutiae of the risk assessment process – you will find resources for that in our training material – but it is worth pointing out what should be included in your risk process. This is actually quite simple. EVERYTHING needs to be included. Or at least everything that is within the scope of your plan. The key is to rate your risk appropriately no matter how small or unlikely it may seem.

Most risk assessment templates start off with entries for Fire, Flood, Earthquake, Volcano etc…. Many of which may seem highly unlikely threats to your information. I would recommend that these types of risks should be included in your planning – even if they constitute minor residual risks that will most likely never happen. Often the perception of what will “never happen” is incorrect in any case. I’m sure that companies whose critical business travel was disrupted by the Eyjafjallajokull volcano are completing their “Ash” plans as I write – a great example of something that “will never happen”!

Rating you risks according to likelihood, impact and actual exposure (vulnerability) is important, and it is also important that you lay out in your plan what the appropriate level of management response should be for each risk. This means that you decide that some issues need immediate response; others can be seen as requiring a lower response time.

Once you have assessed your risk you need to work out how you will “treat” them. This could be through new procedures to be included in your security plan itself, a change in how you do business (or where you do business) or simply to accept certain risks as acceptable and residual. It would be a mistake to bury problems in your plan as “acceptable” just because you don’t have the will to mitigate them. This is an all too common mistake. No plan will succeed if the risks are not dealt with honestly and appropriately. The management support and willingness to recognize weaknesses is key to any risk plan.


Implementing a security plan

June 4th, 2010

In my last post I defined the various parts of your security plan. It is actually very simple to gather security policy, standards and guidelines in a document (or series of documents) paste in your company’s name and call it your security plan. The tricky part is in the implementation.

Depending on the size of your organization (and the nature of your business) there are various regulations and legislation that you will need to comply with. It is important that your plan maps directly to the needs of your business – security is driven by these needs and not the other way around. If you hold credit card data then you will need to comply with the PCI rules regarding the secure storage of that data. When you come to developing and implementing your security plan then your plan needs to map to this standard first.

Once you have your plan ready for implementation you need to consider what controls you will need to ensure the plan is implemented. The controls serve two purposes:

  • They are to ensure the plan is implemented correctly. Remember this is not just an exercise in giving the impression of good security practices – it is about the actual and effective implementation of security to protect your business from threats.
  • They provide evidence of good security practices. These days customers are demanding that their data be managed securely, that companies are managed in a responsible and professional manner, you need to be able to demonstrate your security practices whether it is directly to a customer or during an audit.

Controls do not have to be extensive, but they do need to be effective. For example  – if your company states in its policies that access to certain data is restricted then you need to show how this is ensured. It could be via access controls (physical or logical) in which case logs need to be kept of who has accessed the data at any given time. You need to show what barriers have been put in place to stop unauthorized access, and what incident management procedures you have in place should a breach occur.

Again, how far you go with your security controls will depend on the size and nature of your business. For a small company paper processes and logs may be perfectly adequate when combined with other controls. For example – a log of entry and exit to your building at reception  backed up by a security camera on the entrance to your building would show how you can prevent unauthorized entry to your premises. Provided you keep the camera footage for a reasonable amount of time of course.

The key in developing proper controls for you business is the risk assessment process that should be at the core of any security plan.

Policies, Procedures, Guidelines – sorting out your security plan

June 4th, 2010

It’s quite common for me to be asked to develop security policies for a client. Often this is as the result of an audit finding where no evidence of security planning has been found – the common reaction is “well – let’s write some security policies”.  Of course you need to have documented policies for your company, but the policy should be a starting point rather than the goal. It’s even more common to find companies with well developed policies covering every aspect of their business, but no instruction on how to apply them. I often work with companies who have failed an audit despite having “policies” on every aspect of their IT implementation. The reasons for this are:

  1. Lack of standards
  2. Lack of guidelines
  3. No evidence of policy being applied and acted upon

It’s worth defining some of the terms to get a better understanding of why your 100 page security policy may not be “fit for purpose”.

  • Policies are corporate documents which set out a company’s position regarding business processes, behavior of personnel, and similar topics.  Policies are a high-level statement of your company’s position.
  • Standards (or operating procedures) are the rules which must be followed to enable an effective information security program. Compliance with the standards should be mandatory, but deviation is possible if approved by management. Standards define the minimum, baseline procedures, practices, and configurations for systems, applications, controls, networks, and related topics.  They are designed to provide a single reference point for use during software development and adoption, installation of systems and tools, and during the contracts process with vendors and service providers. Standards do not, however, give detailed command-line instructions on how to meet a company’s policies.  Those are given in the guidelines.
  • Guidelines (or work instructions) are built for each application and platform, and are the handbook to be followed when implementing that particular tool.  So long as the security standards are met, however, a guideline may vary a bit from one implementation to another, so long as a justification is given and properly documented.

Put together, these three levels of documents provide a method for the company to audit itself and ensure that proper controls are in place, without excess cost or risk. They also provide a means for the company to explain to regulators, examiners, external auditors or investors how it is that  the company is safe, trustworthy, and efficient*.

One section not mentioned above is Evidence you need to have a process of testing and logging compliance to the standards you put in place. You need to keep minutes of security meetings, apply basic risk assessment and treatment plans and follow set procedures for any information security breaches.

These do not have to be extensive controls but do depend on the size of your company. A one page policy document and a short standards document backed up with some basic guidelines is perfectly adequate for a small business of less than 20 employees. The larger the business the larger you security PLAN should be – it is important to think of it as a plan rather than a set of policies.


(*extract from CSPO Tools standards template)

Cloud Computing – Regulatory Concerns and data retention

May 28th, 2010

In Previous posts I have touched on data protection legislation in general as well as in terms of cloud computing. Of course different regulations apply in different industries but one that applies generally in the UK at least  is data protection. When it comes to cloud computing I can see several areas where a company needs to be wary of not breaching laws and regulations surrounding the collection, processing, retention and protection of personal data.

On the face of it cloud computing  is currently very hard to align with regulatory requirements – and not just when it comes to data privacy and protection. In heavily regulated industries like pharmaceuticals and banking it’s hard to envisage how companies could display complete control of data. In the case of the pharma industry the need to show control over the integrity of data when developing drugs would seem to rule out cloud computing altogether, at least when it comes to clinical trials.

I have already touched on the general security concerns with cloud computing so protection of data and the risks involved are fairly evident. I can also see issues with collection and processing of data in a shared environment, but one area that companies should be careful of is the retention of data.

It’s very important to remember that a virtual environment is one that can be copied, backed up and moved relatively easily. While your company may have a clear retention policy in place and a supporting procedure that ensures data is disposed of correctly and immediately when it is no longer needed you need to be certain that this is matched by the retention policy of your hosting provider.

Many virtual environments are backed up on a daily basis, and images kept of the backups for the whole life of the system. I can see a situation where a company may be removing data from their servers in a timely fashion as required, but are completely ignorant as to the number of virtual images are being kept of their servers. It’s an important part of any SLA of course – but how do you ensure that data has been disposed of correctly in a virtualized environment? particularly one that you do not own yourself.

You may be able to ensure protection of your data when it is “live” but how do you protect data that has served it’s usefuleness, but must be disposed of in a secure way to ensure compliance with data protection regulations? The one major flaw with cloud computing seems to me to be this very question – by having too much data hosted in a way that ultimately is beyond your control it is very hard to align your IT infrastructure with regulatory requirements. A whole new way of thinking is required as well as  legislation to deal with the new IT landscape.



Cloud computing – Confidentiality, Integrity, Availability

May 28th, 2010

Before surrendering your entire IT environment to the cloud it’s worth taking a moment to consider the implications. You could see this as a conflict between the operational business units and the internal security and regulatory departments of your company. The cost savings are potentially enormous of course – but so are the risks. The problem is that there is no large failure on which to base those security concerns. For the most part security governance and compliance can be illustrated by the number of significant security failures for each item. Need to illustrate laptop and mobile computing security? just quote the latest government laptop that has been stolen. Need to illustrate fraud in the workplace?  Just quote the latest corporate fraud episode.. and so on.

The problem with cloud computing security is that it is so new and so leading edge that we don’t have a store of examples to trot out to illustrate the industry best practice, the question you need to ask is if YOU want to be the first example that everyone quotes when illustrating cloud security.

So – what are the things that keep me up at night about “the cloud”? Given that I don’t have a list of examples to draw from I need to talk a bit in terms of some “what if” scenarios.

Take fictitious company “Nuages”. They have decided to moved their fixed cost physical servers to a hosted virtualized environment. This means that instead of paying for servers that are only at their peak usage once a month when the company accounting processing is run they only pay for that peak when it is needed and have cut their costs by 70% in the process. As well as the accounting servers the company databases with customer data and proprietary company data has also been moved.  As a final cost saving all users connect to a virtual desktop and keep all company data on it. The hosting provider is well known and a detailed SLA is in place covering all aspects of protecting the companies information in the cloud.


Scenario 1 “Availability”: An employee at the hosting provider mistakenly deletes the Nuages virtual hosted environment. While there are backups these take time to reapply and in any case some data will be lost. Of course this could happen in a “real” data center, the point being that a virtual environment can be destroyed in an instant at the touch of a button whereas a physical server is more robust.

Scenario 2 “Integrity and Confidentiality”: A hacker gains access to the hosted cloud. It’s on the public internet after all – perhaps the hacker opened an account in the same “cloud” and created his own server from which to attack the hosting provider from within. Nuages has firewalls in place of course – but these are managed by the hosting provider, and in any case an attack from inside the environment would not be blocked  – it’s “trusted” after all. The hacker gains access to the Nuages server and steals, damages or hijacks data.

Scenario 3 “Availability”: The internet is down – a major fire at a network exchange brings down broadband to the Nuages offices. In prior years workers could have continued on teh local network, but now their “virtual” desktop is inaccessible.

But what about the SLA? sure the hosting company has to pay penalties to make up for the breaches, but no SLA will bring back lost data, or fix a breach in confidentiality or return lost productivity.

There is very much a downside in trusting too much of your precious data to a 3rd party.


Cloud computing – choose what’s right for you

May 28th, 2010

Last week I touched on cloud computing and what it means for data protection and security in general. I will be expanding on two aspects in particular:

  • Security: issues related of  maintaining the “CIA”  (Confidentiality, Integrity and Availability) of your proprietary information
  • Regulatory: issues that may apply depending on your industry (and of course those that apply to all).

Before looking  at the two areas above it might be worth defining the three main types of cloud computing and their various pros and cons. Of course there are the upsides to cloud computing  – it’s not my intention to argue against the concept. I can of course see the benefits of shared IT resources and paying for what actually use rather than what you MAY use. My only goal is to highlight areas that you will need to address if you make the decision to switch to a shared cloud.

It seems inevitable that some form of cloud computing will become the norm, but there are several competing models so it is important to choose the right one for your company. The first thing to consider is if you should create your own private cloud, join the  “public” cloud or a combination of the two.

  • Private – Larger organizations may consider creating their own private cloud and while this still requires investment in data centers and infrastructure there are many security and regulatory advantages with this approach. For example in this scenario users could connect to a virtualized environment from their computer browsers – this reduces the risk of virus infection or malware infecting your company network as you have complete control of the “client” environment. While not true cloud computing in the sense of  a “pay as you go” cost base it is still true to the idea of shared resources. Many companies that baulk at entering the cloud will most likely end up moving in this direction.
  • Public – This is really what most people are talking about when discussing “the cloud”  – this is the complete move of your IT environment to a publicly hosted “cloud” that contains not only your companies data and web applications, but those of other companies as well as individual and casual users. The advantages are very clear in this scenario, as are the risks. I will discuss security concerns in more detail in my next post.
  • Hybrid – A combination of private and public cloud computing. In many ways hybrid systems have been in use for quite a while. Think of the “portals” that many companies started using that allowed customers to connect to segregated parts of their networks – or universities that “borrowed” processing power on PCs through the use of screen savers. In this scenario some parts of your infrastructure would be in a public cloud – and some parts on your own private cloud or environment.

This is a very high level view of cloud computing – I think, however, that some key pros and cons are quite evident. In my next post I will look at the security concerns in more detail, particularly with regard to the CIA of IT security.


The Who, What and Why of collecting customer data

May 16th, 2010

Whether collecting data via your website over the phone or face to face, there are some very important considerations that are often overlooked. The UK Data Protection Act of 1998 has some fairly high level provisions regarding the processing of data;  like all legislation the act can be fairly obtuse but being careful abut some basic elements can ensure compliance. These elements are the Who, the what and the why of collecting data.

  • Who: You must be sure to clearly identify the legal entity that is collecting the data. This may seem obvious but often companies legal entity is different to their public name. This is most common with websites but can occur anywhere. So on your website forms it is important that clearly identify what company will be holding the information.
  • What: It is important that you only collect information that is of interest/importance to your organization. Again this seems fairly obvious but you have to ask yourself whether you need things like date of birth, place of employment, gender etc… All may be legitimate data for your business, but if it is not something you will actually use then it is best to leave it out.
  • Why: It should be clear to the customer or employee why information is being collected – again this seems obvious, but sometimes so obvious that companies leave it out. Don’t assume that a customer will understand why information will be collected  – in the case of data protection it is best to state the obvious early and often.

It’s worth communicating the “8 principles” of data protection – we’ll be looking at them in more detail in the next few posts.

  1. Personal data is processed fairly and lawfully;
  2. Personal data is always processed in accordance with good practice;
  3. Personal data is only collected for specific, explicitly stated and legitimate purposes;
  4. Personal data is not processed for any purpose that is incompatible with that for which the information is collected;
  5. Personal data that is processed is adequate and relevant in relation to the purposes of the processing;
  6. No more personal data is processed than is necessary having regard to the purposes of the processing;
  7. Personal data that is processed is correct and, if necessary, up to date.
  8. Personal data is not kept for a period longer than is necessary, having regard to the purposes for which they are processed.

Clouded Security

May 16th, 2010

Cloud computing has been an idea that has been knocking around for many years at this stage – the idea that software could be shared “in the cloud” without the need for local client installations is a very interesting idea, both in terms of cost and support, for small and medium businesses. In fact the idea of cloud computing has evolved even further with virtual environments providing server clusters and complete virtual networks. Even a one person operation could have a “virtual” enterprise environment hosted in the cloud.

Although the services have been available for a while now it is only with the advent of services like google docs (and of course the complete suite of google services) the idea seems to finally be on the verge of taking off. It’s very hard to argue against cloud services from an operational point of view.  Hard pressed SME’s with limited and shrinking IT budgets will obviously view a free service like google docs more seriously than they may have in the past.

This is when security or regulatory considerations can come into conflict with operational needs. Take telecommuting as an example – best practice dictates that a users should only connect to the company network via a VPN, use a company supplied computer and never work on company documents on a home computer. If the documents are already on a public “cloud” network how can any of these recommendations be applied?

From a regulatory point of view how can document classification and control be managed on shared services – where does the ownership of the data begin and end?

The basic message is that although the technology exists it does not mean that there should be a rush to use it. That’s not to say there is no future for the cloud – just that practical security controls have not yet been thought out.


Security Procedure v Security Policy

May 10th, 2010

Over the past few weeks we’ve been looking at security governance in operation, or at least how it should look in operation. This brings to mind the confusion I often see with clients between a security policy and security procedure. This is an important point as it is quite often that I find managers fretting over the creation of policy but not spending time on the application of security procedures. It’s one thing to have a great security policy gathering dust in your desk drawer and quite another to have an effective operational plan in place to support it.

This is really the point – the policy sets out how you would like to see security in place and the procedures ensure that this vision becomes a reality. When creating a policy you need to be sure that it is something you are willing to enforce. In other words anything that is not a legal requirement but that you believe to be important to ensure the security of your company.

I’m often told by managers that security “is just common sense” and by extension if people are “sensible” then there really isn’t very much to worry about. This approach is what I would term the “glass is half full” approach to security and governance – assuming that your employees will not breach your internal rules and standards because they are logical. Most security professionals approach things differently however, he glass is definitely half empty in our view.

The whole approach to security is not to be paranoid, just to be sure that the human factor is countered as much as possible. Simple (and sensible) controls on password storage and use, access to important data assets and use of internal networks are an essential starting point when setting out your stall on security. It does not have to be extensive and all encompassing from the start but your security plan must be effective.

If you say only certain people should have access to certain data assets how do you prove it? If you say that you have a policy on coding standards for your website how do you ensure it?

Ultimately it is how well your plan operates that matters, not how long a document it is.


Getting your Domain Registered Safely

April 16th, 2010

Last week I covered some security threats to website domain names – but how should you go about registering your name correctly in the first place? When registering your domain you should be careful of a few things – first and foremost is your own privacy. You should use a Domain Registrar (DR) that permits you to create a domain privately – most reputable DRs will do this for you. Essentially this prevents your company or private details being used in social engineering attempts or for identity fraud. The “whois” information for a domain is often the first piece of information a hacker will try to use against you.

When you come to the moment of registering your domain you need to decide on a few things – when you will need the domain for your website, the possibility that you will need to move your site from one hosting provider to another, etc… Here are some scenarios:


You  are simply registering your domain and do not intend to use it for some time (perhaps while you build and test your website, or just decide the next step in your online business) then looking for the most cost effective domain registrar makes sense. There are pitfalls when looking for a domain registrar but if you take the time to do some research  – at the very least googling <insert DR here> and security  – will help avoid disaster!  Keep in mind that you wont be using the domain name for some time so reserving the name is the main concern. Barring a reputation for reselling domain names almost any DR will do.


You’ve got a burning need to get online NOW – you want your website up and running asap so you need the BEST DR going. The need to do your research is even greater now, be sure to look for a DR that has an easily accessible phone support line. Send some questions regarding any aspect of the process – then wait… you should rate the DRs according to which responds the quickest. Response time is important – if for any reason you need to move your website you will be depending on the DR to update DNS entries for you in a timely manner. Building a relationship early will save you heartache in the future.

Like a lot of advice in my posts to date all of the above should be classified as “just good common sense” but for some reason many companies think that the online world operates to different rules to the “real” one. Take the same precautions with your website as you would with your home or office. Locks, alarms and insurance…