Thursday, 21 August 2014

PECB Accredited Training

 PECB Website
We are pleased to announce that we are now able to offer accredited PECB (Professional Evaluation and Certification Board) training courses in-house for clients wanting to develop staff competencies in the areas of implementation and auditing of their management systems.

Courses can be provide for ISO/IEC 27001, ISO 22301, OHSAS 18001, and ISO 9001, as well as ISO 31000 and ISO/IEC 27005 for risk management.
Contact us for more information and quotation.

Tuesday, 17 June 2014

The proper context for policy writing

For a while now I've been intending to post a couple of example documents, such as policies and typical processes, for downloading on my website. Sitting here in my hotel room tonight, with nothing better to do, I figured I would get to work on an example/template for an ISMS Policy.

Sounds easy. I have no problem banging them out when I'm busy at work helping organizations to prepare theirs. But I've been sitting here for hours now and have little to show for it.

I'm phrasing it this way, then phrasing it another way, then changing my mind and looking at it from a completely different angle altogether. Which statement should I put in and which should I leave out? Who am I speaking too? What's the purpose of the policy? Who is actually doing the speaking? What is my focus? What is the actual message?? I have no idea!

The problem, I believe, is that I just don't have any context. In an implementation we go through a whole bunch of things before we get to the point where we, or I, will sit down and write the first draft of a management system policy. At that stage, it just kinda flows. And when its reviewed by the top brass, it makes sense and is relevant to them.

It just bought home to me (again) the importance of process, and why these ISO management system standards make you do what they make you do.. i.e. to 'understand the context of the organization' - and also why I am so adamant about not using generic templates as a general rule of thumb.

I'm sure I'll put something up at some point, but be warned if you end up downloading it, you will probably end up having to re-write the entire bloody thing as you find it doesn't fit your own business context!

Friday, 9 May 2014

Why do we trust in certification bodies?

Are you a believer? Do you accept that a company that is implementing and maintaining a management system based on ISO/IEC 27001 will have effective information security management processes appropriate for their unique business environment?
If you don't, then its pointless worrying about how or why we should trust certification bodies since their role is essentially to provide a greater degree of assurance to the interested parties of the certified organization of ongoing conformity to those standards. 
In certification, you are putting your faith in the abilities of the individual auditors that carry out the audits on behalf of the certifying body. If two different and competent auditors plan and conduct the same audit, both will emerge with different findings. In order to have confidence in this process, you must also understand how it works, its value and its weaknesses.
National accreditation bodies, like UKAS in the United Kingdom, help to give us confidence by auditing the certification bodies, essentially on our behalf, and ultimately removing the accreditation if the certification body is not fulfilling its own management system requirements and complying with standards such as ISO/IEC 17021 (Conformity assessment requirements) - which, for example, requires that certification bodies and their auditors are independent in conducting the audit. For example, certification bodies cannot also be consultants.
Another important requirement is that certification bodies must have effective processes in place for selecting and training auditors to ensure the necessary competence - very important given that we are being audited by people, and all are different. Good certification bodies will ensure consistency as much as possible, and to a high standard.
So to answer my own question, we often trust in 'accredited' certification bodies because we understand that they are being monitored by a competent, independent third-party (a national standards body) and have to maintain certain standards in order to remain accredited.
Are there good and bad certification bodies? Are there good and bad auditors? YES to both! Its certainly not black and white, and good auditors can have bad days too! But ultimately, the certification process is a convention of trust. Ultimately, it is the reputation of the certification body and its accreditation that we are looking to for that trust and is the main reason why an unaccredited certificate of conformity issued by myself would likely be perceived as being worthless compared to the certificate of a known certification organisation.
A final thought. When you see the little green lock icon in your browser window whilst typing in your credit card details for a spot of midnight shopping, and the URL reads HTTPS - Do you stop to ask the question, "Why do we trust in Certificate Authorities"? SSL Certificate Authorities (CA) - those who issue the digital certificates to the e-commerce websites that we trust with our credit card and other personal details are businesses too. 
When it comes to selecting a certification body as an implementer, or evaluating a supplier who is certified, it is primarily the independence, reputation/brand, and history of the certification body which is providing you the degree of assurance that you are probably looking for. But its not a guarantee.

ISMS Assets and Scope

ISO/IEC 27005 suggests that there are two groups of assets to be considered, primary and supporting. Primary assets are 'process' and 'information', supporting, or secondary assets are everything else.
In your scope statement, it is normally a good idea to identify your major primary assets or asset groups - since this is normally core to the reason you would be implementing ISO/IEC 27001. So it is typical to see 'customer information' identified in the scope statement, for example. This in-turn indicates to 'interested parties', customers in this case, that any process, people, technology, etc. that touches on customer information (human, technical, physical, or whatever) will be considered -- regardless it is owned and managed by your company or if it is outsourced.
A VPN therefore, is a secondary asset and [normally] has value (is important) to your organization because customer and other information may be travelling in-through-and out of the hole and has a role in protecting the confidentiality, integrity, and availability of the information which travels through it - its a control. But equally, it presents a risk, since it can fail and render information unavailable among other things. 
This is where scoping starts to get a little more complex because we are now talking about boundaries and interfaces and since a VPN is most often used to facilitate the transfer of information securely from point A to point C, via a third-party B. Your ISP could be point B in this example, an entity which would be out-of-scope of your ISMS (you have no control over their security environment) but represents a boundary and itself is an asset since you depend on them to be able to send and receive information in your business. Note also that a VPN is not something that is required in the process of sending and receiving information, but we implement them as a means to manage risks, primarily concerning confidentiality.
So to make matters more complex, not all assets are things that are in-scope per say. Like personal mobile telephones, are they assets? Not owned by the company, but often used by employees to do their work -- and often containing highly sensitive and important business information.. so they are an asset. As is your home office, where you take your work home for the weekend, making it an asset, but likely out of scope. Does your organization implement controls to manage these risks? Do they recognize the risks?
So scope and assets are two different things. Scope is simply telling us where we can and will apply our ISMS Policies and procedures and what is covered in terms of core business and information. Boundaries, interfaces, and out-of-scope process are something we must be aware of so that we can assess the risks and put in place the appropriate controls and manage the risks, commonly done by way of contractual arrangements and other methods.
Scope statements will normally make reference to information (actual information - not the database that contains the information which is a secondary asset), processes, and locations. It doesn't have to be detailed and complicated, but it is very important and should be accurate. It plots out the big picture for us from which we can dig in to the details.
The scope also gives us a starting point for our assets - so if customer information is mentioned, we can start to figure out where and how that information is used throughout the business processes - that leads us to want to draw up an asset register - so that we don't forget, and others can improve on our work in the future, etc. By following the process, we'll also start to identify those secondary assets, like the database that holds the information and needs to be available to users -- and then we find users become an asset, etc..
So how do we identify these assets in our ISMS? Try the following: Draw a process diagram for a process that is in scope (inputs, activities, outputs, resources, controls/management) -- identify information that is created, used, destroyed.. etc within this process - the process and the information are your primary assets. Then look at how and what uses those assets within that process.. they are your secondary assets. It all goes into your asset inventory because this gives us the context of our risk assessment. And generally speaking, it is normally a good idea that each department or function is made responsible for maintaining their own inventory of assets.
This is why scoping and the identification of assets is so important, since its drives the implementation of the whole ISMS. Miss something important and the ISMS will add no value to your business. Include things that are irrelevant, and you will be burning valuable resources.
Which brings us to a final consideration when establishing the scope.. what is the purpose of the ISMS? A question that must be answered by top management. Answer that, and things will start to become more clear, and it all starts by firstly understanding the Context of the Organization.

Thursday, 27 February 2014

Another airport lounge experience

There is ALWAYS a wireless internet connection available to weary travelers in airport lounges who need to stay connected. Its just always there. And I think its generally expected - am I wrong? I just don't recall a time when I've been in a lounge where you just couldn't get connected.. even if it meant paying for it.

Until today that is. The Marhaba Lounge at Dubai airport, which normally provides a free connection, has, according to a member of staff, been cut off by their service provider and negotiations for its return are ongoing. 

The impact? No matter the actual reason or story behind the scenes, you still have unhappy - paying - customers (and a non-complimentary blog entry :). 

Its a good reminder of how important outsourced processes/services are for many businesses and how critical it is to identify and manage risks when depending on those who exist across the other-side of your ISMS boundary. 

Let's hope they work fast to get back that illusive service and take steps to prevent a recurrence of the same issue again. 

A = Availability