Social media potentially contain a wealth of information. At the very least, if you take the time to slowly tune up your persona, you will be getting more of what you find interesting and less of the typical attention-seeking noise – this is especially true for LinkedIn. However, even after spending the aforementioned amount of time, some genuine facepalms will pop up.
Below is a choice cut – I was supposed to post this earlier but you know, reasons! – someone gave their advice that if you do not fulfill the following criteria, you are not ready to be a CISO (if you need a reminder what is a CISO, just click here and here). Reading up on the definition at CISCO’s website, we read: “Almost all midsize firms and larger enterprises have a CISO in their C-suite. Smaller businesses may not have a technology executive with the title of CISO, but most will have a staff member—such as the director of cybersecurity—who handles those responsibilities.”. Not a perfect definition but workable, to say the least. Let’s get this show on the road.
So, to protect the innocent, the OP (who shall stay anonymous and without HREF) stated that the following are signs someone is not ready to be a CISO. Let’s read the list together.
- Niche (cyber security only) knowledge.
- Failure translating between the technical and the business domain.
- Leadership skills are not there.
- High pressure is not your friend.
- Business domain knowledge is not there.
Let’s take one look at the list. Do the items carry merit? Yes, all of them carry a degree of truth, ranging from modest to spot-on. Overall, if all of the above apply, yes, you might not be CISO material. “So, what makes this a facepalm, if you are agreeing to a large extent with those points?” you might wonder. The facepalm lies in this: the traits (or lack thereof) described in this list not only exclude you from a CISO role, they actually exclude you from a security engineering role as well.
Let’s examine the items on the list one-by-one.
- “Niche (cyber security only) knowledge”. Kicking it off with a slightly controversial point, security-only knowledge is a sure fire way to mediocrity. The problems with one having this knowledge and this knowledge only are multiple. Unless you have a solid grasp of an engineering discipline, you will not be able to provide sound security advice on said discipline. At best, you will be able to provide some basic security advice based on common principles – assuming you do know them. So, as a security engineer not knowing the discipline you are about to secure will lead to basic or erroneous decisions (the last point being especially true for software related matters). This is one of my pet peeves actually with certain security folks – engineering is a series of well informed trade-offs. Generic, blanket advice not only is sub-optimal, you are actually doing a disservice to your customers (external or internal).
- “Failure translating between the technical and the business domain”. Building on the above, unless you understand the business domain you are operating in, you cannot make informed decisions. To give a quick example: let’s say you hire a security consultancy to perform a penetration test on your assets. The consultants come, do their thing and you get the results. Assigning priorities said results is up to you and your ecosystem – this is why the Environmental field exists in CVSS 4.0 and this is not the full story. Seemingly innocuous findings might have devastating effects for non-technical reasons (i.e. lack of visibility in a specific area), conversely a vulnerability that might have someone screaming from the rooftops in a given context might have its impact lessened. This is just one of the many occassions that, as an engineer, you will need to calibrate technical decisions based on business reasons – vice verca also applies – you should be able to counter irrational business decisions based on engineering reasons. Oh, and a word of advice to my security engineering brethren: If you ever find yourselves in a place where you are consistently asked to downplay any findings and upscaling is actively discouraged, GTFO (and I do not mean the zine).
- “Leadership skills are not there“. Let’s think about this for a moment. Leadership can have an extremely broad definition. One of the definitions I really like is the one by Peter F. Drucker: “Every knowledge working in modern organization is an “executive” if, by virtue of his position or knowledge, he is responsible for a contribution that materially affects the capacity of the organization to perform and obtain results“. In addition to this, being a security engineer means that quite often you have to interact with folks that operate on a completely different reward system than your own. While during an emergency your authority temporarily expands, emergencies are not (and MUST not be – in the RFC 2119 sense of the word) the norm, the rest of the time you should get the folks above to go your way by getting their buy-in. Combine the two points above and it becomes evident that security engineering has an inherent leadership element to it.
- “High pressure is not your friend“. Ah, an easy point for a change. As stated above, high pressure situations MUST NOT be the norm – if they are, this is an action item for the engineer. Hero-arcs work fine in films and video games, I really like it every Christmas when Bruce Willis takes down sophisticated opponents without even changing his undershirt and I really like being the ninja taking down the evil terrorist organization but this is escapism. In our day-to-day predictable (to the extent possible) – high pressure situation can (and will) occur and when they occur, nobody looks for a hero, everyone looks for a calm leader to get them out of the mess, clean it up and make sure it does not happen again. I will go out on a limb and say that the author (not being involved in both day-to-day security engineering nor security management) hints that they are hero-worshipping, which is not a viable and sustainable viewpoint and seems to forget that “The graveyards are full of heroes” – one could expand this quote to state that “The darknets are full of breach data from companies that relied on heroism“.
- “Business domain knowledge is not there“. Let’s take a step back. Every for-profit entity (and arguably not-for-profit as well) has a defined objective. As a security engineer in such an entity you are not performing your security duties to be the Good Samaritan, you are performing your duties to help said entity attain its objective. Without a, rudimentary at the very least, knowledge of the domain your entity is operating, you are on board the fail train – your engineering output will suffer greatly. This is especially true for domains where there are specific security requirements to be met – even if said requirements sometimes are partially absurd and outdated . As a security engineer, it is part of your responsibilities to meet them requirements in a way that makes sense for your entity.
Now that I have offered a counter-argument why all the points above while carrying some merit are not prerequisites just for CISOs but for anyone working in a security engineering capacity (engineering being the keyword here), I would like to briefly touch on something that left a personal impression on me. As stated in the introduction, this was published on LinkedIn by someone who is neither a security engineer nor a security manager – their affinity with the field is that they are recruiters for security executives (not in the Druckerian sense). By stating that the qualities above are CISO prerequisites the first point that made an impression to me is this: What folks outside of the trenches think we do? The engineer implicitly described in the short article I am dissecting is NOT an engineer, as the very basic principles of Engineering and Science are violated. Has the overuse of blown-up titles dilluted the meaning of certain words so far that basic skills are considered not necessary to perform in a, by definition, highly sensitive function? On top of that, folks were commenting below the article how spot-on it was. A quick scan to their titles revealed that a lot of them condoning the ideas of the article should have known better.
Fixing the signal-to-noise ratio requires two actions from us:
- Boost signal by promoting material that does make sense and is written with good intentions (even a world-class expert can make an honest mistake).
- Call out drivel when we see it. And this is my opinion about the post. It is drivel, without any significant research nor expertise behind it, written on purpose to get a few clicks and impressions and OP can gather some leads to pitch his trade.
I hope by publishing this article, I made *your* SNR better. Comments and counterpoints are always welcome. Oh, please do not comment “Hey! Welcome to social media!” – I already know this.
Athanasios Kostopoulos 