Originally given as the keynote at BSides Knoxville.
Security is a product, but we treat it like a sacred, immutable grail to preserve, unblemished by the sublunary needs of users. And yet, we wonder why defense remains stagnant, why we fail so consistently in progressing towards the glorious ideal of a “secure organization.” We will continue to fail — unless we treat security as a product. Are we trying to respect the phantasmal Elder Deities of Infosec and their stringent doctrine, or are we trying to ensure our organization can still thrive while operating in a perilous digital world?
One definition of a product I prefer is “something created through a process that provides benefits to a market.” Security as product, therefore, is created through a process that provides benefits to a market — in this case, the organization in which it operates. The somewhat religious belief I hear espoused is that designing security to benefit your organization will result in a blasphemous mimicry of true security. That couldn’t be further from the truth. It’s a mimicry of your duty as a security professional to follow your personal beliefs rather than pursue strategies that benefit your organization.
But perhaps you don’t believe me. You think there’s some level of objective “truth” that is foolish to discard in the name of benefitting your organization. Whatever that truth is, that’s now your product, and if it doesn’t benefit your organization, you’re attempting to sell it into a market that doesn’t want it.
I’m often left perplexed at how some security professionals can see victory in forcing through a change that users viscerally dislike, as if their dissatisfaction represents a blood sacrifice. How is that possibly success? Success is solving a real problem in a way that delivers consistent value. Success is fostering consensus so that you are supported by the organization in effecting meaningful change — even if you implement something adding to your customer’s burden.
For example, when requiring multi-round hashing rather than storing credentials in plaintext, relevant stakeholders in your organization must be included and understand the need for a noble sacrifice. You will fail if the security of your organization rests on users adopting a strategy that neither provides them value, nor is one they support.
As Sarah Jamie Lewis insightfully tweeted:
"our software is secure if you use it correctly" means "our software is not secure"— Sarah Jamie Lewis (@SarahJamieLewis) May 14, 2018
Similarly, if your organization is secure if users follow your security policies correctly, your organization is not secure. Maintaining the dogmatic view that it’s “the users that must be wrong,” rather than accepting the situation for what it is — the failure of your security program — is why we continue to fail. How many more years are we going to lament that our users are poor at security before we actually start working on pragmatic solutions?
Pragmatism doesn’t require security sacrilege. All products, including security, are shared problems within an organization. Each stakeholder must feel they have a personal stake in whatever course of action is taken — a process called building consensus.
As a product manager, there are times when we will release changes or new features that may be contentious. If I pursue a strategy without regard for how my colleagues who interact with customers or potential customers every day feel, the product won’t succeed in the market, because my colleagues won’t have the confidence to sell it. If I come to my colleagues with evidence for why it is necessary, describe how it works towards the broader product vision, and actively listen to their concerns, we can design a strategy collectively in which all parties are confident — even in the face of uncomfortable change.
Security as a product doesn’t require the wearing down of strategies through compromise until they are rendered ineffective. It requires a purposeful strategy through an overarching vision of how security can support the organization’s survival in light of the fact that computers are somewhat terrible, but necessary for success.
At this point, I’ve mastered a stolid expression for when security professionals nonchalantly explain the improvisational nature of their strategy-making. Most assume I’m asking whether they have a strategy for a specific project and seem surprised when I ask if they’ve defined their long-term vision for their overall security program. In the same conversation, the CISO or security engineer with whom I’m speaking will unleash a passionate rant — perhaps you have heard some of these grievances, or uttered them yourself:
- “Things do sometimes sort of get accomplished… but slowly.”
- “We don’t ever actually make progress, we’re just running around.”
- “We keep making the same mistakes over and over — it doesn’t get better.”
- “I don’t have any time to do research, I’m constantly in meetings where we don’t actually get anything done.”
- “I just don’t even give a shit anymore, nothing changes.”
I really do feel for your plight, but y’all can be tedious. There is clearly something amiss here that better or more tech nor people can fix — they will simply be likewise wasted. I hear these remonstrances nearly everywhere in infosec — from the smallest of teams to teams sprawling over multiple functional areas at Fortune 500 companies. There are countless passionate people working tirelessly, whom consistently feel like they aren’t accomplishing anything that is meaningfully improving security.
What is perhaps even worse is hearing that security teams have adopted “agile” methodology, then discovering that their tasks are based on the whims of the individual, the epics are ill-defined and focused on functional areas, and no one is looking at a higher level to see how many resources are being dedicated towards each effort.
What’s even more jarring is every time I play surrogate therapist — asking probing questions to discern why their teams are so inefficient at a macro level — they unabashedly disclose that their teams don’t have any overarching goals defined, let alone metrics to track progress.
And we remain shocked that we aren’t progressing?
Of the “three pillars” of infosec — people, processes, and technology — I believe processes are most ignored and undervalued. I’ve grown exhausted by the number of articles about the “cyber skills shortage” as well as listening to — and speaking about — the pernicious complexity and misguidedness of the security technology space. Yet I don’t see nearly the same volume of fiery headlines and hot takes on Twitter about how our processes are failing us, despite the fact that processes are the underpinnings of how people work together and with technology.
As an example, I’ve been amazed at what our customers accomplished with Excel and two people prior to adopting our solution — managing vendor risk programs covering thousands of vendors across many lines of business. A trait in common with each of those customers succeeding despite their people and technology constraints is how easily they can articulate their process — and it’s because they’ve comprehensively defined it.
A process is “a series of actions or steps taken in order to achieve a particular end.” You can have the best people and the best technology, but if you cannot define to what end they can be used, and how they can be used, success is unlikely to manifest. You also must determine the “what” before the “how” — it’s prohibitive to determine the steps necessary until you define what the particular end should be. I believe there is insufficient attention paid in security programs to what particular ends should be. Is “making Organization, Inc. secure” really the pinnacle of defining goals for our security programs?
The foundation for any product is understand your goal for the product. Fundamentally, what is the product’s purpose? What are you trying to help users accomplish? Viewing security as a product forces you to define your goals and come to terms with your team’s purpose. It also ensures you’re prioritizing actions appropriately — honing in on what will actually improve the product and your customer’s experience.
If your company is publicly traded, have you read their annual report? Can you summarize the Risk Factors they outline in their 10-K? The Risk Factors section is quite literally a cheat sheet, a ranking of your organization’s risks in order of their priority. If you do not understand the risks to the business’ ongoing operations from the organization’s perspective of priority, how could you possibly understand what is most essential to protect?
I assure you that you do not have to dive deeply into the mysterious waters of product management to improve your security program. The aforementioned rants by my blue team friends are painful primarily because they include examples of what you definitely shouldn’t do in product management if you want to create continuously successful products. Even not doing those things will help significantly — and doing the right things will empower you even more.
Because what lurks beneath the frustration expressed by so many in our industry is a sense of helplessness. We don’t feel empowered, we feel stifled and downtrodden. I would argue any profession in which you expend a lot of intellectual effort and time-capital into improving a problem, only to feel like you are running in place, will rapidly burn people out.
In infosec, despite a common understanding that reactive approaches to defense are misguided, we maintain reactive processes. Security teams are accustomed to receiving direction externally, feeling burdened with priorities that defy their beliefs of what is important — as if a secular organization should dictate the priorities of such a sacred order.
Once you adopt the mindset of security as a product, you can begin to take control. One of the “basics” of product management is that solely delivering exactly what customers demand, without understanding the motivation for their demands, will lead to poor outcomes and potentially monstrously disjointed user experiences. You have to proactively understand your customer’s perspective and look beneath the surface of what they are requesting to discern the underlying challenge or desire.
How many of you have worked in retail or other customer-facing service jobs? I have as well, at a department store and later at a frozen yogurt shop, and if security professionals believe they are treated poorly, I promise that you cannot fathom the depths of brutality customers can reach. I ask, because a cornerstone of many customer-facing service jobs is the notion of anticipating needs.
Anticipating needs means understanding your customer’s challenges, desires, and beliefs. For example, one method by which I sold higher-SKU merchandise in the department store was by efficiently learning about my individual customer. I asked questions about why they were shopping and what frustrates them sartorially.
Since I was in the contemporary dresses department, usually the woman was shopping in anticipation of an event, whether a date or party. I listened carefully to pick up on any clues indicating her challenges — for example, one with which I deeply relate is “I hate wearing dresses,” or “I’m going to be on my feet all night.”
Even a morsel of such data was sufficient for me to find additional options for her beyond the items she had chosen. Perhaps a dress with pockets and an elastic waist, that still looks chic while maximizing comfort. Many of the dress-wearing people reading can likely relate to the ecstasy of wearing a dress with pockets, which can both cache snacks or conceal fidgeting hands due to social anxiety. Or, I might offer a maxi dress, which conveniently veils one’s shoes, allowing the option of feet-sparing flats rather than heels.
I’m cognizant that I’m essentially describing a robust recommendation engine (more Netflix than Amazon) — but as it happens, humans can excel in this effort, too. I would imagine most would appreciate a professional faerie godparent constantly anticipating your needs and making your life easier, all without you having to request or nag.
Afforded the cover of not being, strictly speaking, a “security professional,” people are quite honest with me in how they perceive the security team. Security teams frequently are considered the opposite of the faerie godparent— more like a sulking demon that seems to relish an arduous professional life and decrees you are forbidden from doing the things you need to, without ever seeming to care about what those things are.
Security teams both rely primarily on direction and yet seem resentful of this dependence — but ironically also begrudge the notion of reaching out proactively to their organization’s stakeholders to discern what needs to be done.
This inconsistency of thinking leads me to somewhat believe that many security people fundamentally want to dictate what’s important to the company from a security perspective, based on their own opinions, so as to serve the Elder Infosec Deities. Frankly, it sometimes takes considerable effort not to adopt my best Regina George face after listening to a security person elaborately envisioning their Blue Team utopia (what I call a “Blutopia”) at great length and ask pointedly, “Have you ever considered that your opinions might be wrong?”
Part of the reason I don’t ask is that I truly don’t require additional help in amplifying social awkwardness. But the larger part is also that I don’t believe they would be deterred if their opinions are deemed “wrong” by someone else. My conclusion is this is because of the Steve Jobs Myth.
I don’t like Steve Jobs. My personal opinion is that he was a jerk and is a wretched role model for leadership. However, I recognize that he is idolized by the type of people who are prioritizing their personal opinion over what their organization actually needs, because of this Steve Jobs Myth. The myth is that through the spellbinding magic of Jobs’ gut instinct alone, and defying all evidence and user analysis, Apple forged ahead with the iPhone and consequently revolutionized the cellular device market.
That isn’t actually what happened.
What actually happened is there was an experimental project initiated without Jobs’ knowledge, which received lukewarm reception by Jobs once presented to him because he believed cell phones “sucked.” However, he trusted the team to work through the technical details and even allowed the head of the project to hire Apple engineers from other projects. His insisted in return on seeing “an interface that might be intuitive and exciting to lay-users” before he’d be convinced.
The Steve Jobs Myth perpetuates the idea that Jobs gave minimal thought to user needs — which generally makes some people feel empowered to not care, either — and that it is the only way to conceive brilliance and truly leave users awestruck. Jobs’ concern was actually that you cannot simply ask people, “What’s the next big thing?” and that market research is insufficient to conceive a product that customers will love.
However, he viewed user research as essential — as seen in his requirement for the continued development of the iPhone. What he understood is that people won’t always say — or even know — what they want, but through user research, you can see which preferences they truly hold based on how they behave.
Within behavioral economics, there’s a clear hierarchy between stated vs. revealed preferences. Humans can be proficient in fooling themselves in what their preferences are, or if they’re being interviewed, in saving face. For example, if someone asked me, “are you more likely to prepare chicken and broccoli for dinner, or a can of tuna?” I am not necessarily inclined to reveal that I’m sometimes indistinguishable from a cat in behavior and will answer the chicken and broccoli with my ideal self in mind. But if you observed the dinners I made that week, you would see cans of tuna — a vastly firmer source of truth for answering that question.
If you ask your organization, “Do you find SSO easy to use?” you might discover a variety of answers. Maybe they answer “yes” because they don’t want to feel less intelligent by not finding it easy, or they use it so infrequently that they’ve forgotten the frustration of their last use. Maybe they answer “no” because in their customer meeting an hour ago they unsuccessfully accessed a crucial piece of data because of an issue, which made them feel embarrassed in front of the customer. You might even find that people’s answers switch between one week and the next. None of this is particularly helpful.
You can examine revealed preferences instead, looking for the number customer support tickets filed for SSO, the number of multiple push notifications in a row, the number of password reset requests, or how many people re-enter the URL of the service after being directed to SSO. These metrics more accurately tell the “truth” of the user’s experience, and how much it’s aiding or hindering their work.
Another issue arising from the Jobs Myth is that its believers use it to justify proceeding with their projects, generally with the assumption that “users will learn to love it,” because they believe Steve Jobs’ ideas were so provocative and progressive that even if users didn’t know they wanted it, they’d want it in time. That is also thoroughly inaccurate. As Jobs himself stated:
“And one of the things I’ve always found is that you’ve got to start with the customer experience and work backwards to the technology. You can’t start with the technology and try to figure out where you’re going to try to sell it.”
Simply because you personally believe something is valuable or important, does not mean it is. You have to understand the problems that are actually meaningful, and work backwards to how to solve them. This is not just an issue with blue teams, but also with infosec startup founders — the classic blunder of creating a hammer in search of a nail.
Your job is not to determine priorities in your sandboxed mindspace and convince the organization that securing something is of vital importance when it does not present material business risk. Your job is to determine priorities based on what veritably helps the organization and explain why your solution is the right one to help.
An extension of this fallacy is also the reverse — that security people can be presented with a valid solution to the organization’s problem but reject it because they personally don’t believe the problem is important.
As a real-world example, one security professional I know pushed for a specific product to be purchased in their organization. They presented the four-figure cost and offered a variety of use cases where it could be of use — such as simplifying the ability for engineers to implement early detection in the company’s infrastructure. They shopped around the idea to non-security groups on its usefulness and gained their buy-in as well. However, the person in charge of procurement held the personal opinion that this product type isn’t useful, and consequently pushed back on the request.
I see this so regularly I began calling it “Security Morals,” but I now think it should really be “Security Dogma” instead. What I mean by that specifically is that there are somewhat rigid “principles” common among security professionals that are treated as dogma. As aforementioned, there is a seemingly insatiable desire to please the Elder Infosec Deities by strictly adhering to their doctrine, even if it defies the organization’s needs.
In a SaaS product, if an engineer refuses to add a print button because they personally think it’s useless when you can “just” right click and select print, despite all user research indicating that users are at present confused how to print, their personal opinion will be demoted in favor of concrete evidence. If they did this regularly enough, they might be placed on a performance plan.
In security, similar behavior seems rewarded, as if performance is measured by how steadfast your belief is in Security Dogma. Such behavior would not be rewarded if viewing security as a product.
When speaking with defenders, I notice a non-trivial amount bristle at the notion that they have customers — that they aren’t a neutral force above the fray, akin to the Federal Reserve. It was in thinking through why so many defenders hate the concept of having customers that my notion of Security Dogma solidified — that there are principles of security treated as incontrovertibly true and mandatory to implement regardless of the reality of the organization, what determines its fortunes, or what endangers its continuing operation most.
Security professionals may view themselves as a heroic knight, but to others in the organization, they might look like the Knights Templar. As in the trope, even minor security offenses are treated as critical, enforcing “justice” is considered paramount and non-negotiable, and an egotistical complex emerges of interpreting resistance to your “noble” intentions as evidence of principles in need of correction. While you are not, in fact, a knight, you do have the opportunity to be a hero — but not by rescuing someone who is not actually in distress because you believe they need rescuing.
Your customer is your organization. Imagine if you attempted to order food in an app and it told you “no” because the food was insufficiently healthy, while also never explaining how it defined “healthy” food. Would you enjoy the app? Being realistic, most of us would repeatedly rage at it, even when you begrudgingly conceded that it had a point about your midnight pizza endeavors. This is more than not being likable — which isn’t strictly necessary to be effective. You need to be respected. If you are perceived as dogmatic, I promise you that you will not engender the respect you need to be effective.
I’m usually astonished at how little security teams work on cultivating organizational buy-in, since that’s a core part of my job as a product manager. I personally don’t believe a security program can succeed without it. This doesn’t mean everything becomes watered down, worn meaningless by only acting on things which have perfect agreement.
It instead means ensuring that the organization feels as if it is a stakeholder in security, that it’s along for the journey, and that security is not their adversary, but a fellow team attempting to better the organization. You could actually never implement things that other teams specifically request and still foster a sense of consensus by presenting your point of view with a sense of empathy.
I’ve personally struggled to practice empathy consistently. Particularly for those of us who are on the spectrum, actively seeing the world from someone else’s vantage can feel unnatural. But I assure you it’s not impossible, and your job will become substantially easier when you begin listening to people and ensuring you understand their point of view, rather than trying to dismiss theirs and ram your own point of view down their throat. Active listening is one of the most useful life skills you can develop.
Cultivating customer empathy is the first step you should take in your transition to treating security as a product. An example method is through the 5 Whys. The goal is to dig deeper into why something is a problem and identify its root causes. For example:
- “Why do you not want to implement 2FA for Salesforce?”
- “Why do you not want to add a step for salespeople to login to Salesforce?”
- “Why can’t salespeople afford to take the additional time?”
- “Why do salespeople need to log their call notes immediately after a call?”
- “Why do salespeople need to transfer notes from Google Docs to Salesforce?”
The root cause is arguably that there is friction between the notes salespeople take during a call and where they are meant to log the call. The solution might be to integrate Google Docs into Salesforce, meaning the user has to log into only one service during the course of their work — meaning implementing 2FA will be more palatable. As in this case, you may hear answers that do not seem to be pertinent to the security team, as they are squarely in the business domain — but your role is to connect the dots between business operations and security risks that threaten them.
I strongly believe your highest value as a security professional is, perhaps, in empathizing with the organization’s business risk and identifying where digital risks arise that amplify or solidify business risk. Your customer knows what endangers them — but they do not know how that danger manifests through digital means.
Once you feel you truly understand where customers are struggling, you can begin architecting your vision. Consider your vision for your security program as its story that will unfold over time. Themes serve as the heart of stories, the foundation for the central idea the author is attempting to convey. The plot — or the events that unfold within the story — supports the theme and carries the story towards its goal.
In a security as product model, you will also have themes. Those themes will also have plots — courses of work that drive towards the stated goal and the actions you need to take within those courses of work. Before defining any of the work, however, you have to envision the overarching story. Few people are naturally proficient storytellers, but you can practice by expressing your program’s story through a caricatured, fairy-tale lens.
At the dawn of the year, our band of heroes embarked on their quest in Engineersville. They heard the cries from the local farmers of meager yields and slow harvests due to bugs. It would not suffice simply for the heroes to kill all bugs as they appeared — after all, there are many quests elsewhere to complete. They knew their noble purpose was now to help the farmers ensure a bountiful, efficient harvest that they could sustain on their own.
Our heroes’ first goal was to reduce the amount of time it took to squash bugs spotted in the fields, as the bugs could hurt the harvest if they were left alive. Come spring’s first blossom, our heroes transitioned to their second goal — ensuring fewer bugs were being introduced to the crops. They helped the farmers map out how their field architecture would look ahead of planting to determine where bugs could spring up.
As summer began sizzling, they toiled to ensure that their tools could be used by the locals as well, beginning the work on crafting one master tool the locals could use that would automatically determine which specialized tool was best for reducing bugs in the type of fields being sown.
As the first leaves of autumn fell, our heroes tested this magical tool among a small group of farmers, carefully analyzing results and finally releasing it to all locals so that they could begin their next year empowered to have a bug-free harvest. This meant the heroes would have to do even less work of patching and helping locals tend to their fields, allowing them to focus on new quests.
(A wizard hat is optional in crafting stories, but recommended.)
Are there any security principles truly sacrificed in this story? The overarching goal is to reduce the number of vulnerabilities in production. As in this story, there may be multiple themes that are part of the same story — reducing the mean time to fix vulnerabilities, adding threat modelling in the design phase to introduce fewer bugs, and creating an automated tool that abstracts multiple security products away from the engineer so they can test their code easily and efficiently during development.
The goal is still fundamentally a security goal, but the themes show customer empathy. The engineers want minimal friction in their workflows. As close as you can provide “push button, get security,” the more productive they will be. Your team, as a stakeholder, is also not ignored. The two initial themes are enablers to the longer-term goal, reducing workload off your team to support progress towards an even more efficient solution that will reduce workloads further.
It is essential to view it as a full story and not be disheartened that your end-goal cannot be accomplished immediately. Setting themes and dreaming up your vision can inspire you so fully that you find yourself with a cornucopia of ideas. Unless you are exceptionally fortunate, the vast majority of teams will not have the resources to pursue every theme and must prioritize them.
Prioritization is one of those tasks that’s very easily said — you “just” rank which themes are most important to you — but is formidable in practice. When I build roadmaps in my work, there is often an excruciating “this or that” decision that requires you to push back work on something which still would absolutely benefit customers… just not as much as the other theme.
My first word of caution to you is avoiding prioritizing themes based on what you feel is most important. Waging a war of opinions is one in which everyone loses — and that’s ultimately what you will be doing, unless you prefer a dictatorship style, if you use your personal views as the basis for your prioritization.
Instead, you must again return to the perspective of your customer. While you personally may believe the theme of “reducing the volume of emails with malicious attachments” is the most important one, your organization may have their deployment frequency and lead time metrics hampered by an arduous appsec process, which more tangibly affects business performance.
How do you differentiate which themes to prioritize? You collect and analyze data — both qualitative and quantitative. A good engineering program will be tracking metrics such as availability, customer tickets, deployment frequency, error rates, lead time, mean time to detect (MTTD), and mean time to repair or recovery (MTTR). Ask engineering how those metrics are being impacted by security requirements. Ask engineers how they would explain some of the mutual challenges you face — you may be surprised at how aligned DevOps engineering teams are with security (but that is a topic for another time).
If you aren’t tracking metrics on your security program, you should be, as it’s essential for measuring progress in a product. This includes your own MTTD and MTTR — such as how quickly you remediate product security tickets. It should also include measuring the frequency of configuration management changes, such as firewall rule updates, patching, hardening — anything to measure the tempo of your program.
You can also measure how resources — specifically your security team’s time — are being used. Are they spending half of their time extinguishing fires? Is a third of their day dedicated to configuring your SIEM? Do they lose a week each month asking routine questions for threat modelling exercises? These represent opportunities for automation, as there is benefit in reducing the cost of your recurring security tasks and freeing up resources for more impactful streams of work. You should also poll how they want to spend their time, to ensure you retain your talent and avoid needing to worry about the “pipeline problem” in the first place.
Beyond this, you also need to quantitatively measure how your organization perceives the efficacy of your program. For example, conduct the equivalent of NPS surveys for the security organization, where teams with whom security interacts rate how satisfied they are with the security team. I’d recommend keeping the NPS anonymous with the option of entering a comment to give more detail. After all, security people can sometimes come across as a bit intimidating, and you want to find out the truth.
Quantitative data won’t necessarily tell the entire picture, however. Qualitative data helps fill in detail and may even expose concerns that are difficult to discern from quantitative data. Talk with a selection of individuals across different roles and levels in your organization to hear their feedback on how security can better meet their needs and work with them. You should also ask people on your team, from junior to senior, to give their feedback as well. Again, anonymous surveys can be your friend here in order to promote honesty.
My security fairy tale above could be an example of hitting the nexus of what your data is telling you, thus rising in priority. Your engineers are dissatisfied with having to wrestle with security testing products themselves, and their lead time to deploy is suffering. Half of your product security team’s time is spent on patching and last-minute security testing before GA, because engineering finds it too onerous to currently conduct earlier in the process. If you have three product security people making $100,000 each, you are spending $12,500 per month on something your customer doesn’t like anyway. And perhaps as a last data point, your product security team has expressed the desire to do more research and build custom tools.
A project to build a custom tool that lets engineers self-serve security testing in the development process and to standardize a threat model for the design stage would tangibly improve the data points you have collected. It also happens to be straightforward to measure, which makes likelihood of success even greater, since you can more easily determine what more needs to be done to drive the story.
There are also a few economic angles to consider when prioritizing. First is opportunity cost. By supporting legacy tech with time and money, from what else are you taking away resources? Some of the CISOs I most admire share — coincidentally or not — the trait of thinking in terms of monetary costs of work. This importantly includes pricing in the “total cost” of a security product, which includes the amount of maintenance, tuning, tweaking, and troubleshooting that your team will have to perform on an ongoing basis. Any expenditure of effort by your security team on an action is directly taking away investment into another action.
Second is the sunk cost fallacy. Just because you’ve invested a lot of time and money into something already, doesn’t mean it’s still worth pursuing. Throwing strong resources at weak purposes will deteriorate your product. As in the aforementioned example of opportunity cost, if a legacy security product requires substantial ongoing maintenance to perform as you need, prioritizing a theme of moving to a newer, less burdensome product might be necessary. While this may add a short-term resource sink, it will allow the plot in your story to ultimately move forward.
You now feel confident which with themes you prioritized — you know what your story will tell, in what order. However, this story is a shared one, as any security initiatives will inherently be shared due to the nature of affecting the organization. Your customer must be brought along in your journey, and feel like they have a stake in your story.
When you’re soliciting feedback from other people, it’s an opportunity to grow the working relationship — and ultimately engender trust. Rather than nixing their ideas on the spot if you don’t think they’re worthwhile, use language like, “I hadn’t considered that — my team will have to look into it.” You don’t want to promise that all suggestions will be implemented, or you’ll result in a lot of disappointed people, but you do want to make people feel as if they’ve been heard. And, if you do end up implementing something they suggested, or a use case they emphasized, they’ll be delighted.
Be transparent with your story. To start, determine who the right stakeholders are in each organization and ask if you can bring by coffee and treats while you present the story to them. Ask them what they think of it — are there any assumptions with which they disagree? Are there any risks that haven’t been captured? How do they feel it will impact them? Ask open-ended questions so as not to guide them. Before trust is established, phrasing a question as “How will this help you or not?” may compel them to be supportive rather than expressing the full range of their impressions.
As someone working on a product with a third party risk management use case, I can attest that no matter your industry, some of your organization’s prospective customers are asking sales about your security practices. Presenting your vision and progress towards that vision gives them a differentiator to reference, even if far removed from the primary use case of whatever your organization is offering.
Connect with product managers or whomever is designing whatever your organization offers. Not only will it benefit you by receiving feedback, whether to prioritize or to determine the “how,” but it will inspire them to keep you abreast of their own roadmaps. Having security included earlier in the product process will only serve to benefit the entire organization.
As far as how you present your story, some sort of visual aid is generally advisable, rather than purely speaking to it. If you’ve seen my slide presentations before, you can likely guess that I expend substantial effort into how my ideas are visually presented. As a product manager, the slides I create describing my project are not nearly so sparse and beautiful — but I do always consider what I want the listener to take away and leave the rest to voiceover rather than text on the slide.
Bear in mind that while technical meat may sound delicious to you, it can be a repellent to colleagues elsewhere in the business. Your goal is to cultivate consensus around your themes — around the journey of your security program, not the intricate details of the plot. You need to express, in accessible terms, what the theme is, the value it brings to the organization, and any risks or considerations that will be shared challenges across the organization.
Returning to our fairy tale, a slide deck could be presented as follows:
- Our vision is to reduce the number of vulnerabilities in production
- Our goals are to reduce the lead time to deployment, mean time to patch, and security team time spent on application testing
- The primary benefit Organization, Inc. is less friction for engineers to test for security vulnerabilities, allowing for our products to be released more quickly
- The secondary benefit to Organization, Inc. is reducing the cost of security testing, helping with scalability as well as freeing up resources to accomplish other security goals
- We will need to partner with the Engineering team to understand workflows and ensure a security testing orchestrator is deployed appropriately into workflows
- We will need to partner with PM to introduce threat modelling during the design phase, which will require a near-term time tradeoff for longer-term cost reduction
You begin by inspiring stakeholders, then end with what you need from them to accomplish the vision. This has another benefit of putting those requirements on their radar in advance of when they will need to execute upon them, resulting in quicker turnaround times for you.
By the end of the prioritization process, I hope you feel emboldened by the knowledge of which themes are most important to accomplish, and in which order. Now is the time of execution, defining which steps need to be taken towards your goal.
If you have a program manager, this is exactly where to loop them in. If you do not, or cannot loan one from another team for advice, then please do not pretend to be one. That is, you should not assume you understand the abilities and constraints of your team members and assign tasks to them without checking with them first.
While you can lead the charge on the “what,” you must include others in figuring out the “how.” Look to the real Steve Jobs, not the fallacious Steve Jobs Myth, and recall how he trusted the project lead to determine the underlying technical detail so long as his requirements were met. Depending on the size of your team, there will perhaps only be one or two individuals able to take on tasks. Where I see security managers often fail is vacillating between extremes of giving sparse direction and minimal feedback to delving too far in the weeds.
Through the process I outlined, you already defined the requirements of the project through the need to present across the organization — so there isn’t necessarily much more work to be done on your end, save for clarifying requirements on request.
If you want to really make an impact, begin tackling your security debt. You may be familiar with technical debt, which is when quality is sacrificed for speed, typically with the false promise of “we’ll fix it later.” Ironically, by not treating security as a product, you are vastly more likely to accumulate security debt as part of your crusade to integrate your gospel.
Embracing security as a product involves treating it almost as a living thing, one which decays and requires nurturing to stay alive. For each “shortcut” you take, are you considering what challenges will be created later? Did you document why you can’t address it effectively today, for example because there will be a superior way to fix the problem if you wait? How frequently are you returning to those shortcuts and paying down your debt?
There is power in ownership. The endowment effect is a discovery by behavioral economics that people ascribe more value to things they own, far more than they “rationally” should. Your security program being a product means you own that product — it is your vision and your story. In a fashion, you can consciously nudge yourself into a mindset that will inherently encourage you to take better care of your security program.
I stress this because a lamentable consequence of the nihilism I see in defenders is they cease to care about the security of their organization on a time horizon that surpasses their planned tenure. With the tumultuous turnover of security talent in most organizations, if the strategy is Security Dogma, devotion to it dies when the believer leaves, and a new messenger of the Elder Infosec Deities comes in to spread their own interpretation of the Dogma.
By creating your vision for the security program, you describe a map for the security program’s journey. An incoming hero unburdened by zealotry can see where they are in the journey and the end destination. It’s unlikely that every stop on the journey will be entirely discarded unless there is scant evidence for its value. What is more likely is that the “how” will change most drastically, while the overarching quest — your vision, and to some extent, your legacy — remains intact.
The product process even aids you when switching organizations. What is changing is the end customer — not the process. Even so, just as when I helped women pick out dresses, there will be customers with characteristics in common to each other, rendering your maps meaningful beyond the initial customer.
And if you want to rise the ranks, the practice of articulating a clear vision and fostering consensus will only serve to demonstrate competency. It can demonstrate to your executives or your board of directors that you understand them as a customer and will nourish their trust in your ability to deftly manage risk in a way that supports their success.
This is the fairy-tale ending to my own vision I shared with you today — that you can ride into the sunset knowing you were a hero in the way that helped the realm prosper. The fanatics who sought to serve spurious justice will never reach their dream of security nirvana, wailing relentlessly into the wind about their persecution at the hands of locals wanting to prosper.
Inspire your organization with your story of how security can allow it to thrive and make them feel they have a part to play in it. Your band of heroes can and should include colleagues outside of security, who will be far more willing to aid you in your quest — however long or arduous — if you take the time to discuss its purpose to them from a position of empathy.
Security is a product, and reluctance to embrace that is like rejecting scientific evidence in deference to zealotry. There is a way forward that does not rely on worshiping the Elder Infosec Gods through enforcing Security Dogma, which is, in fact, the path of least resistance — despite being less dictatorial.
Quixotism in the name of security purity will crumble as a foundation for a “Blutopia,” but a pragmatic approach, the support of devoted followers within your organization, and a visionary quest just might be the right start to our collective journey.