The CISO has always been one of the organization’s debunker of myths- often those that IT tells.  Here’s a classic most if not all CISO’s have heard: “Sure it hasn’t been patched in 2 years but it’s behind the firewall so there’s no risk.”  The role is increasingly called on to add some reality to the fast moving world of innovative tech and all the things a user can do without even calling IT.  So there are plenty of myths that need debunking, but here I want to take on two of the Security Department’s own myths.  The stories we sometimes tell ourselves.

Myth one: “The users are the weakest link.”  What rubbish.  Consider what “weakest link” means.  There is a chain securing something and every other link in the chain is strong and reliable with the exception of the “weakest” which cannot be trusted.  Really?  Take one of the most common scenarios where you hear this: the user clicks on a link in a phishing email and that causes their machine to download and run malware.  Let’s count the number of technical controls that have to fail for the hacker to succeed.

First, the email gets delivered (well, your email security failed).  Then the user is able to get to the malicious URL (oops, the hacker fooled your web filter and firewall).  The malicious content is downloading through your firewall (guess that link in the chain is not as strong as you thought).  And finally, the malware is executing in the presence of your anti-malware solution (oops again).

Of course, all those “weak links” are technical solutions created and maintained by companies that spend a lot of time and money on cyber security.   They are full time on security and your end user gets at most a few hours a year in security awareness training.  So when the attack succeeds, you can’t expect the reps for the security companies to say “our bad.”  No way.  They are going to say “Well, you know, people are your weakest link.”

CISO’s are tempted to buy this nonsense.  Why?  Because it is easier to say “people are our weakest link” than to say to the CFO “I know I ask you to spend all that money on technology that I recommended and maintain but it wasn’t worth a damn on this one.”

The White House is calling out the technology sector on this.  In the Cybersecurity Strategy released in March of 2023, they wrote:

“A single person’s momentary lapse in judgement, use of an outdated password, or errant click on a suspicious link should not have national security consequences.  Our collective cyber resilience cannot rely on the constant vigilance of our smallest organizations and individual citizens.”​

Weakest link?   Your end user is your LAST LINE OF DEFENSE when your technology stack fails.  Next myth.

Myth two: “Information security roles & responsibilities are coordinated and aligned with internal roles and external partners.”  Recognize that?  It’s ID.GV-2 from the NIST Cybersecurity Framework (still v.1).  When you pair it with ID.AM-6 “Cybersecurity roles and responsibilities for the entire workforce and third-party stakeholders (e.g., suppliers, customers, partners) are established.”  It really seems like you have security baked into your organization if you meet these objectives, right?  Mostly that’s true.  Occasionally, though, there’s a subtle loophole here.  A gap that is not quite acknowledged.   The myth that clear roles and responsibilities are all you need is comfortable, it let’s you check the box, but it’s insufficient.  Alignment on roles and responsibilities are a start but the myth that you are fine if you have them needs to be looked at.

IT operations is not purely dedicated to security, so these roles and responsibilities are, in practice, a balancing act for many an IT Department.  They balance their need to deliver functionality and keep systems up and running with the need to have them be secure.  There are certainly ways to keep IT staff from making bad choices (everything from vulnerability and configuration management systems to old fashioned audits).  But let’s not kid ourselves: choices do get made and they are not always on the side of security.  Say what you want about risk management and roles and responsibilities, sometimes the IT folks take risks they shouldn’t or, at the very least, are risks that are beyond what they are authorized to take on behalf of the company.

To be blunt: many a busy IT manager thinks “what will the users scream at me for” before they think “what would the CISO do.”  CISO’s don’t call attention to this friction very often because they have to have good working relationships with IT management (or because they also are IT management).  Ever start a conversation with a colleague with phrases like this: “remember the past 4 times we talked about the need to review these rule changes before just making them?” or “what were you thinking putting that on the network?” Clear roles and responsibilities just don’t always prevent these occasions.

Besides, isn’t it the CISO’s failure if they cannot persuade the IT manager that the security need should be prioritized over the need to set something up regardless of how vulnerable it is (IT: “but hey, it works”)?   At a bare minimum, isn’t it the CISO’s failure if IT feels free to leave Security out of conversations about risks IT is taking?  Can any “roles and responsibilities” cover everything a busy IT department does in a complex environment?

So, just like Security might want to blame users as the “weakest link” rather than admitting the controls they spend a huge part of their budget on just failed, Security also doesn’t necessarily want to admit that there’s a part of IT that they were never able to convince to always take the security mission as seriously as Security thinks it should.

Security is so averse to discussing this potential for friction with IT Operations that actually working with IT on the balance between the two missions is not explicitly called out as a control objective in any framework I have ever seen.  Rather, the control objectives are siloed into defining “roles and responsibilities.”  To be accurate, to be successful, it is a conversation that never ends.

For an explicit example, consider COBIT 4.1 (outdated I know but it makes the point neatly) placement of security:  “To satisfy business objectives, information needs to conform to certain control criteria, which COBIT refers to as business requirements for information. Based on the broader quality, fiduciary and security requirements, seven distinct, certainly overlapping, information criteria are defined as follows.”  The 7 criteria are Effectiveness, Efficiency, Confidentiality, Integrity, Availability, Compliance and Reliability.  Overlapping indeed.   But what about when they are competing?  That’s the work of Governance and Risk Management.  How many IT engineers troubleshooting an issue have their governance committee on speed dial?

So to be fair, IT control objectives list security as one characteristic among others and Security lists “confidentiality, integrity and availability” in its triad of what it aims for.  In practice, though, I’ve talked to enough security practitioners in my 20 years at this to know I am not the only person who has been asked to turn off anti-virus software (and/or logging) on a server having performance issues even though there is no evidence that the anti-virus software/logging is causing the problem.  And that’s if they ask. 

On the security side, we will sometimes blur the lines around roles and responsibilities too.  With the rise of ransomware and MDR/XDR solutions, many of us are isolating devices first and asking questions later (“oh, did you need that laptop?”).  Ever have an IT person explain to you they have a whole protocol for informing users that systems are going down and that your department just short circuited the whole thing by isolating a device or by disabling users?

To sum up: there are two myths Security needs to resist the temptation to tell itself.  First, that your end users, the last line of defense when all your technical controls are defeated, are somehow your “weakest link.”  Second, that spelling out “roles and responsibilities” is sufficient to ensure privileged users in IT make secure choices in their day to day work.