Why Your Security Program Might Be Failing Before It Even Starts ⎥ Sean Finley ⎥The Elephant in AppSec Podcast
Discover insights from The Elephant in AppSec episode with Sean Finley.
Welcome back to the written recaps of the Elephant in AppSec, the podcast to explore, challenge, and boldly face the AppSec Elephants in the room.
Today, I’m joined by Sean Finley, an experienced Information and Application Security leader with deep expertise in AppSec, security operations, vulnerability management, and governance.
Sean’s AppSec career started at GEICO, one of the most recognizable names in U.S. insurance. He made the leap from business analyst to the company’s very first AppSec engineer, teaching himself everything along the way.
In this episode, we explore
- What inspired that transition
- How to spot red flags that doom security programs before they start
- Balancing security needs with business goals and getting org-wide buy-in
- Working with engineering when their first design could put the org at risk
- Why Sean believes there are far better investments than SAST
Sean's transition to AppSec
Sean's career in AppSec began at GEICO, where he transitioned from a business analyst to the company's first AppSec engineer.
Reflecting on his journey, Sean emphasizes the importance of self-learning and adaptability:
"I worked at GEICO for a very long time, started out just doing customer service in the insurance center, and got a chance to get into the technical side of things soon after college," he recalls.
His passion for the technical aspects of software development and his proactive approach to learning laid the foundation for his successful career in AppSec:
I always liked the technical side of building software, so always enjoyed having those deep dive conversations with engineers that I would work with about: how does the code work, why you do it this way, and things like that. After about 15 years on the business analyst side, GEICO was creating its first application security team. And I knew a few of the folks, the manager and the lead engineer who were going to be starting that team. They were engineers I had worked with years before. We had a good relationship. And I came to them and I said: You're obviously building this with internal talent. We're all going to have to kind of learn as we go. And I'd love an opportunity to do it, it sounds extremely interesting. And so they brought me on.
Sean notes, " It was my very first day on the team. We were observing traffic from a location in Russia that was known for cybercrime. And it just felt like being in a movie or a TV show, you know, about spy and espionage and technical crime. And it was just, it was so fun...None of us knew what we were doing. Nobody came from a security background. We were all learning it together."
This highlights the importance of a supportive environment and the willingness to learn on the job.
How to spot red flags that doom security programs before they start
Identifying potential pitfalls in security programs before they start is crucial. Sean highlights the importance of understanding the organizational context and gaining support from key stakeholders.
Understanding the Role and Gaining Support: Sean highlights the necessity of ensuring that key stakeholders, such as engineering and product leaders, are aware of and supportive of new security roles. He states, "It's definitely part of the discovery process to identify red flags early and address them as quickly as possible. One key question I always ask is: are the engineering and product leaders aware of the new security role, and are they supportive of it?"
Addressing Groundwork Challenges: Sean points out the potential difficulties that arise when a new security role or team is introduced without clear understanding or support from the organization. He explains, "If you bring in another security person and nobody's really understanding why it's happening, then that's a whole lot of groundwork that I'm going to have to do at the beginning." This highlights the need for clear communication and alignment with organizational goals to prevent misunderstandings and resistance.
Evaluating Existing Perceptions: When stepping into an existing role or team, Sean stresses the importance of assessing the current perception of the security program. He asks, "I've got to be aware of what is the current perception of that program, were the impacts positive? Were there negative impacts? Am I gonna have to address those?" This approach helps identify any existing issues or misconceptions that need to be addressed to improve the program's effectiveness and reputation.
Changing Cultural Relationships: Sean acknowledges the common perception of security teams as the "team of no" and the need to shift this cultural relationship. He shares, "I've had to deal with that where it's like, OK, I'm looking to change that cultural relationship between security and engineering." By fostering a more collaborative and supportive environment, security teams can work more effectively with engineering teams to achieve shared goals.
Balancing security needs with business goals & working with engineering when their first design could put the org at risk
Achieving a balance between security requirements and business objectives is a delicate task. Sean stresses the need for open communication and collaboration with business leaders.
"It's important for me as an AppSec professional and a leader to understand what the business is doing," he says. By aligning security efforts with business goals, organizations can ensure that security measures are not seen as obstacles but as enablers of business success.
Sean elaborates, "I think a lot for a lot of my career, security has been sort of viewed as like a cost center. It's something that the business pays for, but it's not necessarily making them money."
- Building Empathy and Understanding: Sean emphasizes the importance of understanding the engineering team's perspective. Having a background in business analytics and working closely with software teams, he developed empathy for the challenges engineers face. He notes, "I understood the process of the SDLC, the asks of an engineering team, and the timelines that they were facing." This understanding helps in building positive relationships and facilitates smoother collaboration.
- Finding a Secure 'Yes': Instead of being perceived as the "team of no," Sean advocates for helping engineering teams find a "secure yes." When engineering designs pose potential risks, Sean advocates for a collaborative approach to finding secure solutions. "I'm here to help you find a secure yes," he tells engineering leaders. By working together to modify initial designs, organizations can implement features securely without compromising on innovation. Sean shares, "I've had situations where the status quo for building things was using basic authentication or throwing everything in the URL. It's just how they've always done it. They don't know a different way."
- Engaging in Product and Sprint Planning: Sean highlights the importance of being involved in product planning and sprint planning. By participating in these processes, security professionals can have conversations about when and how security issues should be addressed. He states, "Planning is definitely your friend, get yourself involved in product planning, engineering planning, sprint planning for the products." This proactive involvement helps in aligning security priorities with business objectives.
- Communicating Risk in Business Terms: Sean stresses the need to communicate security risks in terms that resonate with business leaders. He explains, "You need to be able to speak to that translation from vulnerability to risk, so that they understand the importance of addressing something." By framing security issues in terms of monetary impact, reputation, and business continuity, security professionals can gain better support from leadership.
- Security Champions Programs: To scale security efforts, Sean suggests implementing security champions programs. These programs involve identifying engineers who are passionate about security and empowering them to advocate for secure coding practices within their teams. He mentions, "Security champions programs are a great way to do that in concert with your training programs."
Overall, Sean's approach to collaborating with engineering teams focuses on empathy, communication, and proactive involvement in the development process. By fostering a collaborative environment and aligning security goals with business objectives, security professionals can effectively integrate security into the organization's culture and operations.
Why Sean believes there are far better investments than SAST
Sean challenges the conventional reliance on Static Application Security Testing (SAST) tools, suggesting that there are more effective investments. "I think there are other things that we can be looking to prioritize over SAST," he argues.
And so, if I were looking at my security tool stack and I was trying to determine where I'm gonna put my focus, SAST would not be at the top of my list. And maybe it's controversial. I feel like it's probably not very controversial, but maybe, you know, maybe somebody's, you know, coming up with the latest and greatest SAST tool that blows away my paradigm.
But, you know, you're looking at tools that are looking at that static code that are modeling out how the application is going to use that code, and then trying to determine if there's a vulnerability present that way. And I think it just leaves a lot of room for error for improvement, you know.
I think it's pretty well known that even though SAST tools have gotten better over the last decade with false positives, there's still plenty of them in there.
This often leads to a burden on either the engineering team, who may not have the expertise to discern false positives, or the application security team, who may lack the capacity to thoroughly vet findings.
And when you don't have the resources, who's going to do that research? Who's going to triage those items? Is it going to be put on engineering who might not have the skill set to understand the false positive? Or they might claim it's a false positive because they don't understand how it actually really works, or it is going to be on the application security team, which might not have the resources to try to go through hundreds or thousands of findings to ensure true positives before they get passed over to the engineering team.
Sean suggests that SAST tools, while valuable, may not offer the highest return on investment, especially in environments where a large portion of the codebase is open source.
So I just think SAST is a legacy tool for the most part, and there is value that's there. I just don't think it's the highest value that we're looking for. I mean, I think if we're looking at how a lot of modern software it's built off of open source libraries.
Sean believes that high-quality Software Composition Analysis (SCA) tools offer greater value by effectively managing vulnerabilities in third-party components.
Estimates in every organization are different, but I've seen anywhere between 50 to 90 % of the code base is open source. So if you were on the extreme end of that, and 90 % of your code base was open source, a SAST tool is really not going to be impactful anyway. And so, you know, having a high-quality SCA tool that's got good reachability analysis, that's looking to see if the functions and classes are even reachable or are they being called? You know, how should we prioritize, you know, patching our libraries because, you know, every app seems to have hundreds if not thousands of direct and transitive dependencies and all the vulnerabilities that go with that. Like, that's a lot to weed through. So you do need to have good quality tooling and information to help you prioritize those.
He emphasizes that attackers can more easily exploit known vulnerabilities in open-source components than discover complex vulnerabilities in custom code:
It's easier for an attacker to understand your tech stack than it is for them to figure out where that possible path traversal exists in your custom code. It's going to take more for a threat actor to find that than it will be to fingerprint your application and find an exploit. And so those are the sort of things that I kind of go through as I'm thinking about where would I put my prioritizations when I'm having conversations with engineering about where do we spend our time? What things do we work on first?
Conclusion
In conclusion, Sean Findlay's insights provide valuable guidance for AppSec leaders on how to deal with potential risk, how to improve their relationships internally, and what tools to invest in and what (maybe) not 😌
By fostering a culture of collaboration, aligning security with business objectives, and making strategic investments, organizations can build robust Application Security programs that withstand the time and contribute to the overall success of the organization.
Recommended sources
SANS Institute — https://www.sans.org/
Leaders to follow, according to Sean:
Troy Hunt — https://www.troyhunt.com/
Tanya Janca — https://shehackspurple.ca/
Jim Manico — https://manicode.com/
Books:
Alice and Bob Learn Application Security & Secure Coding — Tanya Janca
Iron-Clad Java by Jim Manico, August Detlefsen