ISO 27001 vs. ISO 27002

Contributed By:
Dejan Kosutic


If you came across both the ISO 27001 and the ISO 27002, you probably noticed that ISO 27002 is much more detailed, much more precise - so, what's the purpose of ISO 27001 then?

First of all, you cannot get certified against ISO 27002 because it is not a management standard. What does a management standard mean? It means that such a standard defines how to run a system, and in case of ISO 27001, it defines the information security management system (ISMS) - therefore, certification against ISO 27001 is possible.

This management system means that information security must be planned, implemented, monitored, reviewed, and improved. It means that management has its distinct responsibilities, that objectives must be set, measured and reviewed, that internal audits must be carried out and so on.

All those elements are defined in ISO 27001, but not in ISO 27002.

The controls in ISO 27002 are named the same as in Annex A of ISO 27001 - for instance, in ISO 27002 control 6.1.6 is named Contact with authorities, while in ISO 27001 it is A.6.1.6 Contact with authorities. But, the difference is in the level of detail - on average, ISO 27002 explains one control on one whole page, while ISO 27001 dedicates only one sentence to each control.

Finally, the difference is that ISO 27002 does not make a distinction between controls applicable to a particular organization, and those which are not. On the other hand, ISO 27001 prescribes a risk assessment to be performed in order to identify for each control whether it is required to decrease the risks, and if it is, to which extent it should be applied.

The question is: why is it that those two standards exist separately, why haven't they been merged, bringing together the positive sides of both standards? The answer is usability - if it was a single standard, it would be too complex and too large for practical use.

Every standard from the ISO 27000 series is designed with a certain focus - if you want to build the foundations of information security in your organization, and devise its framework, you should use ISO 27001; if you want to implement controls, you should use ISO 27002, if you want to carry out risk assessment and risk treatment, you should use ISO 27005 etc.

To conclude, one could say that without the details provided in ISO 27002, controls defined in Annex A of ISO 27001 could not be implemented; however, without the management framework from ISO 27001, ISO 27002 would remain just an isolated effort of a few information security enthusiasts, with no acceptance from the top management and therefore with no real impact on the organization.

Can A Business Continuity Strategy Save You Money?

Contributed By:Dejan Kosutic



You are thinking about implementing the business continuity management/BS 25999-2 standard? But then you hear it will cost you a lot? It probably will cost you, but not necessarily as much as you thought - this you can solve with good business continuity strategy.
Business continuity strategy, as defined in BS 25999-2 standard, is an "approach by an organization that will ensure its recovery and continuity in the face of a disaster or other major incident or business disruption".

Therefore, the point is to prepare yourself in the best possible manner to counteract a disaster if such would occur. This preparation can include organizational measures (drawing up plans, making contracts with suppliers/partners, exercising, reviewing, awareness raising, etc.), and measures including investment in equipment, infrastructure etc.

Time is a very important factor in recovery - if you do not recover your business in time, you will probably lose your customers and consequently lose your business as well. So the business continuity strategy must set the recovery time objective (RTO) for each of your critical activities, whereas RTO can be different for each of those.

One important consideration: the shorter the RTO, the bigger the investment you will need - for instance, if you want to recover your data centre in less than one hour, you will have to invest in an alternative location almost the same equipment as in the primary location; on the other hand, if you want to recover your data centre in two weeks, the investment will be much lower because it would be enough to store the backup tapes at the alternative location, allowing you two weeks to obtain the necessary equipment. All this means that your RTO must not be too long, but not too short either.

Once the RTO is set, you will still need to make some investment; however, with a good business continuity strategy you will be able to decrease that investment, while still being able to recover your critical activities within the recovery time objective. Here are some examples:

■you might not need your own data centre at an alternative location - in most countries you can rent such a location from a specialized company, which means you don't need to invest in infrastructure, maybe not even in equipment or software,
■you might not need offices at an alternative location - employees who do not have to meet customers face-to-face can work from their homes,
■you might not need an alternative location at all if you have other business units at different locations which could take over the critical activities affected by the disaster,
■you might not need to purchase equipment in advance if you can find the supplier that could guarantee the delivery of equipment within your RTO
In all these examples you will need to increase your organizational capabilities, but if you want to save some money, it sure is something worth thinking about.


Cross posted from ISO 27001 & BS 25999 blog - http://blog.iso27001standard.com

Advice for Merchants on PCI DSS

Contributed By:
PCI Guru

Barring the card brands developing a truly secure card processing process, the PCI DSS and related standards are likely to be with us for quite a while. That said, what is the future of complying with the PCI DSS?

For merchants, if you are not seeking out point-of-sale (POS) solutions that do not store cardholder information, you should be as soon as you possibly can. That includes finding card processors that do not require you to store cardholder information and can provide you access to cardholder information when you need it for resolving disputes and chargebacks.

According to Robert McMullen, CEO of TrustWave, the majority of breaches TrustWave investigated occurred with POS systems. So the rational approach to resolving this problem is to get rid of the cardholder data stored on these systems.

The problem with this is that most merchants, large or small, think that they need to store this information for some reason. If you are a merchant in the United Kingdom, France, Italy and other select European countries, then you do need to have the PAN unencrypted, however it only is required on an original printed receipt, it is not required to be stored anywhere else.

So, all merchants need to put POS solutions in place that do not store cardholder data. You do not need it and it puts you at risk if you do store it.

The next thing merchants need to do is to find a card processor that does not require the merchant to store cardholder data. This can be a processor that uses tokenization or whatever, but the bottom line is that the processor does not return cardholder data to the merchant’s systems.

These processors typically provide secure Web-based systems that allow the merchant to view all of their transactions processed and, if necessary, provide a method to decrypt the PAN for dispute research and chargebacks.

Merchants need to restrict access to the processor’s applications to only those people that absolutely need access to perform their job. These people should be reviewed at least quarterly to ensure that they continue to require access.

For those of you that just cannot get rid of cardholder data, there is the option of hashing. Hashing allows applications such as fraud discovery, member tracking, rewards programs and similar functions to continue, they just do not have access to the actual PAN.

A hashed PAN results in the same hashed value, so research and analysis of PANs can still occur. It is just that if you need to see the real PAN, you will have to go to the processor’s system to obtain the real PAN.

The travel industry, in particular hoteliers, are really behind the eight ball on PCI because of their need to keep the PAN for sometimes years because of the way reservations work. However, this is where tokenization can earn its keep.

If a hotel takes a reservation and gets back a token when the credit card is authenticated, then the hotel can use the token however many times in the future for check in and check out. Again, there is no reason for the hotel to need to retain the actual PAN.

The bottom line to all of this is that there are ways to minimize your organization’s PCI compliance efforts just by getting rid of the data in the first place. So, stop putting forth efforts to comply and get with the movement to get rid of the cardholder data in the first place.

I have had a few clients go down this road and PCI compliance is now a piece of cake. Their networks are still in scope for transmission, their applications in some cases do process cardholder data, but there is not storage which makes them much, much less of a target.