CISO: Librarian, Archeologist or Explorer?

I first wrote this post back in 2021 so I thought it’s time for a revisit with an addition of a few more roles. 

We talk about attackers being the enemy. Sometimes we talk about insider threats. But one of our biggest enemies is pernicious dependencies that limit our ability to keep environments up to date and configured to what we expect or need. One common trait of the best security programs is they have a massively deep and current understanding of what is in their environment and across all their vendors and other external dependencies. Then they use this understanding to drive change for the better. To do this they have to become a combination of:

• Archeologist 

• Navigator

• Cartographer

• Explorer

• Librarian

• Historian

• Anthropologist  

• Architect

• Detective 

• Diplomat

Archeologist

A former colleague of mine once described technology risk / information security as “industrial archeology”. This has stuck with me. In pretty much every situation there are layers of technology, patterns or practices that stem from epochs of leadership or approaches. You can almost literally dig down into all the enterprise’s systems and find these layers and spot the extinction events, the Cambrian explosions and other moments....…….ah, the “client-server” layer rose from the remains of the “mainframe era”, and those shiny new APIs are just an abstraction layer on top of an old object broker interface which in turn was an abstraction for an LU6.2 mainframe access layer which in turn abstracted an old CICS/IMS transaction. Even more current and, so called, digitally native environments of just a few years of development have these layers. These represent past in-vogue design patterns and the use of that particular era's NoSQL store, cache or transaction processing framework. We're all probably, right now, laying down some sediment that future versions of us will discover and gaze at in wonder or horror.  When you're driving a security program you constantly uncover these layers and artifacts of past decisions that cause delays and unpredictability in your otherwise pristine plans. Doing some archeology upfront is well worth the time.  

Navigator 

A big part of any security program is knowing where you are and knowing where you want to be. This requires navigational skills - knowing the position and what steps need to be taken to get to you where you are headed to. You need to have sufficient situational awareness to spot the hazards in your way and route around them (or put some “directed fire” on them). 

Cartographer  

Another big part of the security program is to construct a map of your domain, whether it’s the enterprise business processes, the extended supply chain, the technology and software inventory, all the way through to people and their roles. Having a precise and constantly updated map is crucial to be able to have the visibility on what you need to prioritize. Without a basic map of your enterprise at some level of abstraction you’ll never be able to construct sufficient roadmaps to plot the course to your desired risk destination. The other useful approach in thinking of yourself as a cartographer is that you can create layers on your basic map to annotate it to reveal specific patterns of risk or other sense-making, a lot like how layers work in Google Earth or in Geographical Information Systems (GIS) technology.

Explorer  

In most organizations before you can produce the map that you might use to navigate by, you have to discover the environment. This might involve creating the inventories you need to permit your mapping. Many organizations are still surprised to discover whole realms of IT and vendors in their midst. I’ve heard of organizations (thankfully not ones I’ve worked at) where the security team literally was in the process of finding whole departments that for whatever reason had managed to be off the corporate grid for a long time and had, like discovering a long-lost tribe, to be brought into the civilization of the enterprise.

This can get worse, a long time ago, I was bemoaning to a peer in another company how difficult it was to do real time discovery of network end points - he made me feel a lot better by telling me they were still finding whole data centers. You had to laugh, otherwise you’d just cry.  

A big part of the exploration is also to discover how the organization works, the processes and wider dependencies that can work against the change you need to instill. This could be everything from the purchase order process which might stall a business unit from adopting the controls you (and they) want, all the way through to discrepancies in job titles and career development ladders which might hamper the workings of your embedded security roles.   

Librarian 

I’ve yet to find any organization that has done a truly great job at organizing its internal information on policies, controls, systems operation, and business processes in any meaningful way. A security program needs this, needs to promulgate this and yet it is usually never given sufficient attention. I’ve known some organizations actually hire library scientists, taxonomists and ontologists to help with this, but in all those cases I’ve seen, the work has eventually died. Of course, now, various AI tools can make this happen more effectively than before essentially making an organization’s body of knowledge more accessible and useful.

It is also important to use frameworks to encode knowledge so others can usefully assess their state against these. Google’s SLSA framework for software supply chain security is a great example of this.

Incidentally, hat tip to Richard Westmoreland for his view on what InfoSec is: 

Historian

Another critical but often neglected aspect of the security program is its history. This is often undocumented and left to oral history passed down from the long-tenured employees. This could be the key decisions, the incidents or close-calls, customer issues, and the failed projects that drove certain approaches.

These are important to know as often the organization’s history drives a fear of change e.g. ”we tried X once and it nearly killed us, never again”, but the security historian will know that event and will be able to counter: ”yes, but back then we didn’t do Y and Z to make that X work fine and so now we’ll be good.” The security historian often knows or can find out the influencers of influencers of key decision makers. For example, in most organizations there is a shadow unwritten organization chart of who the actual decision makers are, these are often the former trusted lieutenants of organization leaders who are now in other parts of the company but for who the leader still informally reaches out to - to do a “what do you think about this proposal?” gut-check before any significant decision. If those hidden influencers aren’t brought into your process then you might have less control on the outcomes you seek.

When you’re starting out on your security history exercise it’s always worth talking to the long tenured employees. They are a fountain of knowledge that is crucial for your success. Dave O’Connor also has a great take on the role of SRE for this as well.

Anthropologist 

Then we have the role of anthropologist. This brings everything together. Our environments are a complex system at multiple levels of abstraction that are constrained by technology, archeology, organization history and, mostly, people. This is not just the people in the organization, it’s a much bigger eco-system of customers, suppliers, regulators, auditors and other stakeholders. Each of these communities have their own culture and approaches that need studying and understanding. Above all, the security anthropologist needs to understand how these "societies" interact so that the right approaches to improved security can be determined. If your goal relies on the cooperation of two teams that have been at each other's throats for years then knowing that and planning for it is going to be a vital part of your success.

Architect

Perhaps this role is too obvious. Many organizations even have explicit roles of security architect. Laying out the required technology scaffolding to implement a set of plans in service of the organization’s strategy is important. And, in the spirit of secure by design and secure by default having security built into the wider technical architecture is one of the bigger flags of success.

Detective

Another one that is perhaps too on the nose is the role of detective. This it is not necessarily just about forensic or other investigations related to detected security events. A bit like the archeological role, a big part of the security leader’s job is to investigate project failures, risks and other issues and follow the trail of problems to ensure the organization learns better approaches for next time. Sometimes, see also anthropology, there needs to be some good detective work to uncover people or teams that might be actively or passively standing in the way of agreed goals. 

Diplomat

Finally, we have the diplomat. Maintaining ongoing good relations between teams is not something just to be done at a transactional level when work needs to happen. The establishment of good working relationships and trust is what makes the ongoing transactional work a lot easier. When you look at the activities of actual diplomats there is a lot of analogous practices such as: building relationships with new leaders when they are appointed, understanding the dynamics of their goals, ensuring your team is building relationships at a peer level with their (perhaps new) team, looking to establish formal joint goals (“treaties”) to work on together, and forming alliances to drive broader goals.

Bottom line: effective security leadership needs a combination of archeology, navigation, cartography, exploration, librarianship, architecture, detection, diplomacy, and immersing yourself in your organization’s history and social anthropology.