Cassandra: the prophetess whom no one believes
Cassandra, a prophetess cursed by Apollo, provides a suitable metaphor for the challenges faced by security professionals. According to legend, Apollo fell in love with Cassandra. When she rejected him, he cursed her: she could foretell the future, but no one would ever believe her. This curse led to Cassandra’s fits and tantrums, effectively describing the frustration of being disbelieved.
Security professionals often find themselves in a similar position. They identify potential software security issues and attempt to raise awareness, but their concerns are often met with resistance or unbelief. This pushback often stems from developers’ investment in their own work, making it hard for them to accept criticism from someone outside their team.
The “department of no”
So how is Cassandra present in application security? At the design level she may warn that “this might not be secure as designed” to find out that “nobody wants to hear that their baby is ugly”. During development, she may say, “Don’t use this function; it’s insecure”, often provoking a response like, “It worked for me, so it’s not a problem”. In testing, she may suggest that uploading a JPEG to a text-only field might break the system, only to be met with a dismissive, “No, this field will only receive text, and it works perfectly”. Even in deployment, when warning about a library with twelve CVEs and a high EPSS score and being met with scepticism: “Says who? You’re just giving me a number”. Ultimately, when an exploited vulnerability leads to a crisis, the security professional’s post-mortem “I told you so” is often countered with, “Yeah, but it was your problem”.
These daily encounters often push application security to the periphery of the development process. Security concerns are frequently ignored until incidents occur at a high cost. This phenomenon highlights that the traditional view on security stems from being perceived as the “department of no”. Teams approach security with requests for public-facing endpoints, application optimisation, or open-source tools, only to be repeatedly met with a “No”. This constant rejection has given security teams a negative reputation, which needs to change.
The initial approach: micromanaging and misunderstood priorities
Izar Tarandach recounts his experience at a large company with a well-established product that suffered from significant technical debt, frequent team changes and security issues. To address these challenges, he first conducted a deep dive into the product leading to a comprehensive list of required fixes and detailed instructions on how to implement them, including estimated timelines. This direct, prescriptive approach, however, did not go well. Even up to a point that an internal email started to circulate, instructing teams to stop talking to the security consultant because “every time that we give more details, he finds more problems”.
He realised he made several key mistakes in his approach. By taking responsibility for the product’s security, he unintentionally removed ownership from the development team. He micromanaged their work, which clashed with the autonomy developers expect, especially in agile environments. His priorities were also misaligned – he cared more about security than they did. And although he delivered the detailed task lists and timelines, he wasn’t involved in the actual execution. Ultimately, he acted like a typical consultant, arriving, depositing a solution, and then leaving others to deal with it.
Calibrating the approach: from authority to empathy
Acknowledging his missteps, Tarandach adopted an iterative approach. First, he tried to be a “wizard”, then a “pope”, pontificating from a position of authority. This involved proclaiming that security code is quality code and horrible things will happen if you don’t do things the right way. This authoritarian method also failed, yielding only minor tactical victories.
Next, he tried something new: radical support, allowing people the opportunity to make mistakes and then to learn from them. Essentially, the security professional is available for support when needed, but otherwise, they do not interfere. Again, this approach backfired. By stepping too far back, Tarandach felt disengaged, missing new issues and opportunities when the team wanted input.
He looked further and learned about the crucial soft skills for security professionals as posited by Adam Shostack, a thought leader in threat modelling: active listening, respect, assumption of good intentions, patience and collaboration. He saw them as a possible framework to identify gaps and build a roadmap for working better together.
The misconception of empathy: commiseration vs. cognitive empathy
Despite the value of these soft skills, something was still missing, leading Tarandach to add “empathy” to his approach. However, his initial understanding of empathy led to commiseration. He and the teams would focus on the many problems they faced. They would express frustration that management showed little interest in addressing the issues, that time constraints forced them to focus solely on delivering new features, and that their previous efforts to improve things had failed. The situation felt hopeless and overwhelming.
It was Tarandach’s wife who encouraged him to examine the formal academic definition of empathy. It turns out there are several types of empathy, notably emotional empathy, or feeling someone else’s emotions, which was his initial approach, and cognitive empathy, which involves understanding someone else’s perspective. Tarandach realised that it was the latter that he needed.
Perspective-taking and leading without authority
This revelation shifted Tarandach’s journey towards perspective-taking and leading without authority. It became clear that decision-makers are not just the C-suite or those writing cheques, but the developers as well. Therefore, adopting the decision-maker’s perspective is crucial to understanding how they view proposed security plans. Practically, this meant:
- Tailoring the pitch: No longer using the same message for everyone but instead crafting the best pitch for each specific message and person.
- Managing both sides of the conversation: Before proposing anything, considering how it will be received by the other side and adjusting the pitch if necessary.
- Suggesting solutions, not giving instructions: Instead of dictating exact actions, the approach shifted to defining a goal and collaboratively asking, “How can we do it?” thereby involving them in the execution.
- Finding the right time to push or walk away: Recognising that other teams have different pressures and calendars and adapting to their timelines instead of expecting them to adhere to a security-centric schedule.
- Acting as allies, not adversaries: Constantly pushing back creates friction and an adversarial atmosphere. Instead, foster an environment where people are willing to collaborate.
Beyond Cassandra’s curse
The results of this new approach have been significant. It has led to personal and professional growth for Tarandach, yielding better, more meaningful results and working with people, rather than against them. He defined the following key outcomes:
- Understanding motivations: Learning what motivates different individuals, recognising that a product manager has different agendas and values than a developer.
- Identifying execution barriers: Realising that resistance to security measures often stems from legitimate reasons, such as time constraints or existing project demands, rather than deliberate defiance.
- Addressing personal motivators and demotivators: Acknowledging that people are deeply invested in their work, and criticism can be demotivating. The goal shifts from implying “you don’t know what you’re doing” to “you know exactly what you’re doing, and I’m here to help you do it better”.
- Proactive planning: Easier prediction of potential issues from roadmaps, allowing for proactive planning.
- Healthier work relationships: Transparency about agendas and expectations fosters deeper, more meaningful dialogues, ultimately leading to a more secure product.
With this new perspective, security no longer means automatic rejection. The answer can now be, “Yes, you can do that, if you work with me, if you implement it differently, and if you consider all these other factors that you previously deemed less important than your lines of code”.
Fear works
Tarandach experienced that fear, when applied judiciously, can be a valuable tool in selling security. Rather than merely documenting risks, a strategy can be to require top management to sign off on accepted high and critical risks. Once a top manager understands that signing meant taking personal accountability for any negative consequences, the team is quick to fix the issues. This demonstrates that fear, specifically the fear of blame, can be a powerful motivator for executives.
Being Cassandra effectively
Cassandra could not stop the Trojan Horse because her warnings were disbelieved. But what we can learn from Izar Tarandach’s journey is that bridging the gap requires more than technical expertise or authoritative mandates – it demands empathy, perspective-taking, and strategic communication. By moving away from the role of the unheeded prophet and toward that of a collaborative partner, security professionals can shift perceptions, build trust, and foster a culture where security is a shared responsibility rather than an imposed burden. Ultimately, it’s not just about predicting danger, but about being heard, understood, and invited to help prevent it.
