The Nocebo Effect Of Security
Even good security can sometimes become an anti-pattern, just add complacency.
A nocebo effect is said to occur when negative expectations of the patient regarding a treatment cause the treatment to have a more negative effect than it otherwise would have.
The term security theater was coined by computer security specialist and writer Bruce Schneier for his book Beyond Fear, but has gained currency in security circles, particularly for describing airport security measures.
When I tell clients that security questionnaires have no real security value, I’m curious (anxious) on their reactions. Either they will agree with me… or they will think I’m not a serious security professional.
Of course, at this point I’ve built a report with them, and I can thoroughly defend and explain my position. It’s all about delivery and timing of course. I’m used to telling companies their baby is ugly. 🍼
In actuality, security questionnaires are sometimes used as a liability and CYA tool than anything else. If a company says they did something and are later found not to be doing that thing, then it becomes a mechanism to point a finger. 👉🏽👈🏽
Let’s step back though… questionnaires are just one aspect of cybersecurity theater. For more on questionnaires, please read Daniel Miessler’s posts on improving Vendor Security and security questionnaires. His posts and thoughts are well written, insightful, and I sometimes feel he’s writing what I’m thinking. I personally respect his craft.
Anti-Patterns Of Good Security Gone Wrong
This post was initially going to assert that Security Theater is a placebo. However, since a placebo can also have a psychological implication and a positive impact… the correct term here could be closer to Nocebo. Where an action can have a negative effect or consequence. Below are some examples:
“One and done - We did our penetration test and fixed our high and critical bugs. We’re good until next year.”
“We're certified <Fill In The Blank> compliant… so we’re good.”
“We hired a security engineer to fix all our problems. We’re good.”
The key takeaway here is complacency, regardless of whether it is intentional or not.
So although the tool and mechanism itself should have a positive impact on security, the use, misuse, or lack of care and feeding or follow up of that tool has negative impact on the security program altogether.
Successful Security Patterns
The person commissioning these functions is looking for security assurance, but true security assurance is delivered in a layered approach and pattern.
Here is a how the same scenarios above can have a positive impact on security with just a change in approach and mindset:
Fix the critical and high security bugs quickly
Address the “why” regarding these bugs to prevent the same class of bugs in the future.
Fix remaining security bugs. Conduct threat modeling exercises to discuss and document why they should not be fixed. Schedule a follow up in 6 months in case the threat model has changed. Create standards on how to prevent the same class of bugs from occurring.
Enroll in a bug bounty to have continual testing of your application.
The business understands that compliance does NOT equal security.
The business understands that at the end of the day an auditor is a human, and humans are not infallible or completely objective.
Setup the security engineer for success. Allow an effective communication channel of security risks to management.
Maintain the care and feeding of security engineers; grow the team.
The above discourse is for illustrative purposes and YMMV.