Welcome back to another episode of Risk Grustlers, the podcast aimed at demystifying risk management for newcomers. Our mission is to unravel the complexities of this field and make it accessible to everyone taking their first steps.
In this episode, Gary shares his unique journey into the world of security. Gary’s story is one of transitioning from a 15-year career as a developer to finding his footing in the realm of information security and risk management. Join us as he walks us through the path that led him here.
Watch the complete podcast here.
Let’s take a look at some important highlights from the enlightening podcast.
Ayush: Tell us about your journey into security. How did you end up in this field? What emotions and experiences shaped your path?
Gary: Sure. I spent 15 years coding, then shifted to architecture and design. 9/11 shook things up and hit the travel industry hard. I got involved in sharing data with Homeland Security to build a secure watch list after that incident. We needed to transfer data very securely. Data safety caught my interest—locking it down and keeping the bad actors out.
I started designing systems with security as the base, tight controls, and limited access. Then, our company’s security head moved to Expedia and wanted me on his new team. I was like, “Why me? I design, not secure.” He needed someone to bridge the gap between tech and business, someone to explain why security matters. So, I made the move in 2011 from a place I’d been for 15 years.
Aayush: Did you feel nervous about it? How much of a learning curve was there when you made the transition?
It was a very difficult transition. I second guessed it multiple times, as I wasn’t the principal security architect. I was a bundle of nerves, dealing with that classic imposter syndrome. Leaving behind a stable gig in Colorado for the unknown in Seattle was no easy choice, especially for my family. But I took the leap.
Seattle felt like a whole new universe. I met several genius architects. My learning curve shot through the roof. I dove deep into research and learned a lot just by being around them in meetings all day, every day. My role was to bridge the gap by making the tech lingo understandable to everyone else so they knew what was going on and what they needed to do.
Aayush: As you ventured into the unfamiliar, what were your initial steps to acclimate and identify your path? What were the primary challenges you tackled first?
Gary: I focused on simplifying concepts, especially in identity and access management. Ensured everyone understood who could access what and when. Role-based access was key—defining it so only the right folks could access data and systems at the right times. Early on, I grasped this basic idea and translated it into practical solutions that people needed.
It felt great when people turned to me for answers instead of the other architects. Being that bridge helped make complex security talk understandable and actionable.
One key lesson I learned early was to admit when I didn’t know something. Just saying, “Let me check on that,” became my go-to. The approach saved me from diving into deep waters and helped me come back with solid answers after consulting with colleagues.
Aayush: Given the overwhelming number of security tools, the rise of new acronyms, and the pressure to meet regulatory and customer security expectations, it’s challenging to discern what really holds significance. CISOs are constantly inundated with pitches; does going back to the basics help?
Gary: It’s crucial to grasp the organization’s risks, establish processes to address those risks, and ensure effective remediation. Often, we acquire many tools and generate numerous findings, but there’s confusion due to the overwhelming number of critical findings, making it challenging to take appropriate action.
Aayush: What’s truly critical? Is it about having the right data encrypted, or is it about whether the encryption algorithms are secure or compromised or how encryption keys are protected?
Gary: Encrypting data doesn’t help if your encryption key is easily accessible. Basic compromises like that happen. First off, know where your data resides and who can access it. Role-based access control is key. Also, purge data when not needed. Why protect data you no longer use? Store it securely offline if required for compliance.
Supply chain worries are real. We hand off data to vendors. Instead of costly site visits, focus on training. Vendor breaches often stem from email compromise, phishing, ransomware. Training on spotting fake emails matters more than fortress-like data centers.
Aayush: When organizations aim to return to basics, where’s the starting point? Is it examining frameworks like SOC 2, ISO 27001, or NIST 800? These frameworks share similar controls, so what’s the initial step?
Gary: When checking out vendors, we start with SOC 2 or ISO 27001. These cover the basics. Once that’s sorted, we delve into areas like data exchanges. We prioritize identity aspects – single sign-on, robust authentication. Local authentication is out; access control and removal upon departure are in. This way, we streamline our focus.
Aayush: Imagine I’m a large SaaS company with $200-$300 million in ARR and a 2% revenue infosec budget. I’m just starting on security. What’s the absolute worst advice you could give me?
Gary: Here’s my advice—talk to many vendors, listen, and gather tools. But an inbox full of vendor-driven issues isn’t the way. I focus on our existing tools, collecting their findings, and then prioritizing. Resources are limited, so we fix the high-priority issues first.
We’re left with two choices: Invest more resources to solve it all or accept certain risks. Either we fix all findings with more resources or accept some risk. For instance, if we find application vulnerabilities, do we have a web app firewall to mitigate them while developers address them?
Aayush: With attackers being fast and sophisticated, how do we balance basic infosec controls against evolving threats? Is there a tradeoff between simplicity and effectiveness against smart attackers?
Gary: Attackers take the easy route, so start with strong security basics. Prioritize clean security hygiene before advanced measures. Having the right processes in place is crucial. Don’t invest in tech that finds the wrong things. Use technology to spot issues, but prioritize, understand, and remediate findings through proper processes.
Aayush: How do you present a case to secure a budget for security, especially when establishing controls from scratch? Could you share your experiences navigating the process of obtaining security budgets?
Gary: Security shouldn’t just be viewed as a cost center. It’s about enabling the business, not blocking it. We aim to integrate security controls into developers’ tools, creating that security “easy button.”
My current focus is helping teams do just that—no unnecessary overhead. Demonstrating how we reduce risk and empower the business makes these conversations smoother.
We align with the company’s risk tolerance and the board’s stance. It’s about understanding and mitigating risks to match acceptable levels. Every board wants minimal risk, but investment has limits. Our role is to clarify accepted risk, ensure comfort, and determine the necessary investment to lower risk if needed.
Aayush: When selling LLM use cases to large enterprises, what are the top four or five crucial controls startups must have in place to enhance their appeal to these enterprises?
Gary: Public information benefits all. Think Disney using Google for character recognition—identifying Mickey Mouse in pictures. But when AI affects how our business operates and thinks, we guard that IP. Data segregation is key, even when sharing learning. We isolate our data by not feeding it into an accessible system. There’s the public good too, where everyone contributes.
