security — Savva Pistolas

The Launch of ISO27001.zip

2024-05-28T00:00:00Z

On Thursday I launched my new project website iso27001.zip, a website containing a collection of notes on the International Organisation for Standardisations’ management systems standard on Information Security Management Systems (ISMS) - ISO/IEC 27001:2022.

It’s a non-commercial venture that’s aiming to make documentation and exploratory content about ISO 27001 more accessible and engaging for both veteran users and newcomers alike, in the hopes that more people will engage with this standard as the cybernetic masterpiece that it is. In this brief reflection, I chat over my experiences with this standard, and how they led me to want to build the site…

If this subject matter is new to you - check this out.

😀 TL;DR - I love this thing, I’m hoping to build something that makes more people love this thing.

First eyes on ISO

The standard is not unique amongst it’s neighbours in the management systems standard world, following the same harmonised structure that most others do; it is instead my specific experiences that drew me to the standard and eventually developed my desire to write about it. My first exposure to the standard was many years ago in University, when my Applied Cyber Security BSc introduced it to us in our governance and risk management module. I was originally baffled by it, but soon became enamoured by the battle-tested tapestry of mutual dependencies that made up this document. Clearly, some thinking had gone into this! I enjoyed it primarily as an exercise of theory and was taught that the standard was an ideal match for larger organisations that could provide discretionary funding and make dedicated recruitment and staffing decisions.

My output at University challenged this assertion that the standard only had usability in the world of big enterprise - I had found that the Information Assurance for SME Consortium (IASME) had mapped the standard roughly across to some of the efforts it was taking to make accessible cyber security frameworks in the SME space. Further, I myself had used the standard to successfully conduct a gap analysis on both a real SME and a business component of the University - successful enough that both could make impactful changes to their body of policy based on my feedback. It was the first time I had been able to practically translate some best practice guidance to meaningful, context-informed advice, and to do so in an explanatory and justified way. It was very rewarding.

ISO had clearly made efforts to try and make sure that the standard was vendor agnostic, and some very friendly, knowledgable people in industry had informed me that it was more than possible to use 27001 for improvement within SME, and so It was clear to me at this stage in my pre-career that the inaccessibility wasn’t in the design of the body of the standard but in the accessibility to the means by which its learning could be applied. I had been able to act as the interpreter of the best practice guidance, and provide meaningful guidance with unquestionable provenance, but clearly I had added value - It wasn’t simply transliteration from standard to direction.

I had received some fantastic education on the context of the standard itself, where and how it has been useful, and what a practical application of it actually looks like. This was my induction. From here it was an easy move to start to develop the information security risk management version of ‘common sense’. This part of my experience wasn’t a component of the standard itself; it wasn’t required reading. It came as my network and experience grew (let me say here that it is certainly still developing! I continue to be humbled by the fantastic experiences I encounter), and I believe the development of this ‘common sense’ is also the development of a blind spot if we do not pay careful attention to it. To those who don’t have ready access to the language or understanding that comes with these interactions and experiences, the standard can feel like a very alien thing to ‘work’.

The problem

The seemingly ethereal nature of the standard that exists when you don’t have a practical base to build it on (or someone to point at it and explain it) resonates with a lot of friends’ understanding of ISO management system standards (MSS) such as 27001. They are instruction manuals that aren’t attached to anything - an ever undecipherable IKEA step-by-step for something that doesn’t tangibly exist. I understood this position: building systems of work involve trying to capture and document interpersonal relationships and expectations (or as the management theorists who don’t do hugs would like to call them: Psychological Contracts). If your organisation isn’t one of coercive control and you find value in working with people who share your strategic objectives (vital in the not-for-profit space) then it’s necessary to find meaningful ways to share goals and objectives at the institutional level and derive our operation from this common understanding.

If that first olive branch of teaching and understanding isn’t extended to help you explore the standard in practical terms and then work back towards the theory with a well-developed common sense, then you’re unlikely to see the potential of the standard and relegate it to the whopping great pile of boring insurance-satiating box ticking exercises that cause arguments in all-hands meetings.

Heading to work

What little doubts I had of the practicality of the standard were dashed as soon as I hit industry - we successfully and frequently used ISO 27001 and its sibling for business continuity management systems: ISO 22301:2019, to assess whether the body of policy for smaller organisations actually met up with the processes and procedures that informed their normal operations.

Time and again we would be met with policy that was utterly disconnected from the purpose it was supposed to serve and had no clear connection between expectations/responsibilities placed on workers at all levels, and the strategic objective of the organisation. I derived immense satisfaction and engagement from identifying clunky or broken policy, stripping back the corporate jargon, comparing with the relevant clausal requirements - adjusting for context, and then preparing considerations for our client to take home with them. We had 100 percent positive feedback, and without fail we provided value. The system worked.

Badged up

Under the watchful guidance of my seniors at the time, I picked through dozens of these case studies, it became clear to me that I wanted to formally concretise the knowledge base. I was supported to become an ISO 27001 Lead Implementer - attending a week long training course followed by an examination which I passed. It was a very hands-on course, and I was attending alongside people who weren’t here to learn for the sake of learning (as I must admit I was), I was joined by people who needed practical understanding of the standard to take home. We had workers from internet service providers, freelance consultants, taciturn defence contractors, and middle management six-sigma black belts.

Putting aside the awesome industry stories we got to hear from all in attendance, and the outstanding trainer we had, I was left hoping for more of a nuts-and-bolts approach to decompose the standard and understand it from a theoretical perspective.

This was the inception of the idea of the website - if hands-on expertise in application and implementation (which comes in many shapes and sizes) is a requirement to understanding the standard, then those who are not directed to use the standard or have access to a colleague who can successfully inspire, are unlikely to naturally stumble into it and find it of interest. I had experienced a unique blend of academic exploration followed by attentive outcome-focused industry application, all under the watchful eyes of some very impressive people who had been doing the work since before I was born - and were applying this expertise in the not-for-profit space. An avid notetaker, I decided to keep track of my efforts and try to write accessibly and without stripping away when I was excited about a certain area, hoping that I would have enough of a body of interest in the subject to produce something at some point.

And so…

I then proceeded to completely forget about the idea. I slowly accrued notes and made supportive diagrams in my own time that consolidated my understanding and satisfied my interest in the standard, wrote a few blog posts, and a service methodology for our ISO informed gap analyses at work. There was no meaningful catalyst that pushed me to structure and publish the site, it was the spring-cleaning of my Obsidian vault where I stumbled across the initial idea in a note and took stock of what I had to share. I had enough to launch it as a public facing work-in-progress!

And here we are. I’m only currently sharing about 30% of the total content and notes I hold on the 27001 standard (and a lot of this bleeds into other areas). This is because a lot of what I have is only really useful to me because it jogs my memory - it isn’t useful standalone. My list of content to add to the site is long, and I am looking forward to watching it organically grow in the coming months and years. I love being busy when it’s with work I care about, and the most enjoyable part of launching a project is that it isn’t the end, it is the beginning!

If you’ve gotten this far, and you enjoy the site - why not contribute? Make the standard more accessible and get a writing credit by sending me the body of your contribution!

A Lapsus$ in judgement - The sacrifice of Arion Kurtaj

2024-01-31T00:00:00Z

As always, this website plays host to my opinions which are informed by my understanding of the facts available to me and the wisdom of the people around me. This article may be updated or amended in the event that new information comes to light.

Introduction

With a roster of attacks against Microsoft, Uber, Samsung, Nvidia, Ubisoft, and Rockstar Games, the Lapsus$ hacker group has become infamous for it’s outrageous smash and grab tactics that have impacted industry giants across the globe.

The group’s members were, for a time, exclusively minors. They worked together on many majorly covered cyber offensives. The end of the story seems to be the indefinite hospital order placed on Arion Kurtaj - now turned 18, after he hacked Rockstar Games from within police protection at a Travelodge using an Amazon Firestick, a mobile phone, and the hotel TV.

The news cycle has enjoyed sharing headlines expressing awe that a teenager could hack a huge organisation using such unorthodox and limited hardware. I would like to make some space to critically reflect on the veracity of these claims, and explore whether this hack really is the MacGyver mastermind hack that it’s being lauded as. Underlying this exploration will be considerations of the various structural and personal interests that might seek to oversell or ‘sex up’ this series of attacks from the group.

The group

If you haven’t heard of Lapsus$, here is a quick briefing on their activities: Lapsus$ was a hackergroup based out of Brazil and the UK that was known for 11 major cyber attacks, all of which revolved around a similar modus operandi of gaining access to a corporate network by acquiring credentials from employees.

Once credentials were acquired, the group could begin accessing the network. Having gained access, the attack was as simple as downloading whatever they could get their hands on; deleting the files on the client-side; declaring their triumph in a 50,000 member telegram group channel; and stipulating the terms of the extortion attempts against the organisation they had successfully targeted. That’s it. The reason the account of their methodology is so short is that it is simple and repeated. Lapsus$ don’t really know how to pick locks, they tend to just buy the key.

The group was comprised of seven people aged between 16 - 21, with the generally recognised leader being Arion Kurtaj - who was 16 when acting most prominently in the group. Arion has since been arrested and is currently on an indefinite hospital order. An additional 7 other members have been arrested by the City of London Police. A Brazilian citizen has also been arrested under the accusation of being a member of the group.

The process

When the group was on their first major spree in 2022, I remember learning about the straight-forward nature of their attacks. Their process of accessing, exploiting, and extorting is actually quite a simple one. Despite the simplicity of the process, it nonetheless successfully attacked global giants like Nvidia, Samsung, Ubisoft, T-Mobile, Microsoft, and Uber.

Described by Krebs as “Low tech, high impact”, the Lapsus$ group employ solutions such as SIM swapping - where the attacker convinces a phone service carrier to switch a target SIM over to a new physical SIM to provide the ability to do text based multi-factor authentication. This, combined with an employees password, grants Lapsus$ access to their target network.

They’ll also happily just buy access to networks, purchasing access credentials from the internet, and also engage in plain old open recruitment on their telegram - saying they’re ready to pay employees to give them access to their corporate accounts:

(Figure 1. Screenshot of an ad recruiting employees to give out access to their employer’s network from Microsoft’s “DEV-0537 criminal actor targeting organisations for data exfiltration and destruction”)

The revenue stream to fund the acquisition of these access credentials is drawn from employing the same strategy on individual accounts at cryptocurrency exchanges. The group likely use the SIM-swap method to access accounts and then drain holdings, in addition to any extortion payments made by their victims.

When access is acquired, the group don’t deploy malware or ransomware - which is what sophisticated threat actors might do to secure persistent access to the network for later use. Lapsus$ instead opt for what Microsoft classifies as “Exfiltration, destruction, and extortion”. This is simply downloading everything that they can get their hands on and deleting it after the download completes. This dataset then forms the basis of their extortion attempts.

Microsoft, in their debrief on the tactics, techniques and procedures of Lapsus$, provide some interesting insights that involve light analysis on the strategy and behaviour of the group; one such insight is that there is a clear streak of apathy towards operational security or secrecy in Lapsus’ ranks, with very little effort made to protect the identities or ongoing operations of the group.

Indeed, Microsoft was actually able to stop the group from downloading source code during a live incident because Lapsus announced it to their telegram channel prematurely while the attack was ongoing.

The group also enjoyed ‘embellishing’ the impact of their hacks to their channels. During their attack of security service provider Okta the group created and circulated strategic screenshots to lie about the extent of the systems they’ve compromised.

This was the clearest indicator that the perpetrators were young and excitable, and not an advanced threat actor like a financially driven criminal organisation or state actor. The group are motivated by impressing and awing their audience, sometimes to the extent that they sabotage the entire operation by announcing it to 50,000 people halfway through it.

The intelligence was quite unanimous quite early on that Lapsus$ were a group of teenagers utilising simple methods to conduct high-impact attacks, that manage to end up sabotaging themselves with their juvenile excitement. Furthermore, they argued with one another, as teenagers tend to - with the results being that Arion had his name and address leaked by one of his peers in his cyber circles. This is the behaviour being grandiosely characterised by Microsoft, one of their prominent targets, as a “unique blend of tradecraft”.

The response

Microsoft produced a 4,000 word incident response and threat intelligence report on the group in the wake of their hack on the company, naming Lapsus$ as the ‘DEV-0537 criminal actor’ or ‘Strawberry Tempest’ using their new weather themed threat intelligence taxonomy. They explored the group’s behaviour and threats, and did their best to take Lapsus’ claims to pieces. The main success for Lapsus$ came as Microsoft still allowed telephony-based MFA (recieving a text message to authenticate yourself instead of using an app like Microsoft Authenticator or Authy) and so it was with great ease that the group could exploit this using SIM swapping.

The recommendation of avoiding using text messages for MFA was performatively publicised as guidance in the wake of the incident by Microsoft. This is a clear effort to make it appear as though we as a community are not already aware of this being best practice guidance that the giant was simply not following. Both the National Cyber Security Centre and the USA’s National Institute of Standards and Technology agree that telephony based MFA is inferior to other forms of MFA, and have done for quite a while.

It’s always important to remember that anyone debriefing an incident response on their own organisation has a conflict of interest and is incentivised to make an incident appear as sophisticated as possible. To do any less is to admit the failure to prevent a simple attack succeeding.

For clients and share holders, it’s never going to be very reassuring to read a press release from a multinational conglomerate computing giant simply saying: “We still use text messages for MFA, and a 17 year old called up our SIM provider and convinced them to move one of our secure phone numbers over to a new SIM so he could log in”. Instead, the profit motive will have exerted a large amount of downward pressure on Microsoft’s editorialising of their debrief. To this end, the release is packed with melodramatic language and focuses on the impact of the devastating blow leveraged by the ‘Strawberry Tempest’ threat actor in the wake of their social engineering efforts to collect “intimate knowledge about employees, team structures, help desks, crisis response workflows, and supply chain relationships”.

The last stand

Now we’re equipped with insight on the simplicity of the M.O. of Lapsus, and how their targets have been responding to their successful attempts to access their networks, we need to understand precisely how Arion conducted his infamous Rockstar Games hack. This will position us to assess how impressive it may or may not be and whether these Hollywood-esque headlines are being disingenuous.

Firstly, Arion had access to a mobile phone - this is already enough to conduct the hack. Phones are just small computers, anything he had in addition to this will have been a bonus, but not a necessity.

If we remember the Lapsus$ calling card of purchasing or engineering access using employee credentials, Arion may have simply used existing credentials he had procured ahead of time. Alternatively, perhaps he needed to buy some and so hopped onto an access broker forum or telegram page and paid $40 for some user credentials using stolen cryptocurrency. When he did leverage his access to the network he began to download files, which is usually accomplished by right clicking and pressing download - not by ‘hacking the mainframe’. When he was happy with what he had acquired, he deleted the files on Rockstar’s side. Finally, Arion entered the Rockstar Slack channels to announce his hack and make his demands. It appears that no effort whatsoever was made to hide that it was him conducting the attack, or to secure the devices he was using. It’s worth remembering that he was committing these digitally enabled crimes whilst in police protection and supervision.

Let’s play with another theoretical - perhaps the police disabled the internet of Arion’s phone and so he was left without internet in the hotel room. The Amazon Firestick is another computer left in the room with him, it’s just got more controls and restrictions placed on it by Amazon. How difficult do we think it would be to remove these restrictions? This is called Jailbreaking or Rooting. It’s easy.

Thanks YouTube, looks like anywhere between 5 and 15 minutes if you don’t know what you’re doing. A Firestick is just running the mobile operating system Android, and reverting it back to this state allows us to install web browsers, and other tools. Perhaps Arion connected his phone via bluetooth to the Firestick to use it as a keyboard and mouse.

There are a lot of potential ways that this final outcome of Arion being digitally empowered to conduct this hack could have occurred, and none of them are particularly outlandish in terms of raw technical skill.

The duty

I am left wondering why the police who have charge over a vulnerable young autistic man, who they deem to be an ongoing threat to the digital security of UK plc and it’s international friends, have left him alone in a hotel room with the exact hardware he needs to perpetrate another attack. We can see the lack of interest in operational security from Arion, we can also see Arion’s complete disinterest in the economic impact his hacks will have. Indeed, it is the intentions borne from this mental state that informed the decision to hold Arion in protection in a hotel. Why on earth did the police give a computer to the guy who said that he’ll hack again if given access to a computer?

Arion was actually deemed unfit to stand trial due to his severe autism, and it was this same mental health assessment that determined that he ‘continued to express the intent to return to cyber-crime as soon as possible’. His condition was legally recognised as affecting his decision making, to the extent that the court was directed not to assess his intentions when committing these offences, but simply whether or not he conducted the attacks. Arion has demonstrated time and time again that he may be unable to conceptualise the relationship between the actions that he is taking and the full impact of the legal consequences.

With each hack, Arion must have been releasing a huge amount of dopamine, the neurotransmitter in our brain that relates to motivation and pleasure. It is precisely this identification of the dysregulation of dopamine that is observable in autistic patients and is currently being explored by some in the neuroscience community as a corresponding trait of Autism(1, and 2).

In this conception, dopamine may be a substance to which Arion had a dysregulated relationship - and the safeguarding effort should have protected him from the medium by which he could suffer further from that dysregulation. In effect, the failure to remove digital technology from his room is akin to leaving a harmful substance proximate and accessible to a dependant user.

If the police did leave an internet-enabled computer in the room of a soon-to-be convicted cyber criminal, despite having a duty to prevent exactly that, then perhaps they might also see the benefit in avoiding commenting on the mundane simplicity of the hack and allowing the media to present it as the improvised miracle outcome of the machinations of a savant mastermind hell-bent on causing chaos and destruction.

There would be a very clear benefit in avoiding the conversations about whether they checked the back of the hotel telly for a Firestick, or even whether they knew that this device counted as an internet-enabled device. That would raise all sorts of questions about whether the one safeguarding job they had was carried out properly in order to protect both the potential targets from being impacted, and the perpetrator from reoffending and hurting his chances of reform.

There is additional public interest in questioning if the training for safeguard assessments on these hotel rooms is sufficient, as not all digitally enabled crime is property damage. Police protection may apply to those engaged in harmful or violent imagery or communication, are these offenders offered the same opportunity to utilise internet enabled devices to further harm and be harmed by their behaviour? Perhaps this constitutes another reason to communicate that this incident could only occur if a technological whizz was at the helm of the event.

The Incentive

The police haven’t released the details on the hardware used in the Rockstar hack. Frankly they don’t need to, we have enough information based on the modus operandi of Lapsus$. All computers are still computers - regardless of their shape or size. Anything with internet access can be used to enter a username and a password, or browse the internet to buy illegal access credentials. That really is all there is to this.

It is very clearly possible to explain - with both brevity and the use of accessible language, that this was a security incident caused by a technically competent 18 year old who was using computers left in his possession to conduct a simple but high-impact attack. A considered approach, which journalists aiming to cover this story could utilise, would be to decompose the attack and contextualise it against the attackers history, as above.

Arion is now also a legal adult and so the press are permitted to print his name in their coverage. I don’t believe that the press coverage was at all informed by the investigative desire to understand or explain what happened, and this is clear in the absolute lack of technical detail or historical context shared by the press on Lapsus$’ behaviour. Outfits such as The Guardian have instead clearly opted for shock value, aiming to drive traffic to their sites and generate yet more noise.

The conclusion

This triple coincidence of wants amongst the private sector targets, the police, and the media shouldn’t go unarticulated. The private sector targets need to classify the attack as sophisticated so as to minimise impact on share prices or profit. The police maintain their credibility and public image by conveying the perpetrator as a mastermind. The media stand to benefit hugely from the exposure and traffic coming from a report on the latest Hollywood-esque hack coming from a minor. Allowing these organisations to benefit from and feed on the coincidence of these interests is an obfuscation of the moral duties at hand. We need to ask what the consequences will be for this young man’s life, and conclude that it is important to deconstruct these narratives when they emerge as an act of protection for people like Arion.

I hope this has adequately teased open a conversation about the finer points that may have been lost in the coverage

Huge international organisations such as Microsoft and Rockstar that fail to take adequate steps to secure their systems against simple attacks can expect similar future incidents. Rockstar claims that the GTA 6 leak cost them $5 Million and “thousands of hours of staff time”, this was almost certainly about the voluntarily incurred marketing shift they launched to reexamine their strategy after the video game clips were leaked. It’s also worth mentioning that Rockstar’s notorious ‘crunch culture’ in which employees are culturally expected to work overtime 5 days a week means that Rockstar won’t be paying for hundreds of those extra hours anyway.

If we are certain then, that this is not the last teenager who will successfully break into a large organisation in this way (Arion is certainly not the first), we must make a decision. Do we engage with these incidents like has been done with Lapsus$, or do we accept our moral responsibility to people like Arion who are vulnerable and need cultural and social support.

We would do well to understand that minors are only exercising the digital skills that come as a symptom of the world built around them by the very same organisations. A holistic and informed approach to the treatment of vulnerable people, who reach out and pluck the low hanging fruits of the digital world, would prioritise helping those individuals to avoid doing so in the future.

I am personally not bothered about bemoaning the impact of the damages to the brand of a game that lets you execute prostitutes and renames it’s likeness of a Vespa to a ‘Faggio’. Instead we would be better served by focusing on how we can assist the health and wellbeing of young netizens like Arion Kurtaj. Coverage of these incidents as anything other than this phenomenon is disingenuous and strips them of the advocacy and compassion that they are entitled to.

You can subscribe to my blog via email or RSS feed.

Thank you to Eulalia Saurin, Androula Pistolas, and Elaine Haigh for your expertise, insights, and time spent on helping me produce this blog post.

Considerations when getting started with InfoSec policy.

2023-08-31T00:00:00Z

Policy work is one of the most reliably ‘second-hat’ pieces of work that I’ve come across in industry for smaller organisations. I’ve spent countless hours with people who have very little interest in policy who have clearly been saddled with the job of getting org policies sorted out. I’ve seen the populated templates that they work very hard to get across the line and signed off by the board, and I know the line of questioning that can very quickly unearth whether a policy is anything other than ‘shelf-ware’.

This speaks to a few conversations; where should policy sit in the emergent or organic growth of smaller, modern businesses? How have we developed a common sense relationship to policy that limits our understanding to be purely about the ticking of legal boxes? Is there any way to develop meaningful, useful policy that doesn’t get you absolutely lost in SEO-engineered advertorials along the way?

I want to cover some of this here, and provide a meaningful conversation that I truly believe will enhance whatever policy drive your org is on right now. Thinking about these things for the sake of thinking about them certainly guarantees a superior design, and hopefully might even change the relationship you have with the process.

Policy work can feel like nothing less than the articulation of the complex social and procedural relationships between members of the org, but this requires a renewed focus on policy as a social toolkit, not a punitive or legally mitigating collection of rules.

Who is this for?

Anybody who has taken on (or been handed) the responsibility to sit down and assess, rework, develop, or otherwise work with the body of policy of their organisation. Business Continuity, Information Security, Acceptable Use, BYOD are in-exhaustive examples of what may be on your plate at the minute.

Why am I positioned to contribute to this?

I have run Gap Analysis projects for many organisations across many disciplines. I review bodies of Information Security and Business Continuity Policy in accordance with internationally recognised standards ISO 27001 and ISO 22301 - providing considerations for orgs to take to their future discussions to enhance their policy. I’m also an accredited ISO 27001:2022 Lead Implementer under the British Standards Institute.

I am not sitting down here to tell you how to run your business or what requirements you categorically need - Context is the precursor to knowledge and I don’t know yours. I am collecting my (ongoing and developing) personal experience of this side of InfoSec and sharing it in the belief that it will be useful to someone.

What is to be covered?

What policy is, and what policy isn’t
How to get started on your policy
Signposting resources for your consideration (UK)

📑 What is policy?

I’ve written using the term ‘policy’ as a broad classification of the work that may be coming as part of (in-exhaustive):

Implementing Information Security policies/ Cyber Security Policies
Documenting or building out your Business Continuity Policy or plan
Building an ISMS, or a BCMS
A drive to put knowledge into organisational ownership that currently sits in people’s heads, or in the ‘common sense’ of the org.

Looking at the commonalities between these examples (or indeed your unmentioned but incredibly relevant example) is useful in helping us define what ‘policy work’ should look like.

At its most simple, Policy refers to a system of guidelines that are used to achieve desired outcomes. People build these systems when they work in collaboration with other people so that they can be consistent over time and meet shared objectives. If people work collaboratively for a shared output of some kind, it’s important that they agree on a process. Processes are the efforts we take to meet objectives or goals. We determine what processes are by using ‘inputs’. Inputs can be things such as conversations, shared objectives, or requirements.

Examples of inputs could be the marking scheme for a group project, or the mission statement of a charity. We need these to figure out what we want to achieve (Outputs), and how we want to achieve it (Processes).

When we follow through with our efforts and create something based on our shared goals, we have produced an output. We can then assess whether our output is useful by comparing it against our intentions when we determined our inputs.

While this process can be done in a conversation for a group project of three people, it gets harder to ensure that processes are agreed upon if you bring more people to the conversation. When a project between two people turns into a collaboration between ten, it starts to become easier for different people to have diverse opinions and priorities on our inputs, our processes, and what our objectives are.

Policy helps us to collaborate at larger scales by documenting what our objectives are, what inputs inform those objectives, and what processes need to be followed to make sure those outcomes happen.

Our body of policy needs to accurately map the relationships between people, and provide an accurate signpost to the resources that mark out subsequent roles and responsibilities. These must be justified in a way that can be walked all the way back to the strategic objectives of the organisation, which themselves can be justified as considered and informed.

🗺️ TL;DR - Policy cannot be used simply to mitigate risk or answer to regulators. Policy should be used to map the relationships between people, and the subsequent agreed (and existing) processes that create and describe how business objectives are used to make decisions on risk and controls in your business. Policy is a map to processes.

👁️ ➡️ 🧠 Make the descriptive explanatory.

Further to the previous point - if you are developing a management system of any kind and intend to map or articulate that system through a body of policy, it is vital that the system is explanatory, and not just descriptive.

Description is the account of traits or features of a given object that can be used to identify it. Explanation is the ability to decompose and identify the mechanisms by which the describable actually comes to be and operate.

It is not enough to create controls that are only descriptive, it is important to show the provenance of any responsibilities or controls and draw a silver thread back to the underlying mechanisms and processes that justify and explain this final output. This can be seen as an explanatory relationship.

🐦 The Stress Canary

Policy work should not by its nature cause stress. The concerted effort to capture and document the relationships between different operations and staff is a project that will make life easier. Each stage should bring relief and clarity to your mind about the state of the business, and the opportunities for further development. But the scale - or the information, that you uncover about the readiness of your organisation - alongside improper resourcing or support, can leave you feeling like you’re clutching at straws or doomed to fail.

Stress should be seen as a Miner’s Canary for the methodology of your project. Ensuring you are following a process that has been informed and approved by top management means you cannot feel lost, and should not feel stressful. If you do catch yourself feeling stressed, you need to remember that:

You are not taking on ownership of the risks you are identifying, and they exist with or without your knowledge of them.
Policy work can only arise to document what organisational objectives and goals have been determined, it is not your job to create as you document. These are separate work streams (More on this later).
If you are a risk owner also completing the policy drive (likely a micro or small business owner), then make sure you’re separating the creation of new processes/goals from the documentation of them in policy. That degree of separation will stop you going mad.

🍰 Working guidance for development of policy - The short version

The main takeaway from what has been said so far is that policy must serve to articulate existing decisions and processes, not create them from nothing. In practice, it is almost universally applicable advice that:

Any body of policy that creates obligations should be based on a risk assessment and impact analysis.
Risk assessments and impact analysis should consider the strategic goals and objectives of an organisation.
Strategic goals and objectives are set by top management.

You can take this waterfall of responsibility to the bank and stop reading now if you like. The reason policy is so vital to any management system is because it serves to articulate an explanatory relationship between these key features. Policy is the output of a management system, not an input.

Consequently, some of the best policies I have ever reviewed have been 1-2 pages long, and some of the worst I have ever seen have been long, arduous, and control-centric.

A note on inputs and outputs in the context of continual improvement: Cycles of iterative and continuous improvement eventually do mean that policies become an input for a process seeking to refine and enhance the management system of your choice, but it’s not always useful to begin with this mentality, and it may in fact hinder the important appreciation of policies being the documentation of processes that exist, instead of the conjuring of new processes as they are written.

Some Reflections on good practice for policy projects

👍 Identify the work-object and get buy-in

The first step on any high-level/organisational project should be to secure buy-in from top management. This is the acknowledgement and resourcing to commence your project. Traditionally we’re thinking about the board or the C-levels here - but realistically it’s likely to be the person who pays for things to happen, and goes to prison if they violate the companies act. As we are looking to create a body of policy that derives from strategic objectives we need to get authorisation for those responsible for setting them. If a project such as this doesn’t have meaningful and well-resourced buy in then it’s a non-starter.

What does buy-in need to be for? It cannot simply be for the development of our policies in house, as policies develop as a by-product of meaningful decisions that lead to new processes or management systems.

So the real work that is being proposed is for the development of:

Mechanisms to identify what processes are necessary for our ISMS
Commitment to the refinement of the processes we already have in place
Resourcing and support for the new processes or procedures that are required
Effective documentation of this work in a body of policy.

Let’s now discuss setting information security objectives. We derive IS objectives from common information security goals that are considered to protect or develop the overall strategic objectives of the organisation. These let us focus on how we technically assure information security using policy, processes and procedures. We also use them as a unit of measurement in the establishment of our risk appetite - as we can ask whether certain actions support or damage our information security objectives.

Another way I have tried to visualise this is seen below, where we place our Information Security Objectives within our strategic objectives. The respective objectives are our measures of whether we have enacted our day-to-day processes (such as the mentioned ad campaign or awareness program) in accordance with our overarching objective.

Either way, the essential concept being communicated is that we have specific goals we set using our IS Objectives, which themselves are set as supporting concepts for meeting our overarching strategic objectives.

🧱 Design Information Security Objectives based on the CIA Triad. These are your ‘raw materials’

Information Security objectives are very easy to set and tend to be similar for different organisations. They get more specific or convoluted mainly when we need to take on certain levels of risk that change how we protect information. For the most part, we create Information Security Objectives as a means to focus on how we technically assure the information security of an organisation to better support the overall strategic objectives

you can safely use the following guidance:

Information Security objectives can almost always derive from the CIA Triad - Which is the confidentiality, integrity, and availability of data. When we set out these objectives we create the mechanism by which we justify new roles, responsibilities, and processes. These IS objectives can be as simple as:

The organisation appreciates that the maintenance of Confidentiality, Integrity, and availability as pertaining to information and information systems is integral to the support of the strategic objectives of the organisation. we therefore create the following Information Security Objectives:

To implement, maintain, and continually improve our information security to better protect the confidentiality of our information, including but not limited to sensitive information.
To implement, maintain, and continually improve our information security and design to ensure that the integrity of our information and information systems remains unquestionable.
To implement, maintain, and continually improve our information security and design to ensure that the data that we rely on - and the people that rely on us, are able to access the data they need in a timely and reliable manner.

With these three core aspects of the CIA triad folded into the objectives of the organisation, you have created the means by which controls and responsibilities can be explained and justified. These are the raw materials from which we can build more precise or granular controls and processes.

✅ Figure out what you care about - Start with a risk assessment

When we tell users to use MFA or a password manager, or what is expected of them when taking care of a company owned laptop, we are supposed to be making an informed decision in response to a risk.

We should theoretically only be able to take these precautionary actions after qualifying the actual risk we are treating. In the ‘real world’ we don’t need to fully qualify the likelihood or impact of risk when we decide not to throw ourselves from great heights or ingest unknown berries, so it can slip our mind to qualify risk when we are building systems of work.

Building management systems are very different to the rough and ready risk calculations we conduct when regarding our own physical safety - we are creating a system by which we must justify the obligations we place on other members of our organisation, and a system whereby these obligations support loftier and further reaching strategic objectives. We therefore need a mechanism to assess risks before treating them. This is what a risk assessment is.

A risk assessment consists of identifying what may interrupt the successful ongoing enactment of strategic objectives, and then weighing up the likelihood that this incident may occur, against the impact that this incident would have if it did occur. Once we identify and qualify the major and minor risks facing the business, we are able to make an informed decision about what we can do to treat these risks and protect our strategic objectives.

Conversely, if we try to build out a set of controls or requirements without a risk assessment, we do not have any underlying structure to justify or measure the success of the control. This is not a suggestion to create measurement and performance tracking where there is no need to, only to create a relationship with risk whereby we need to be able to articulate it fully in order to say with certainty that we have treated or addressed it.

🗺️ Figure out who cares about you - Look at your context

Management Systems place a lot of focus on ‘understanding the organisation and its context’. This refers to the need to be able to place your organisation within the landscape that it acts and behaves in. The interconnected nature of different economic and social forces is one of the requirements for an organisation to even be possible to run and exist; It makes sense that we can’t abandon the consideration of these factors when it comes to securing and protecting our organisation.

The two points of interest for considering context are to:

Understand your ‘context’ using a focus on internal and external issues that may affect your information security management system
Understand the needs and expectations of people or organisations that you are connected with

I’ll attach a table with some examples of internal and external factors for consideration, but the best rule of thumb is to find and categorise issues, individuals, and institutions into either internal or external factors, and run a thought exercise where you identify how these things may impact your strategic objectives.

Internal Issue	External Issue
Organisational Structure of your business	Political landscape of the country you are in
Information Systems	Legal obligations and responsibilities
Staff awareness and understanding of your objectives	Relationships with external stake holders or members of your supply chain
Culture of your organisation	Contractual relationships

A note on the scope of consideration: It’s not just legal/good faith actors you should consider as a part of your context. Criminals or those who would see harm to your organisation should also be considered in this process. Any ‘Issue, Individual, or Institution’ really does mean anyone and everyone.

🏠 Build the house before you live in it (Even if you live in it already)

Any structured management system/body of policy project should have clear demarcation between the planning and operating phases. Planning is the process by which we determine and begin measuring objectives, whilst ascertaining what risks we are identifying and what our approach to treating them are. Operation is actualising our plans, and can only ever be done properly if we are working to a good and thorough plan.

This may seem like common sense - but I feel I must make this point as I have seen a very common approach whereby the project owner (who is unfortunately likely doing the work because they have been told to, not because they want to) will put together a set of boxes to tick and processes to change or conjure into being, and work from the operation of the organisation backwards, and create documentation of processes as a byproduct of the unjustified sets of controls they just ‘feel’ should be in place.

I can’t emphasise enough the ongoing help that a thorough planning phase will provide.

💭 Closing thoughts

I hope you’ve enjoyed this collection of thoughts on policy and management systems, and I hope someone finds it useful. It is of course in-exhaustive and there is plenty more to talk about - Which I hope to do. This feels like a good portion for thought however, so I will leave it here for the moment.

The main takeaway I hope to provide is that it’s worth digging into thinking about this stuff from an architectural point of view, and giving yourself as much breathing room as you possibly can to discuss and design the process for your policy work. If you have ended up using this piece of writing as a contributing factor in your project and you’d like to chat further about it’s application in your specific business context then let me know (savva@pistolas.co.uk). You can also subscribe to my blog via email or RSS feed.

Reflections on the radiowaves - TETRA:BURST and secure software in CNI.

2023-07-28T00:00:00Z