You only have to look at the various types of credit card frauds I outlined in a post a few weeks ago to realize that it is very likely that your business will eventually be a target. Whether this leads to financial loss for you or your customers it is important that you protect your reputation first and foremost. This is not to say you put reputation before acting in the correct manner. The most shocking part of any revelation of major fraud is often how long a company or government department takes before admitting an issue has occurred. The TK Maxx credit card fraud is a classic example of this.

In 2006 TK Maxx discovered that hackers had cracked their encryption system and gained access to their customer’s credit card data since as far back as 2003.  This of course was bad enough, but what made things worse was that it took 18 months before the news of the breach was released. So tip number 1 in terms of protecting your business from credit card fraud is to have a response plan in place from the start. Always take the attitude that fraud WILL occur – once you know that a customer has been affected you should inform them immediately. Any short term damage will be mitigated by the long term protection of your reputation and image.

When dealing with customers online it is best to use a 3rd party provider – you don’t want to have the responsability of storing and protecting your customer credit card data – and compliance with PCI (Payment Card Industry) requirements is at it’s most basic.

What about preventing fraud in the first place? It’s unlikely you will ever find a way to prevent fraud completely – but the minimum standards to make it less likely should be:

1. Insist that you or your payment gateway provider use SSL encryption for all credit card transactions. SSL encrypts the traffic between your site and your customer’s browser and makes it less likely that a transaction could be spied on over the internet.
2. Use the Credit Verification Value (CVV) number in all transactions. The CVV value should not be stored in any way once communicated as it is a random number generated for each individual credit card and provides some assurance that the customer has the card in their possession
3. Use the Address Verification System (AVS, i.e. that the credit card address be given when ordering over the internet) – even though this is almost obsolete as a verification on its own when used in conjunction with the CVV number it provides further assurance that the card is in the physical possession of the customer.
4. Only keep data when needed and discard when finished and ensure your payment gateway provider follow s the same policy. It’s tempting to store credit card details to make transactions easier for your customers – but be aware of the risks that if you store data you are responsible for it!

I’ll end by reiterating the most important tip – be transparent in your dealings with your customers, if a breach occurs be sure to inform all those affected immediately and take steps to rectify them. Any immediate financial loss could be insignificant when compared with long term damage to your reputation.

It’s is one thing to build a security plan, another to implement it and a struggle to maintain it. It’s very common to see security policies and plans with no controls in place to support them (as I have touched on in previous posts).  This is a major problem when you need to display security implementation to a potential or existing client. Sure you have a plan, but what does this actually achieve? This is where maintaining a Security Maturity dashboard is very useful.

There are many ways to build a maturity dashboard – essentially it is drawn from the balanced scorecard methodology which has it’s own variants – the core design is always the same however. It depends on defining a baseline for your security implementation and the steps required to achieve that baseline.

Basically for each area covered by your security plan you will need a policy, procedures, controls, metrics, compliance and continuous process enhancements (CPE) to achieve full maturity. As you will most likely start with a policy for the areas you want to cover that represents the most basic level of maturity. As you build your security plan through the use of industry standards, risk assessments and security incidents (by using “lessons learned”) you can start moving up in terms of security maturity. This is the scoring system I use:

• Level 0 = Gap (No policy, procedure or controls in place)
• Level 1 = Basic (Policy and procedures in place, no metrics or controls in place)
• Level 2 = Standardized (Policy, procedures and controls in place no metrics but infrequent compliance checks)
• Level 3 = Advanced (Policy, procedures and controls in place with metrics and compliance – no CPE program)
• Level 4 = Dynamic (Policy, procedures and controls with full metrics and CPE program)

Of course there are nuances – as you assess each area of your plan you will see that you are either exposed (have a score of 0) or have a policy in place (score = 1). However, The very act of carrying out the assessment means that you have acknowledged a gap and have started to respond to it (if you follow the correct process you will start to draft a policy to fill the identified gap), in this case you actually have a score of 0.5.  Once you have identified the starting point (ie – the good, bad and indifferent parts of your security implementation) you can start planning a program and how to move from one level to the next.

You can even provide an overall score for your organization so you can take a high level view of your progress. By creating a maturity report with a scorecard you can demonstrate a commitment to security even before you have put any in place (as long as you follow through of course!). This can be a key element in heading off negative audit observations or findings or reassuring new and existing customers that their data is safe in your hands.

I will provide more detail on maturity planning including how to set up your own dashboard in future posts. As I have said above – there are many approaches to how you measure your security implementation, the main thing is that you check compliance with your OWN policies on a regular basis.

As a manager you will not be expected to know the ins and outs of how your website is built – however it is important to make the right choice of technology and not just trust in the advice from your IT department. Every website technology has it’s pitfalls and today I will run through some of the better known website technologies and their pitfalls. If you have been following my posts over the past few months you will have seen how important I believe good governance and due diligence is when building your IT strategy.  Having a basic understanding of the technology in use for your company is an essential part of this.

There are dizzying array of web tools that allow even the most technologically inexperienced to create and maintain a commercial website. You must decide which you are going to use and why – commercial programs such as Dreamweaver, Front page etc… all have their pros and cons from an operational point of view.. and in terms of security are no better or worse than each other for the most part – the security issues related with building sites using these tools are almost all user related.. it is what scripts you write or put in place that will determine your risk exposure (as well as hosting provider etc… which I have discussed in a previous post)

Content management solutions (CMS) and template built solutions pose different issues – the manner in which these are managed and maintained when online provide the first major decision that you will face when deciding how to create your website. Most CMS programs provide an online administration page. This administration page is a major flag for a potential hacker and could be a serious vulnerability.

This does not mean that open source CMS solutions such as Joomla, Mambo, Drupal etc… should not be considered – just that you should be clear as to the risks involved and weigh these against the benefits that these very powerful solutions can provide you. It could be argued that tools such as these benefit from a large user community which can respond quickly to security issues where commercial products are not so nimble, on the other hand since the source code is fully available there is more scope for vulnerabilities to be discovered and exploited – this means that security releases and updates are released quickly, but patches and updates are needed more regularly. This requires more vigilance on the part of the website administrator. It is a choice that you must make and is more often than not decided by cost and available resources to manage your site.

Open source tools are very popular but have the disadvantage of being technically unsupported – even if you pay for support the code used is open to being exploited as it is in essence all out in the open. Having said that, as a starting point for your e-commerce site, using tools with pre-built templates provide very powerful solutions for little or no outlay.

HTML editors  may give you more control, but assuming you are not a web designer yourself you will have to pay for sites to be built and maintained – open source CMS solutions are much more user friendly and have the potential at least to be set up and maintained by the technologically challenged.

If you’ve never worked with HTML or Web pages and don’t really understand how they work then it’s going to take you quite a bit of time to get a good site up and running and the chances of leaving security holes are much greater.

I should point out here that if you hire a third party to build your site it is imperative that you follow due diligence when assessing a potential company or freelancer to build your site. It is very easy to hire someone “sight unseen” from an online freelance body shop (such as elance.com or guru.com etc…) – however the very same person building your site could also be a potential threat to your business. Even if there is no malicious intent from the person or company you hire they may not follow good security practices themselves which again opens up the possibility that you will be hacked or infected by a virus. Be sure to review a companies reputation on the web and consider hiring an independent security professional to review code and platform settings.

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.

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.

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)

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.

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.

However….

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.