ISO/IEC 27001:2013. A Sonnet on Security
Would we at dawn of work be unprepared?
Our keys should each and every door unlock?
That none would know the gems we common share?
The scoundrel 'round the saint works in the dark.
We write to them but prying eyes surmise?
The watchful eyes ne'er strive to view our walk?
The bells would ring and not a guide arise?
They speak though none but truth shall pass to talk.
We know from whence we press our endless fight.
The lines are drawn for all in unity.
The lucent boxes’ gears ne'er turn in sight.
And hand in hand our steps a cadence be.
That which we craft or trade for burden borne.
And not from single thread our patchwork form.
So why a sonnet? Even from antiquity, there arose a discipline in the poetic form to honor structure as much as narrative. Technically speaking, you could write a sonnet with 7 words. It would certainly honor the structure but wouldn’t move the reader much. When we have conversations with clients about security standards, laws, and frameworks, it seems like we’re starting from that point. Granted, we have developed our own language for information security, but to the uninitiated, it seems like all structure and no narrative. In truth, the frameworks are meant to develop a narrative about how a given organization conducts itself to be more secure, for its own benefit. The first and largest gap to overcome in such engagements is to bridge the gap between the framework and the narrative.
It’s not an easy task. The first touchpoint for most clients is a realization that they must be measured against a framework. Perhaps a vendor has taken on a new client that requires partners to follow a framework to which they themselves are subject. Laws surrounding privacy and security of consumer data are also common requirements, as is the ubiquitous Payment Card Industry Data Security Standard (a.k.a. PCI/DSS) that anyone who accepts credit cards must consider. Regardless of the inspiration, the realization often leads to the inevitable second step: trying to read the standard and make sense of what it’s asking for.
There are many technical measures that are prescribed in these standards which gives rise to the common interpretation that technology is the answer. Technology is only part of the answer and that part has seriously limited efficacy on its own. The common goal of every security standard that exists today is that cybersecurity countermeasures need to be baked into an organization’s day-to-day activities at all levels. It seems unapproachable at first. Apart from IT, most of the organization is deterred by the tech-laden wording and can’t envision how to work such patterns into their day. But the reality is that looking beyond the structure and carefully crafted words, the narrative is approachable and the end state, attainable. Sonnet or security.
So, let’s examine how one carefully crafted work maps to the other. This isn’t an exhaustive treatment of the standard, obviously, but I hope you enjoy this walk through it. As a reminder, the first seven lines of this sonnet declare problems and as such are describing the absence of the appropriate controls; the final seven state the opposite.
Would we at dawn of work be unprepared?
Sections 5 and 7 of the standard (Information Security Policies and Human Resource Security) outline the practices that relate to preparing the workforce to perform their duties with security at the forefront. Section 5 reminds us that policies must be written to guide prospective workers in safe and acceptable practices. Section 7 lays out the framework for ensuring that these policies are presented and understood when new members join the workforce. It also prescribes actions to be taken when someone leaves the workforce, such as turning off access.
Our keys should each and every door unlock?
Section 9 (Access Control) deals with ensuring that each person is assigned the appropriate level of access to complete their job description, and nothing more. It also handles common problems such as the accretion of rights and privileged access management. Those two terms can be stated more simply. The former is the issue of retaining access to department A’s resources when someone moves to department B. The latter is the issue of someone that has access to their normal files but from time-to-time needs access to much more. Having a single account means that they have more access than is needed most of the time and as such are assuming too much risk, versus being assigned two accounts, one for normal use and one for privileged duties.
That none would know the gems we common share?
Section 8 (Asset Management) prescribes an accurate inventory of things like computers and mobile devices, how they are assigned, how they are recovered when someone leaves, how they are secured if stolen, and so forth.
The scoundrel 'round the saint works in the dark.
Section 6 (Organization of Information Security) reminds us that, among other things, there should be a separation of duties. That essentially prescribes that in any given process, there should be at least two people involved and neither can complete the process without the other, nor can either cover up their own actions or the actions of the other. In many cases, more than two are required for sensitive processes like payroll or money movement. This ensures that a single scoundrel cannot work around the saint, as the line states, and that collusion or – even worse – conspiracy is required to circumvent the controls.
We write to them but prying eyes surmise.
Section 10 (Cryptography) covers the protection of data in transit and at rest. Data here refers to files, images, and anything else stored digitally. “In transit” refers to how well data are protected against eavesdropping when they are being transmitted over the Internet or otherwise “out in the open.” “At rest” refers to how well data are protected when they are stored on a disk, laptop, or memory stick. If such a device is stolen, are the data readable by anyone with the device or are there additional protections in place? Section 10 covers these aspects of security.
The watchful eyes ne'er strive to view our walk?
Section 12 (Operations Security) outlines security measures such as auditing (watchful eyes). Auditing is a technical feature of most systems and networks, but in keeping with the holistic view of security, it also involves processes and procedures for alerting on or periodically reviewing audit logs and the steps taken if suspicious activity is observed, respectively.
The bells would ring and not a guide arise.
Section 16 (Information Security Incident Management) lays out one of the most important aspects of an information security program: what to do when security measures are breached. There are two important aspects of developing an incident management plan. First, it is useful to examine all the stakeholders involved in a response. Management, customers, vendors, partners, authorities, cybersecurity insurance carriers, IT, legal, PR, etc. Second, it is even more useful to do it deliberately when not under the direct pressure of an incident. Put another way, the worst time to figure out how to get out of a burning building is when it’s engulfed in flames.
They speak though none but truth shall pass to talk?
Section 13 (Communications Security) speaks to the “perimeter”, as we like to say. This is where your technology meets other technology in the wild. It happens at the devices that connect you to other resources in your office. It happens at the devices that connect you to the Internet. It happens at the servers that send and receive your email. An incredible number of external parties are trying to speak to you through the perimeter, but good security measures ensure that only the safe ones make it through.
We know from whence we press our endless fight.
Section 17 (Information Security Aspects of Business Continuity Management) highlights that an organization’s work (the “endless fight”) should not be subject to undue interruptions due to a failure of equipment, security measures, or otherwise. If a device is compromised, what is the user of that device to do? If a building is unreachable or uninhabitable, what are the workers based there to do? And if the data that runs a company is corrupted or otherwise lost, what can be done about that? These are the questions section 17 considers.
The lines are drawn for all in unity.
Section 18 (Compliance) ties together the security program, internal and external requirements. This concept is extremely important for a security program. It profits little to have a detailed security program in place and operating if it misses key industry or jurisdictional requirements that must be met in the context of an organization conducting business. One of the first tasks in crafting a security program is to take stock of all such requirements to ensure the program meets or exceeds them at a minimum.
The lucent boxes’ gears ne'er turn in sight.
Section 11 (Physical and Environmental Security) pertains to physical security measures that are as old as human dwellings themselves: doors and locks. It also extends to such physical measures as access control and logging, whether it is by a code entered at a door or a card swiped. It includes surveillance of those areas and monitoring of other physical threats such as a computer room that is overheated or being flooded. Handing off a great deal of the controls required of Section 11 is one of the most compelling cases for moving servers to the cloud, but the requirements are still just as important and do not disappear completely from the local office.
And hand in hand our steps a cadence be.
Section 15 (Supplier Relationships) stresses that no matter how well-developed a security program might be, its true strength is related to how well-developed the security programs of independent, yet interdependent organizations are. To address this, organizations require of their partners to attest to their own compliance with the standards to which they are subject. Being in lockstep (hence a cadence) is the only manner in which one organization’s security practices can prove to be effective in today’s connected world.
That which we craft or trade for burden borne.
Section 14 (System Acquisition, Development and Maintenance) states another aspect of security being as strong as its weakest link. Specifically, it requires that any systems that are developed or acquired by an organization be inherently secure. Good examples of this are a customer information system. Regardless of the industry, everyone stores data on their customers. Is the system home grown? Or is it a third-party package that is purchased or subscribed to? Regardless of its genesis, its capabilities must include the ability to fit into a security program. Imagine a system that has all of the features a company could want, but with weak security features that mean everyone has access to everything, can change anything, with no audit trail or trace of evidence of what they did, and holds data that cannot be backed up. Such a system is absurd to imagine, but there are many security deficiencies in solutions today that represent unacceptably large holes in an organization’s security program.
And not from single thread our patchwork form.
You caught me. There are no more sections to the standard. You’ll note we doubled up on the first line, which makes room for this last line. Arguably the most intrinsic concept to an effective security program and why ISO/IEC 27001:2013 has 14 sections and over 100 controls is something we call defense in depth. It is the guiding principle that a single threat should not be mitigated by a single control, but rather a series of controls that overlap. It’s found in firewalls that stop viruses ahead of email servers that stop viruses ahead of email programs that stop viruses. It’s also found in the user behind the keyboard of an email program that has been trained to spot a virus, should one get through. It is the interweaving of all of theses measures into the day-to-day life of those of us who work and live online, which is almost everyone lately. It is fitting to end with a line that essentially points to every line that precedes it as mutually required, related, and reinforced.
So, there you have it: ISO/IEC 27001:2013. A Sonnet on Security. Of course, I could have named it something a little catchier, like The Thwarting of the Marauders or perhaps Arise, O Shield of Ether. But that’s apparently just not as melodious to tech folks like me as six letters in two acronyms, plus nine digits for flavor.