Document Security Certifications

Document security solutions, certifications and systems redundancy.

Are security certifications and systems redundancy all they cracked up to be?  Quality standards may tell you about the process but not about the implementation and updates will render previous certifications invalid.

Document security and IT security certifications

A great deal is made these days about certifying business processes, including security ones.  Having well documented procedures and processes may be part of the licensing requirements for a financial institution or a nuclear facility development.  And perhaps the grandfather of the management documentation system standards was the introduction in 1979 of the British Standard BS 5750 for ‘quality management systems’ later to become ISO 9000.

This introduced the idea that confidence in a product could be gained from using an approved quality management system and quality manuals.  But what meaning should be taken for snapshots of documentary processes in the realm of IT and document security systems?

IT Security quality standards

In the IT Security world the USA Department of Defense developed in 1983 the TCSEC – this looked at how you could assess the effectiveness of computer security controls built into a computer system.  This was followed in the 1990s by the ITSEC developed in Europe.  These were replaced by the ISO standard ‘The Common Criteria for evaluating security systems’, which developed the idea of Evaluation Assurance Level as being the depth and rigor of an evaluation against the security claims made for the security target of evaluation.  It does NOT say the security is better the higher the level, but that the claim made is that is has been better evaluated.

The problem with the certification process is that it is essentially a paper based analysis where the process(es) to be followed are documented and then checked to see that the process(es) can be followed.  What it does not do is say if the process(es) link together to form overall effective security.  We may not be able to see how well evaluated the security functionality was.

So what can go wrong with the process?

1.  Incomplete specifications for document security processes

So take for example the following document security method – a file is to be encrypted with a symmetric key which must travel with the file.  The cryptographic modules are certified as being suitable.  The software code is developed according to standards which are suitable for applications development.  The process is documented.

However, nothing is mentioned about the protection mechanisms for the key, and if they work, and how they are verified, whilst protecting the cryptographic mechanisms will have been addressed very thoroughly.  Further, higher level protection mechanisms including code obfuscation and encryption or even running virtual machines to carry out commands and protect data (especially personal data) may have been used but are likely not to be documented.

All of these things may be mentioned as options in a document protection scheme but are only found by verifying that they are both present and properly configured.  And they may need provision for testing in a variety of environments because some anti-virus products report protected programs as rogue because the same techniques are used by hackers to prevent their programs from being recognized and reprogrammed or removed.

2. Lack of evaluation

One of the most horrifying failures to implement and carry out best practice led to the collapse of Barings Bank in 1995.

A manger in Barings Futures Singapore was able to place and authorize purchases and sales in the stock and money markets, and was able to cause computer systems to report losses as gains.  This was against best practice, but was not picked up by either internal compliance or the auditors until far too late.

3.  Reliable Audits

It was reported in the Independent on 10 July 2019 that, “Overall, only 75% of the sample of audits from among Britain’s 350 largest-listed companies for the year ending December 2017 met quality standards.”  That is not to suggest that audits themselves are of no value but to note that they may not always report on every situation or challenge management sufficiently.

Auditors may also have to rely on internal ‘experts’ to help them understand the systems in place and of course the information given could be biased.

4.  Product updates and changes

Perhaps the greatest enemy of any document security system or IT system is change.  Any WordPress site manager gets used to the regularity with which updates break previously perfectly sound systems without any warning, affecting both the main site functionality and the underlying security. If you share PDF files with clients securely using WordPress plugins, for example, then an update to WordPress can stop that plugin from working. So, there are even greater effects when Operating Systems and their components are updated.  When considering document security systems these are two aspects that are critical.

The impact of change of user functionality can lead to security failure – being unable to prevent printing a secured document, for instance, can be catastrophic for application system security even if the SSL technical controls work just fine and make sure the document is not falsified.

Changing or upgrading the version of PHP used in a server can have unforeseen consequences simply because of the complexity of testing security functionality is time consuming and therefore expensive as compared with the approach of putting it in and seeing what happens (suck it and see), which one can argue is what UAT testing is about?  Most applications manufacturers have some reliance on end users finding errors because there are many more people focused on the task.

Security certifications will no longer be valid once either the document security software or a system on which it runs are updated since even minor changes can have significant unintended results.  This is especially true when relying on plugins and browser environments which are highly vulnerable to application and operating system updates.

Does systems redundancy make up for testing?

Availability, sometimes part of a Service Level Agreement, is a difficult topic which comes somewhere out of risk analysis and business requirements.  High availability is considered the desired application goal even if there is no document specifying what that means in terms of equipment which you can install and control and systems where you cannot.

Chief among these things you can control are firewalls and routers and servers.  So you can make hay while the sun shines and put in redundant hardware and failover switching until the cows come home.  And hope that on the day it all actually happens according to very carefully tested plans – which need documenting rather a lot!

Chief among the things you can’t control is the public Internet, which is where things are very different.  As happened in the early lockdown phases of Covid-19 there was a massive move to using public Internet connections as the carrier for commercial infrastructure.  This put the Internet under tremendous strain and systems experienced response difficulties they had never thought about (only to find that no amount of redundancy or failover would solve this problem).

If you have ever experienced DNS cache poisoning (where bad DNS IP addresses get propagated into the DNS replication mechanism and are distributed) then you know how easily systems can be affected.  For a day or so getting to some web sites will be hit-and-miss depending on which ISP you connected through as to if you got the right connection or not.  There is no hot-line to contact and you have to sit and wait for the Authoritative Name Server admins to fix it.  And no, you don’t have redundancy hardware for that.

And finally redundancy may not work as planned.

Back in April 2004 Computer Weekly reported that a fire in a BT cabling tunnel in Manchester England took out telephones, faxes and access to networks including mobiles for 130,000 businesses, and the resulting loss of capacity had impacts 100 miles away from the disaster location. Although buildings were not affected disaster recovery plans were activated which also involved major businesses and call centres because there was no way of getting circuits restored and re-cabled quickly.  The conclusion is that everyone thought they had redundant systems and connections, but found out maybe not.  No amount of quality standards at the applications level could ever allow for the unplanned – like a bomb going off in the City of London taking out the office infrastructure but leaving the telecoms alone.

Conclusions

IT Security Certifications may help manufacturers focus on security points that may have been missed at the design stage, and that can be valuable.  But certifications do not tell the whole story.  Just as important is the web history of the results of attacks against the security application since hackers like to prove a point.

Also errors become part of history and often have to be supported.  On 17 May 2020 Wired published an article over shortcomings recently found in PGP, the biggest file encryption security program of all.  It commented, “One of the many problems with PGP is its age, says Green. It was first developed in 1991 (“when we didn’t really know anything about crypto”) and then standardized into OpenPGP from 1997.  The science of cryptography has advanced dramatically since then, but PGP hasn’t, and any new implementations have to remain compatible with the features of previous tools, which can leave them vulnerable to similar exploits.”  Adobe has a similar problem with PDF password protection.  So when certifying document security solutions, do you include history that has to be supported?

There is a danger that redundant systems turn out to be just that, and not sacrificial defenses.  Rather like certifications, you need to understand what the claims are, what versions of a system they refer to (and the versions of the underlying architecture) and how well they have been evaluated.  Always remember Gilb’s hypothesis, “fixing one bug in any application creates two bugs, only one of which is likely to be found.”