Open Access To Anyone

The subject of document security is one that evades logic when it comes to what is published to the web for public consumption – why? In the last year I have spoken and consulted with multiples of organisations and government agencies in the UK, EU, and US, and have noticed that, when it comes to document security, many have one thing in common – they don’t do it! However, when I raised this recently with a CEO, he responded ‘Why should I care, after all its just public information, and when it comes to securing it, there is very little point’ – Indeed and interesting point of view, but sadly, one that is shared by many.

OK, so to cut to the chase, let us recall those three letters [CIA] which we as Security Professionals so often refer to:

So, first of all, let us consider ‘C’. Here there is no issue whatsoever as the documents [asserting they have been correctly released] are in the public domain, and have thus been deemed fit for consumption by that readership. Next, let us look to the last element of ‘A’ – again, not a real issue other than if the related hosting site or systems are down. And that leaves us with the middle consideration of ‘I’ for Integrity, and it is here where I feel our focus in this instance should reside.

So, taking a step backward to ‘not really caring’ about the security of documents that are published onto the web, I would like to present the case as to why this is such a very bad practice in terms of Integrity [leaving to one side the other associated dangers of Metadata, and hidden content – that is an article for another day].

The first Artifact I wish to present is that of the recent release of the very important, and emotive PDF document outlining the case of Scottish Independence. Not only was this document release with complete access to its content accommodating any manipulation [See Fig 1], but within 1 hour of being released it had been hacked, secured [See Fig 2], and recirculated on the Internet.

Fig 1 – Open for Manipulation

Fig 2 – Hacked but Secure

Artifact two is the insecure PDF document which was published by a well-known city brand. Again, having been released as an insecure PDF the company was unaware that it had been subjected to a subtle change in relation to its content, and that it had been extensively published onto a global readership with some very misleading facts – only to become visible at such a time the content had caused embracement – in this case the subtle adjustment to some contained numbers had most certainly uttered an impact on the integrity of the document and its contents.

Ant the last Artifact I wish to present for the case of document security relates to the association of malicious content, embedded links, and other such code of a potential malicious nature such as JavaScript. In this case we encounter yet another insecure PDF document, but on this occasion the intent was to manipulate its content into the guise of a PDF Trojan horse. The document in question had been amended, and had been fashioned to include some additional URL’s, which pointed off to a site carrying active and very malicious content to infiltrate and exploit vulnerable machines. However, to make matters just a tad more serious, the associated malpractice had been committed as an insider attack, and as such the document in question was actually hosted on the company’s main web site, and was not noticed until such time it had caused some damage to a number of important client sites.

So there are my three cases out of multiples for doing document security, and having a related standard/procedure deployed.

To close, yes, I agree that anyone can produce a falsified document – but my argument here is still nevertheless, that is no excuse to use such an argument as a reason not to do the right thing, and thus by association make it so very easy for the attacker. In fact I would urge here that any organisation who published documents [in any format] to the web, consider the additional measures which can be applied in the form of Digital Signing, and applying a security policy to the end products. Granted this will not serve 100%, but then nothing does – but we can at least try.

Professor John Walker  FMFSoc FBCS FRSA CITP CISM CRISC ITPC

Visiting Professor at the School of Science and Technology at Nottingham Trent University (NTU), Visiting Professor/Lecturer at the University of Slavonia[to 2015], CTO and Company, Director of CSIRT, Cyber Forensics, and Research at INTEGRAL SECURITY XASSURNCE Ltd, Practicing Expert Witness, ENISA CEI Listed Expert, Editorial Member of the Cyber Security Research Institute (CRSI), Fellow of the British Computer Society (BCS), Fellow of the Royal Society of the Arts, an Associate Researcher working on a Research Project with the University of Ontario, and a Member, and Advisor to the Forensic Science Society