The skills for your role and your leadership style build up throughout your career. But I’ve found, personally and in talking to others, that there are also significant formative moments that cause a big leap forward in expertise or outlook. These moments could come from good coaching or more often the brutal feedback of life in the real world.
It is interesting to discuss what people’s formative moments are, as everyone is different. Here are my Top 13 (I like the number 13) that have shaped my worldview and behavior on many things. The nature of them being formative means that they happened earlier in my career and so, given I’ve been around a long time, some of the situations may read like a history lesson. That will either be amusing or depressing since while many things have improved the underlying macro challenges of security remain the same.
In this post I’ll cover the first 7:
1. Build Your Future Network Now
Networking is both overrated and underrated in career development.
It is overrated in that much of the discussion fixates on the type of shallow networking that goes on at conferences, work events or other gatherings. The picture in one's head is of people furiously going around making small talk, exchanging business contact information and then likely never speaking again. Similar things play out on social media.
It is underrated in that, because people discount the shallow networking, they underestimate the actual massive impact a patiently and solidly built network can have. Such a network is typically founded on the strong bonds of having worked with people in employment, industry associations, advisory councils, and boards (public and private). Your personal reputation in those leads to recommendations for future engagement on other activities. If you relentlessly deliver and contribute, and in many cases are good with putting in the so-called grunt work then you will build up reputation capital.
Like most people, I got my first jobs by directly applying for them. Subsequently, my first 2 CISO roles were from direct approaches by executive search organizations, based on them canvassing the industry about who people thought were good. It helped even then to have a network of people I’d met in industry groups and peer events as well as people I’d worked with who were now elsewhere, but knew my work. All my subsequent roles were from direct referrals of people I’d worked with in the past that were now in other organizations and were recommending me directly to join them. Without explicitly aiming to do regular "networking" you can actually build a solid and possibly large network over time by not just being good at what you do but also by being professional, hard-working, conscientious and supportive of others. In other words, be the sort of person you would recommend and be someone others would get some kudos for having recommended.
The same works for industry positions, boards and advisory roles. I’m on some pretty significant government advisory boards and councils. Some people seem to think I got invited to these simply because of my current or prior job roles, which admittedly do have some intrinsic brand value. But the major reason for being invited to these groups is actually 20 years of lower key service on industry initiatives, serving on smaller committees, constructing reports, attending the meetings, joining the dots and connecting people. In other words, being useful and getting the work done. After a time you build up significant reputation capital for that and are immediately thought of for the next committee, the next board and so on simply because you have risen up the ranks of advisory work with other people who are now selecting people for their committee or board. They want other people who not only have expertise but are also a known quantity, get work done and are pleasant to work with. Some people think it’s all about “who you know”, but remember the who you know is a factor mostly because that came from “what you know” and “what you got done”. This means putting the work in and not obsessively trying to get to the very top with shallow work and short-cuts.
My favorite story to illustrate this was Hank Paulson, former CEO of Goldman Sachs and past Secretary of the United States Treasury. He spent many years as an investment banker in Chicago and during that time cultivated relationships with Treasurers, Chief Financial Officers, and in many cases their deputies and other staff. He spent, with his team, time supporting them in their roles and not necessarily always winning a huge amount of business. All these people ultimately rose to CEO or otherwise became more influential in their organizations. When they did they remembered who helped them on the way up. What then appeared to be a ready made network of CEOs to feed business his way was actually a network built over time. In other words, he built the network he needed for when he needed it, not actually tapping into a network that pre-existed.
When you’re rising up in your career, say 3-5 years away from being CISO, then the best approach is to not over-focus on trying to be so well known with the executives at the company. For sure, make sure your boss (the CISO or otherwise) is giving you some exposure and opportunity. But, your best bet is to more heavily support and network with your peers or next level above in other functions across the business, finance, IT, operations, product with a focus on those who are known to be on the up and up. Help them in every way you can, get to know them and support their initiatives. Then in 3-5 years when you're in the CISO seat or being vetted to take over from the existing CISO you will have a pre-built network of supporters of the people you worked with that have now inevitably risen to the executive ranks - and the people who you might have focused on in the C-suite 3-5 years prior may now be long gone. This is the networking equivalent to the Gretzky quote of skating to where the puck is going to be. Build your future network now.
2. Continuous Control Monitoring
I first became fixated with continuous control monitoring a long time ago in a company where we had an intrusion. Fortunately we had sufficient defense in depth that this was stopped at one layer of defense and could have easily been stopped in deeper layers. What was interesting, though, was in the after action analysis our quite well tuned network intrusion detection system (N-IDS) didn’t register or alert anything about this intrusion attempt. We knew this should have been detected and it wouldn’t have been lost in the noise because, uncharacteristically for the time, we had the false-positive and false-negative balance set up well. What had actually happened was a week earlier there had been a network change that took off-line a number of the network switch ports that fed the N-IDS and no one had noticed that essentially many sensors were simply reading zero. The way the environment was set up was that we had no singular sensor alerting and the drop in volume was so minor as to not raise an alarm. In effect the problem we had was no-one knew that zero events didn’t actually mean zero events but meant there could be nothing but zero events because the environment was off-line. Yes, it also meant the particular N-IDS product wasn’t self-observant enough to alert that it had stopped receiving traffic from a set of span ports, but this is nearly 2 decades ago when these devices were not that advanced.
Incidentally, at the time this also reminded me of a general pattern of sensor problems that I’d witnessed before. In many industrial applications it’s hard to know if a sensor reading zero is broken or really reading zero. For example, in some nuclear environments I’d worked in the radiation sensors would naturally read zero because the inside-out shielding stops the outside-in background radiation and so they may include small and harmless radiation sources so the sensor always reads something to make it immediately obvious if it is broken.
As a result of this N-IDS event we created a small system that monitored for feed liveness over the broad array of IDS systems and other controls. We also created an early form of synthetic event generator to generate events across the broad sensory environment to ensure correct operation.
As an aside, there’s some additional applications of this approach to project and program management. How many projects have you had under your supervision where it follows the pattern of Green, Green, Green, Green, RED? In other words the project was silently failing until it became a visible failure. The response to this is to introduce interim milestones, or canaries for project failure so you get an early warning ahead of time.
3. Real World Use of Systems
As you get more experience over more industries, geographies and technologies you get to learn the old Mike Tyson adage that “everyone has a plan until you get punched in the face” is applicable in technology as well. Well, more specifically, that your technology is all great in the lab but when it hits the actual field the reliability and usability are really put to the test.
The lesson here is to know for sure what your system will behave like in the real world with real users in the environment that the technology will have to live in for years, perhaps decades.
I was fortunate in my early career to work on industrial control systems and some military applications where I had the benefit of multiple positive and negative lessons. I used to work for British Coal, the nationalized UK coal mining industry. I got to work on some small parts of a pioneering system called Minos (Mine Operating System) which was built in part with a distributed system language called Conic. This all mostly ran on good old DEC PDP-11’s under a real time O/S called RSX-11. These machines were deployed in pit head control rooms. I remember the first time I did a site install of a software update (yes, all manual) and being shocked that this one machine was in a dirty equipment room and had a centimeter of dust and debris on it. This machine had been running quite happily for a long time. I remarked to my colleagues that it was lucky these machines were so tough. They laughed, luck had nothing to do with it as it turned out the testing of these included a specifically dirty lab that created the environment quite the opposite of a classic computer room to make sure they did have a fighting chance of operating in the real environment.
In a similar tale of technology surviving actual users, later in my career I worked for an investment bank in London that was evaluating a range of new trading turrets (a desktop multi-line phone and inter-com). One of the key reliability features is how much they can stand heavy key pushes, cigarette ash being dropped on them (back in the days when you could smoke anywhere) and the handset being smashed on the desk in frustration by a trader having a bad day. All of this was part of the test of each potential turret product. Much fun was had by the team that day and all things being equal the most physically robust devices were selected.
I also remember, for another bank, implementing a pilot smart-card authentication system that ultimately never became pervasive for a whole host of reasons to do with technology integration (the SSO system not being ready for it). But the major killers were two usability issues. First, while we could rig smart card readers in the office with new keyboards or attached readers, no one wanted to carry a portable smart card reader for their mobile devices / laptops and people preferred the use of the one time code from their keychain attached SecurID device. The second more interesting failure in the real world was observed in its use as a corporate id badge and smart wallet for cafeteria purchases. The original (this was 2000’s) smart cards were not that securely attached and we’d all failed to anticipate a lot of people would carry, and thus bend the cards slightly, in their wallets kept in their back-pocket (it was a heavily male skewed environment then). An even weirder edge case was increased failures in winter associated with people using the cards to clean snow from their windshields.
So, whatever you do in whatever field you work, pay attention to the actual environment, people and situations your technology will be used in. It makes a massive difference and in so many cases is the difference between success and failure.
4. Go With What You’ve Got
All of us have been in situations where we have been faced with the choice of deploying a tactical solution now that mitigates a risk quickly vs. a more strategic solution that will be more effective and better over time but won’t deliver benefits immediately.
Sometimes this is an easy decision if the strategic solution is so far away or the tactical decision is likely to be replaced very quickly. In reality, most situations are more difficult where it’s a significant bet on the ability of the vendor (or team) to deliver the strategic solution quickly enough. In most cases over my career I’ve opted for getting the tactical out of the door as soon as possible to get the risk mitigated as quickly as possible for the simple reason that the strategy is never delivered on time with the features you expect and the tactical gives you the breathing space needed. Of course, this relies on the tactical not being so expensive and intrusive as to make no sense and also that it doesn’t actively thwart the later introduction of the strategic solution.
My formative moment here was deploying an end point integrity verification solution for remote access. This was in the 2000’s well before zero trust and similar solutions made this a routine feature. The idea was to have VPN based remote access only permit connectivity from strongly (cryptographically) authenticated users and to also make sure that the device they were connecting from exhibited strong integrity (configuration good, up to date OS, endpoint security up to date and so on). If it wasn’t then the connection was directed to a place to get updates or to IT support for any necessary manual help. We had evaluated a product that was good enough but at the same time our VPN provider at the time [a big router / networking vendor and serial acquirer of security start-ups] acquired a company that would be integrated into the VPN client and gateways and would be a much better, cheaper, performant and reliable approach. Our networking and endpoint teams naturally wanted to wait for the networking vendor to do the integration and roll out one new updated product. The vendor was claiming the integration would be done in 6 months. We, the security team, were highly skeptical based on past experience and knew we had a clear and present danger that needed resolving, a good enough vendor and an approach that wouldn’t be an impediment to the later deployment of the more strategic approach. We stuck to our guns and had the tactical solution deployed which was highly effective and stopped many potential issues. Now, you know the next part of the story right? Was the more strategic product actually ready in 6 months? Hell no. In fact, it went on that long I think we all stopped tracking what in fact happened to the product and it was yet another one of the products that went to this vendor to die.
5. Board Redirection
Discussions of board’s oversight of cybersecurity and how CISOs should represent themselves and their organization’s security programs are all the rage. This has been brought into sharper focus this year, at least in the US, due to the SEC requirements on board oversight and incident disclosure.
Now, for many regulated industries the board’s oversight of cybersecurity as part of a wider array of operational risks is nothing new. For example, most CISOs in the financial sector have been in front of their Boards for at least 15 years. Those individuals and teams have built much good practice to fuel this interaction and I’ve covered a lot of this in various posts [here, here and here].
But for me, one of the formative moments that started some deeper accountability of business units to the board on matters of technology risk, including cybersecurity, was a bit of an accident. I was presenting to the risk committee once, a long time ago, about the state of security for various systems across a number of business units. I got asked a question about the laggardly performance of one particular business unit. Now, in a moment of frustration (driven by a long history with this particular area) I answered, “Why don’t you ask them, their leader is here in the room?” Having initially watched my career flash in front of my eyes something strange happened. All heads in the room turned to that leader and waited for an answer. I must admit he did a pretty good job of ad libbing some reasons and promised to partner with me to resolve the issues. After the meeting I apologized for throwing him under the bus, but I did point out we had been trying for a long time and were lacking his support. Two things happened after this, word got out that the board and leadership expected as much accountability on matters of technology risk from the business unit leadership and their CIOs as from the CISO team and, consequently, those teams worked even closer with the CISO team to get on top of things. In hindsight, of course, it’s the right thing to have this shared accountability among businesses, technology and security and since then I’ve always tried to balance the accountability of risk management in the CISO team coupled with the accountability of other teams to execute. Essentially, it’s vital to align responsibility, accountability, capability, and the transparency over whether that is working. But, yes, sometimes this is easier said than done and may take a moment of frustration for you to find the path.
6. Don’t Neglect Branding / Packaging
We all probably appreciate the value of branding and packaging in various parts of our commercial life. It’s such an accepted part of the world around us that it has always surprised me it doesn’t feature more in organizations' security programs. What we name things and the brand we give to things can have huge impact to both memorability and conferring a property from the brand, often a degree of intended seriousness that benefits the work itself. I kind of knew this a long time ago but was still surprised how effective it was on a series of activities in a prior role. We decided, mainly as a bit of fun at first, to brand some of our major programs of work including their associated operational activities. These were:
Hunter: the threat hunting operation and continuous improvement program.
Harbinger: the predictive macro and micro threat intelligence capability that fed other programs.
Radar: the continuous risk assessment and control monitoring capability.
Sonar: continuous asset and inventory discovery.
These had fairly predictable logos that captured the imagination, for example Hunter was an Artemis-like archer. We used these logos and descriptions in management meetings, team meetings, budgeting sessions and so on but where it really helped was in board meetings where the brand recall really helped re-orient the board quickly as we provided updates at regular meetings.
It’s also important to apply this principle to the pithy naming of policy objectives. For example, a few decades ago in one organization my team was doing a front to back overhaul of all things identity and access management. We were struggling to get people to remember the policy objective. This was at a time when people barely had consolidated HR systems and corporate directories never mind anything else. Our goal was to make sure there was one HR system of record, one corporate directory that was the canonical source of all data about employees/contractors and key accounts. Additionally, all privileges in infrastructure, applications and data stores would map their identities to the central identity store and not have any variance (this was in parallel with a massive SSO implementation that would also help assure that). We got tired of explaining this, of communicating the policies and standards but one of my team had a brain wave of just calling this whole thing “No Privilege without Identity''. Yes, in hindsight that was obvious and lacking some nuance but it was a vital tagline that others could repeat, it encapsulated the goal and was understandable. As simple as it might sound it was, in fact, one of the core innovations that let all the technology and process innovation take hold.
So, channel your inner marketer or better still partner with your communications and marketing teams if you have them to brand your key programs of work, your teams and activities and get your policies into pithy and easy to remember goal-oriented slogans.
7. 80 / 20
I have focused on the 80/20 concept for a long time. In many circumstances there are 20% of issues driving 80% of the risk, 20% of the work driving 80% of effective outcomes and so on. I see this crop up everywhere albeit in some cases being more like 70/30 in one direction or 95/5 in another.
It’s a perfect counter to the temptation to only proceed with something if you can get to perfection or close to 100% especially when you get stalled because you know there won’t be the resource or commitment to actually get to 100%. The absolute most important thing to do then is to get something done and in such situations the something might be 2 things. First, fix the most critical issues that represent existential risk. Second, go after the issues that will broadly reduce 80% of the risk. Similar approaches can be taken in other areas of work.
I’ve seen this pattern repeatedly. One area that I particularly recall a while ago was in a privilege reduction program where we needed to reduce a particular type of critical privileged access across a large scale server infrastructure. In doing this type of work you can take many prioritization approaches but the best approach in most situations is to follow the pattern mentioned before, specifically to eliminate the allocation of the most extensive individual privileges (80/20 of privilege criticality). Then to identify the individuals who have the most aggregated privileges, which is usually a Pareto distribution - that is 20% of the people have accumulated 80% of the privilege. If you deal with both these 80/20’s it represents 20% of the work and reduces the risk overall by 80%.
Taking this approach also helps distinguish how to prioritize other work. One of the keys to team and personal prioritization is to know whether a piece of work requires getting an “A-grade” vs simply being a “Pass”. Looking through the lens of 80/20 helps with this because the 20% work is what needs an A-grade and the rest can be a pass.
Talking of grades, the formative moment I had on this first began at school and then university. Like many people who get good at taking tests, I realized that 80% of the marks on most exams were the same basic 20% of questions dressed up in different ways. Ok, in some subjects this might be 70/30 or 60/40. The point being that you can optimize work by nailing well over 60% of most exams by mastering a small subset of the knowledge or skills in answering those types of questions. I like to think I did well at school and university because I knew my subjects and I worked hard. I did, but I also worked the 80/20 as much as possible to make sure I was on the right side of that particular game.
Bottom line: throughout our careers we encounter situations that shape our views and behaviors for the rest of our professional lives. These formative moments, that might not seem so at the time, come to define us. It’s useful to write them down and reflect how they have affected you and those around you and to evaluate if they help or hinder you. A moment that locks in a behavior or view that is now counterproductive because the world has changed is something to be extinguished. Share your moments for the benefit of others.