General security

A Post-Compliant World? – Part 1

John G. Laskey
December 19, 2018 by
John G. Laskey

Over the next three articles, we will consider the past, present and future state of infosec compliance. Please note that these are personal views, not necessarily shared by past employers.


My security career began at a time when data security was just a niche subject of little concern to anyone other than specialists. It has bridged to the present, when everyone has to be concerned about their own information because anyone, anywhere is now a potential threat to it. Between these two extremes the attempts, particularly by governments (I worked for one) to ensure compliance were utterly transformed – to the extent I believe we now live in a post-compliant age.

What should you learn next?

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

In this new world, security will always have to play catch-up with the latest security incident, to the point that the emphasis must shift from identify/detect/protect/respond to recover.[1] I hope you’ll agree that it’s always useful to sometimes look back, so we can more effectively learn lessons for the future. We must do as much as we can to avoid the same traps of complacency and over-protectiveness that I believe were features of infosec for years. We need to learn to stop fighting the last war.[2]

A Short History of Security

I started security compliance checking during the mid-1980s, before the word “infosec” was ever heard. My job during those years was about “physical and documentary” security, a simple world where standards of compliance were quite easy to judge: the doors were locked, check; all the papers on a file were there and any copies were accounted for, check. The keys to cupboards and doors were all in place, and everyone in the office seemed to understand what they had to do to keep things secure. As if to underline this simple, unchanging environment, our compliance reports were pre-printed, needing minimal additional text to describe our findings.

The earliest approaches to computer security (as it was then called) were based on tried-and-tested models set upon principles of defense in depth, of having “trusted” (i.e., specially trained and motivated) users and building secure data centers inside thick walls (which could incorporate all of the preceding).

From around 1990, I started to notice more computer systems in offices. But this was still pre-Internet, and mostly a pre-networking age. These computers were rarely networked, and their screens were mostly green. I did not see any real attempt to reconcile this emerging world of stealthy data creation to the reporting and compliance models that had been around for years. Also, there was still no computing power inside the average home and none on phones. This meant nobody had to think about computer security outside the relative security of an office. “Telecommuting” was not yet a word.

The tried-and-tested methods used to account for papers and keys continued to be applied to removable media such as floppy disks, which at that time held minimal amounts of data by today’s standards. A 5.25” floppy could not hold much more than 1 MB of data, or just over 500 pages of text.

But the growth of office systems and a lack of understanding about how easily electronic data could be lost and stolen – and how computer viruses could now wreck the information and the hardware and software used to produce it – led to security staff looking for new ways to counter these threats.

The next attempt to get to grips with all this was to create security policies. Tailored to specific systems, they were intended to get office managers to take responsibility for security by methods such as asking them to sign off the (sometimes very complex) procedures. To codify all actions needed of system users to keep the system secure, simpler (but often overlong) operating procedures (SyOPs) formed a subset of these policies. For example, SyOPs would tell users how to make up passwords, how they should lock away removable media, instruct them not to use unauthorized removable media and so on.

The words were certainly all there, but they did not make sense to most people. The concepts of computing were often very new to many users, not yet taught in any classroom and obscured by over-complex terminologies and processes.

With hindsight, I can see the missing element. That element was any sustained effort to update the consciousness of users about the new truth: Information could now be replicated and distributed invisibly. It could no longer be controlled by any of the physical methods long used to oversee the security of documents and workspaces.

Paradigm Shift

The next noticeable phase came around the mid-1990s, when office networking made these imperfect security responses even shakier. The initial response was simply to increase the length of system security policies (and calling them “network” security policies), which made it even harder for the average office worker to grasp what they had to do to protect information. The increasing complexity of the technical drafting needed left security officers with even less time to assess the effectiveness of security measures. And building anything without assessing its effectiveness is a recipe for failure.

A major attempt was made to tackle this by shifting the emphasis of the security officer’s job towards checking a system’s operation against the security documentation. The documentation would now be produced and owned by the information owners, who could turn to outside consultants to produce it. This process, called accreditation, is difficult to define in simple terms but was basically an honest attempt to apply audit and assurance to existing procedures. It included – for the first time – elements of risk management, i.e., system owners would now “own” and take responsibility for any risks identified by the accrediting security officer.

This shift did allow infosec staff to step back from drawing up procedures for other people’s systems and enabled them to reposition themselves as commenters upon the effectiveness of procedures proposed by system designers and managers. These changes roughly coincided with the growth of the Internet for business, using new technologies that also introduced new vulnerabilities.

The details of these changes are less important than the security mindsets they uncovered, for people who were in their own way still fighting the last war. Early in the office automation revolution, security officers sometimes stood in the way of progress to forestall security difficulties.[3] In the pre-infosec age, I had got quite used to security viewpoints taking precedence, but this was a new world, where security really could stand in the way of success and of progress. Continuing advances in office technology, and the eagerness of the office to exploit them, set up repeating conflicts between those charged with security and those directed to ensure progress.

But it was the business need to use the Internet (and “secure” Intranet services, which used Internet technology but did not have direct links to the Web) that finally destroyed the model of security as an impregnable castle.

It took extra efforts to reform the approach to security learning required for infosec. Security education was rooted in a time of just reading materials, not practical lessons or “see-it, do-it” approaches. More importantly, it was now necessary to tell employees about the risks of their use of infosec in a world where there was little or no constraint upon their use of the same technologies outside the office.

Accepting and Moving Forward

From the early 1990s to the mid-2000s, I saw infosec compliance change from imposing risk-averse approaches to applying risk-management solutions. This went along with a growing realization that any government-imposed models of security were “virtuous, but self-defeating.”[4] It also became clear that the application of technological solutions did not “cure” security problems but were at best a pill to manage them. All these things were hard for security people who had developed their skills during the 20th century to swallow.

Yet acceptance of these points was key to managing the rising tide of data usage. It was especially difficult to convince more experienced security officers that the new paradigm was essential, not just from a desire to automate but for economic progress.

In my next piece, I’ll review the problems for security through the normalization of IT, the constant change of threats and the pressure through legislation to “do something!” about infosec problems.



[1] The five Core Functions of the current (2014) NIST Cybersecurity Framework. See

[2] A notorious example: World War 1 had taught France the importance of entrenched defenses. To deter the next war, they built the vast entrenchments of the Maginot Line. The mobile German army of World War 2 simply stepped around them.

[3] An example, from memory, was cautioning against enabling some “mobile code,” an honest attempt to prevent system intrusions.

[4] Quote from former NSA and CIA Director General Michael V. Hayden, speaking at the Billington Conference, Washington, DC (September 2015)

John G. Laskey
John G. Laskey

John Laskey is a US-based security consultant who previously worked in the British government, where he was responsible for securing systems and advising senior managers about major programs. In the US, John has taught the ISO 27001 standard and is now helping develop and market new InfoSec products and services. He is a member of ISSA (New England Chapter).