Rod has considerable experience in providing information security consultancy and advice within a New Zealand government department. He specialises in implementing Information Security Management Systems based on the AS/NZS ISO/IEC 27001:2006 standard and risk management using the OCTAVE methodology.

• Confidentiality
• Integrity
• Availability

It’s been our mantra for a very long time that these are the three things that need to be achieved to obtain information security, but are they enough? I have had a niggling feeling for a while that they may be more. That is not to say that the CIA triad aren’t still relevant—they are still central. However, modern enterprises (including government) are making increasing demands on their IT departments to deliver real business benefit and return on investment.

For a while there used to be talk of non-repudiation being a new security objective. It’s a cumbersome word, for an idea that’s expressed in the negative, so it doesn’t appeal to me!
I suggest two extras:

• Trust
• Agility

Trust has been knocking on the door for quite a long time. Public Key Infrastructure (PKI) provides a mechanism that helps achieve trust. PKI helps us to trust the entity (person or system) that we are connected to is who it claims to be. It also supports non-repudiation (i.e. the initiator cannot claim that someone different sent the message or performed the transaction) and provides a method of verifying the integrity of a message or software package. However, the recent DigiNotar hack highlights that without appropriate CIA and other security basics, trust cannot be assured.

Agility has always been an objective of enterprise architecture. However, it should also be an objective of security architecture (both enterprise and solution). Virtualisation, SANs and Cloud Computing are all mechanisms whose big appeal is agility. These technologies can enable organisations to easily implement mergers, restructures, new alliances and supply chains and agency arrangements which are essential without compromising their information security posture.

Just as the original three goals were somewhat inseparable, with the addition of two new ones we must not suppose that they are entirely separable from each of the other four. However, I think each is distinct enough to justify its separate identification.

I’ve recently been working on a project that’s entire purpose is to provide trust. The solution manages the distribution of Public Key certificates. As the certificates are public, confidentiality is a non-issue. However, integrity is vital, because the certificates must be able to be relied upon. Availability is important, because dependent business processes will fail if this system is unavailable. Similarly agility is important as the solution will be expanded and evolved to provide additional functionality. It may even be migrated to a completely different platform.

Old information security thinking has tended to be pre-occupied with confidentiality (the NZISM is a great example of this). However, it’s important to see the whole picture, and recognise all five (are there more?) security objectives, not just the old three.

Michael has extensive experience in providing information security consultancy and advice to Australian government departments. He specialises in developing and implementing information security governance and compliance frameworks using national and international standards to help organisations improve their security posture.

I have analysed the differences between v1.0 and v1.01 and found that only two controls have been updated. There are a small number of minor corrections. The following provides a list of changes:

• A blank page has been inserted following the front page;

• The Foreword has been slightly reworded and signed by the new Director of GCSB;

• The table of contents no longer includes itself;

• p65 the double full-stop has been remove at the end of  the control How to report a cyber security incident to GCSB;

• p129 the last bullet point in the Context section has been reworded from “another DSD approved evaluation” to “Australasian Information Security Evaluation Program (AISEP) approved evaluation”.

• p130 the first sentence for the Recognition arrangements statement in the Context section has been changed from “DSD has a number of recognition arrangements regarding evaluated products” to “The AISEP programme has a number of recognition arrangements regarding evaluated products”. In addition to this the not in the second sentence has been made bold.

• p222 the Area security and access control statement has been changed from “Areas in which cryptographic system material is used should be separated from other areas and designated as a cryptography controlled area”  to “Areas in which cryptographic system material is used should be separated from other areas and designated as a controlled cryptography area”.

• p268 the last row of the table for the Firewall assurance levels statement has been changed so that agencies are required to use EAL4 not EAL2 firewalls to connect two networks classified at Top Secret in different security domains.

“Posting personal information on the Web

System Classification(s): R, C, S, TS; Compliance: recommended

It is recommended that personnel undertake a Web search of themselves to determine what personal information is available and contact an ITSM if they need assistance in determining if the information is appropriate to be viewed by the general public or potential adversaries.”

Obviously the NZISM applies to NZ Government departments and agencies and I doubt too many would have implemented a policy that requires staff to Google themselves on a regular basis. However, I am interested if anyone in either the public or private sector has implemented this control and whether it has actually revealed anything that resulted in an information security incident.

I configured a Google Alerts search that automatically searches for terms I have specified (e.g., my name and the company’s name) and sends me an email if it finds any matches. However, I must confess that I did this for marketing, not security, purposes after reading Mitch Joel’s Six Pixels of Separation.

So does your company require you to regularly “Google” yourself for information security reasons? And have you ever found anything posted about you that required you to take action to have the information removed?

For many businesses it is their reputation that is the most critical asset for them to protect. Without their reputation, they will lose their existing customers and won’t attract new ones, at which point it doesn’t matter whether they have the most wonderful technological solutions in place or something really basic.

Financial considerations typically feature fairly high on the list too – PCI compliance is a fact of life for many companies and if not properly addressed can result in large fines if their customer’s cardholder data is compromised. However PCI compliance does not mean that all a businesses security requirements have been addressed. While its strong focus on securing card data may provide adequate protection for other assets, it does not ensure that all relevant assets are protected to a level commensurate with their value.

For others what is important is agility – how easy is it to integrate new businesses they acquire (without compromising the security of the existing or the new business), or remove ones they divest.

I have had conversations a number of times with people who can’t, or are not willing to, understand that an Enterprise Architecture cannot be fully developed without considering the businesses drivers and requirements for security. There appears to be a feeling that although an Enterprise Architecture is fundamental to medium to large sized organisations and needs to be addressed in order to provide a consistent and supportable framework for new application development projects, security can be tackled at a project level. “We have our network and firewall – we’ll just plug into it like the others systems do.”

The SABSA framework provides a structured approach that considers all aspects of the business in the same way as the Zachman, TOGAF or other similar frameworks approach Enterprise Architecture. Because it is closely aligned with Enterprise Architecture approaches, SABSA works well beside them. The ability to trace requirements through to deployed solution and from deployed technology back to business requirements is fundamental to ensuring that actual security requirements are delivered and that nothing is delivered that doesn’t have documented requirement. This provides a framework against which the performance of business security solutions can be measured and evaluated in terms of a return on investment proposition. It also ensures a consistent approach to security, managing the risk landscape while avoiding reinventing the wheel for each new initiative that comes along.

You can download a PDF copy of the NZISM from the GCSB website.

The term “best practice” is thrown around by IT professionals to justify their recommendations. However, the use of the word “best” is a very bold statement. To state that something is “best practice” implies that nothing else is equal to or better than the practice being presented. It also suggests that it has been independently evaluated using a published and repeatable research method against competing practices and determined to be best.

In my opinion if you use the term “best practice” you better be able and willing to provide evidence that your assertion is true. Whilst many IT management frameworks claim to be best practice there is very little independent research published to support their claims.

I think one of reason IT professionals use the term so frequently is that managers and clients want to know that they are doing is the best thing possible. However, the fact remains that the use of the word “Best” has a specific connotation which is usually not backed up with evidence.

The issue is compounded by some ICT management frameworks that insist on claiming to be “best practice”. Typically these claims have not been empirically tested by an independent party so cannot be substantiated. However, businesses change, threat landscapes change, tolerance for risk changes over time. Even if a practice were to be validated as the best possible practice today, it does not necessarily remain so in future.

To be fair most people mean “good” or “industry accepted” practice when they use the term “best practice”. However, I think it is time that IT professionals actually used the appropriate terminology to support their recommendations. I stopped using “best practice” over two years ago and it hasn’t stopped clients adopting my recommendations. I use either “good practice” or “generally accepted practice” depending on the context, and where appropriate I provide evidence to support my assertions.