Ronnie Flathers — Security programs big and small
With Ronnie Flathers
Building an AppSec ProgramSecurity TestingSecurity CultureCareers in AppSec
Which parts of an AppSec program should change as a company grows, and which should stay the same? Ronnie Flathers joins Chris and Robert to compare security work in a fast-moving smaller company with the challenges of a large enterprise.
Audio hosted by Buzzsprout. Nothing loads until you press play.
Episode chapters · 14 chapters
- 00:00IntroductionAudio
- 01:59Xbox hacking and Ronnie's security beginningsAudio
- 04:50Consulting and early mentorshipAudio
- 08:44Security catching up with software deliveryAudio
- 11:54Growing security skills in developersAudio
- 13:11Champions who want to participateAudio
- 16:52Embedding security with engineering teamsAudio
- 18:37Advantages of a smaller company's technology stackAudio
- 22:52Why large-company security cannot do everythingAudio
- 24:25Working with development processesAudio
- 25:47First priorities in a smaller companyAudio
- 29:04Making progress with resistant teamsAudio
- 30:55Enterprise visibility and management through metricsAudio
- 33:24Four foundations of an AppSec programAudio
About this episode
Which parts of an AppSec program should change as a company grows, and which should stay the same? Ronnie Flathers joins Chris and Robert to compare security work in a fast-moving smaller company with the challenges of a large enterprise. He explains the advantages of a consistent technology stack and close developer relationships, then explores what breaks when one team can no longer know every application or manager. The discussion covers developing security champions, meeting teams where they work, and making incremental improvements instead of chasing an overnight transformation. Ronnie grounds the comparison in four principles: visibility and transparency, enabling rather than hindering, iterative progress, and management through metrics. The starting point is understanding what exists before deciding how to secure it.
The Application Security Podcast is brought to you by Security Journey.
About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
→ Learn more about Security Journey
Connect with Ronnie Flathers:
→ LinkedIn
→ Ronnie’s blog
Resources
→ Darknet Diaries
→ OWASP Juice Shop
→ Agile Manifesto
Actionable
From this conversation
- 19:14
Secure a shared technology stack first
Focus on getting that one technology stack secure
- 23:22
Equip team-level security champions
Identify key individuals within each team
- 24:54
Build security into the SDLC
Don't treat them separately, bake them into one
- 29:12
Make small security improvements often
Make small improvements often
- 31:29
Build an application inventory before scaling
Get a handle on what you have, document where it is, what you have
Transcript · 38 min conversation
0:00Chris RomeoRonnie Flathers is a security guy, a pentester, and a researcher. In this conversation, we explore his experiences building application security programs. He's had the opportunity to program build inside of a small company and now is doing it at a large company. We hope you enjoy this conversation with Ronnie Flathers. I want to take a moment to introduce you to Security Journey. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term sustainable security culture among amongst all their developers. Our approach is to provide security education that is conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important. The modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style, that allow developers to put what they learned into action. And lastly, fun.
0:55Robert HurlbutTraining doesn't have to be boring.
0:56Chris RomeoWe make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo, the application security podcast.
1:13Robert HurlbutHere we go.
1:33Chris RomeoHey folks, welcome to this episode of the Application Security Podcast.
1:36Robert HurlbutThis is Chris Romeo, CEO of Security Journey, and I'm joined this week by Ronnie Flathers, who has a lot of knowledge and experience in the world of application security, software security, and also building programs both at a small, maybe startup-y kind of organization and working in large organizations and building programs.
1:57Chris RomeoAnd so Ronnie, you're a new guest to the show.
1:59Robert HurlbutWe always start with the question, what is your security origin story, if there was a comic book, I don't know what your comic book would be called, but what would episode 1 look like to explain how you got into security?
2:13Ronnie FlathersSure. Well, first of all, thank you so much for having me. Pleasure to be on here. I think the origin story we could trace back, and if I had to summarize it in one word, I would say free Xbox games. I think my first foray into security was the original Xbox and learning how to mod the console so I could play free games when I rented them from Blockbuster. That was kind of what actually got me sparked and interested in security at that time, reading about the modchip scene and the whole console hacking scene. A lot of it was way over my head, but that was the first time I really started to kind of explore these topics of security, security boundaries, what these were doing, how to bypass them, and got my hands dirty with some code and hardware as well. That could be the origin story of what kind of sparked the interest in me from high school.
2:58Robert HurlbutOkay, so this is high school. I'm going to guess this is late '90s, early 2000s? just based on Xbox, the original Xbox. And so you're in high school, you know how to code at this point, or are you really just into the Xbox games?
3:13Ronnie FlathersI, I have been a computer nerd since I could sit at a desk, uh, and I was fortunate enough that my parents had, um, computers all the time, so I got to play with them. I taught myself to code. I loved it. I enjoyed it. So that was kind of what started to get me into it and blend that passion of working with computers. In high school, Taking a few programming classes, whatever was available to me, was also kind of sparking that interest in getting there. But I actually ended up going to college and didn't have an interest in pursuing software at the time. I went to college and went to business school and got a degree in real estate finance because at the time when I was there, I did not think I wanted to go into a career of software development. To me, computers, software, hacking, that was just the hobby. And I hadn't yet seen that career path for me yet. And that kind of became more evident to me post-graduation of college when I realized that I could actually do what I love doing as my hobby professionally.
4:09Robert HurlbutYeah, that's one of the keys to a happy career is do something that you would do for free, but yet they just happen to pay you. Turns out quite well in the world of security, right?
4:19Ronnie FlathersYeah, I was lucky enough. I took one elective in college on security and my teacher told me this amazing term that changed my life called penetration testing. And suddenly it dawned on me that there was a career out there that I could get paid to break into things and hack things. And that was an industry that was really starting to take off. And that totally changed my career perspective. I decided to not go into the mortgage industry and go into the penetration testing industry instead. And flash forward a couple, almost a decade, and I've been in security ever since.
4:50Robert HurlbutSo what does your first stop look like then coming out of college as somebody who's now gung-ho about the whole idea of penetration testing? Did you go to kind of a big company, big firm to be able to develop those skills? Small company, what's, what's the lineage look like there?
5:05Ronnie FlathersYeah, I was, I was again just very fortunate. Kind of an opportunity fell, a door opened, and I walked through it. I had no relevant experience, no degree in security, even not even a technical degree, but I was self-taught and I felt fairly confident in my skills if I could just get in the door to have an interview. And I got an interview with a smaller consulting company based out of Chicago called NeoHapsis. And I'd never been to Chicago before, and NeoHapsis interviewed me, took a chance on me and I got hired on as a junior associate consultant with NeoHapsis and moved to Chicago for that job. And it was, it changed my career. It was the best experience and best decision I could have made. Getting into consulting, while it could be exhausting, especially when you're highly billable and hitting the road, but I got exposed to so many different companies, so many different technologies, did a lot of different penetration testing, everything from network security assessments to, then actually that was my first foray into sort of application penetration testing, then the mobile application application penetration testing and mixing it up with different projects every couple of weeks really let me hone my skills and worked my way up from being a junior associate consultant at NeoHapsis to actually being the practice manager and managing a team of technical consultants in the Midwest.
6:19Robert HurlbutYeah, I think there's a couple lessons learned there. I didn't go the penetration testing route, but somebody, you know, a small company took a chance on me as a sysadmin that just happened to be a security company. I didn't even know what that meant. at the time when they hired me. And so, I was able to follow a similar path you did as far as growing and having people pour into me that really weren't looking to get anything in return. It was just like, hey, we want to help make the industry a better place. And so, I think that's a lesson learned for those people that are in our position now that have been around for a while. Like, we have this— we got to pay it forward because there are those that helped us along the way. The other thing is for those that are new to the industry, You just got to get in the door, right? That's what I tell people now. It's like, I don't care what you got to do, even if it's not in security and you're like, I love security, start at the help desk, be the best help desk person that they have, and then they're going to come and ask you, what do you want to do? Do you want to do this anymore or do you want to do something else? Because you're awesome and we'd love to have you do this forever. But then, so you got to look for that opportunity to be able to transition to something else along the way.
7:22Ronnie FlathersYeah, absolutely. And I found over my career too, and the security industry as a whole is generally very friendly and easily to, uh, easily easily networked, whether you're an online presence or going to security conferences. I love chatting with people who are either recent grads or trying to break into security. And as I'm sure you know too, the security industry, although it's growing, is still a pretty small industry. And when you know someone who knows someone who knows someone, getting that foot in the door, just getting your name out there, is that huge first step.
7:51Robert HurlbutYeah, I truly believe there's 2 degrees of separation in the world of security. It's not the 6 degrees of Kevin Bacon or whatever. Like, it's— there really are. Like, you and I could sit here and go down a list and like we could name the people that we know, that we each know, that would vouch for both of us. Like, it's just— that's just the way this thing is. So, uh, we definitely need more people, and, and that's certainly the direction we need to go in.
8:14Chris RomeoWell, great.
8:14Robert HurlbutIt was great to hear your perspective on where you're coming from. It's funny, I was just listening to the latest episode of Darknet Diaries, another podcast I really enjoy, and they're actually interviewing a bunch of Xbox hackers from that same time frame.
8:27Ronnie FlathersOh man, they're my own heroes then. I gotta listen to that.
8:29Robert HurlbutYeah, you should. They broke into basically all the big game companies and were downloading the before they released so they could play them. And so it was just funny when you start talking about it, I was like, I've been thinking and thinking about this story just recently. So definitely something to check out.
8:44Chris RomeoSo I guess the first big question that I had for you is I wanted to get your take on what do you believe the current state of application/software security is?
8:54Ronnie FlathersYeah, absolutely. So it's a big question, but I think I'll answer it with telling you just a little bit more of my experience and how I've kind of seen it evolve. As a consultant, like I mentioned, one of the biggest benefits I had was that I was exposed to just a wide variety of clients and a wide variety of security teams. So even if I was doing a penetration test, or if I was just coming on to help do code reviews or architecture assessments, I always worked with the security team and was just observing while I'm on site with these companies, how does the security team operate? And how does the company operate around the security team? And through that experience, I definitely saw programs that were successful that I felt worked very well. and programs that, you know, I felt like were not working very well. And I think it kind of ties into how I view the current state of software security, which is very probably very much the way that software development was, but a couple of years ago. I think security is generally lagging a little bit behind where the world of software development is. And whereas in today's age, software development has fully embraced the DevOps mindset, the agile mindset, cloud native or rapid development type mindset, security, if you want to keep the analogy going, is still sort of in that waterfall era and starting to dip their toes into application DevOps or DevSecOps is the buzzword you always hear thrown around.
10:14Robert HurlbutYeah, and I think, you know, there certainly are some organizations that are very much cutting edge, but then I'd agree with you. There's a lot of, there's a lot of companies that are lagging behind just because they don't have the, maybe the knowledge or the experience. And let's face it, back to what we were originally talking about, this is a tough industry to hire somebody. I got a list of friends of mine who are looking for application security people and I just collect them at this point. I collect them on a list and I'm like, I'll tell everybody I know, but the chances of you filling this unless you get really lucky or pay a lot of money are pretty slim because there's just a lot of demand in this industry right now for what we do as software security professionals and there's just not a lot of us floating around. So yeah, I totally agree with you on that.
11:00Ronnie FlathersI feel that talent shortage firsthand every day. In fact, if you know anyone who's looking for a job, let me know.
11:04Robert HurlbutI'll add it to my list.
11:06Ronnie FlathersBut yeah, it's because I mean, if you read some of the descriptions, it's like what's necessary now to run an effective application security program is we need someone who's basically fluent as a developer, is familiar with all the latest JavaScript frameworks or latest DevOps tools and DevOps technology. Oh, and on top of that, we also need you to be a security expert. And those are the types of unicorns that I think all the companies are trying to compete to hire on right now. And it's extremely difficult to find. And I don't think that that's a sustainable model.
11:35Robert HurlbutNo, I don't either. And that's, uh, yeah, I mean, a number of friends of mine, I'm sure like friends of yours, are— by the time you learn that somebody is unhappy, they're already at a new job. And all you do is you see like, oh look, they got a new job. They were unhappy on Thursday, and on Monday morning they started their new job because it's that crazy of an industry.
11:54Chris RomeoYep.
11:54Robert HurlbutSo yeah, that definitely does play into the current state of software security, the fact that security is lagging behind where some of these some of these development resources and development frameworks and things are at. So what else? What other reasons do you think, or state of software security?
12:09Ronnie FlathersYeah, I think kind of building on that training, it needs to kind of be a little more updated as well. I think what, what we just talked about, that model of hiring is kind of looking at it backwards. I think a lot of companies are trying to find security professionals and then expecting them to drop in and then learn the development practices, the coding, the DevOps materials, and fit in with a development team coming from a security background. And as we know, that's going to be very hard to fill because there's a talent shortage of security professionals. So I think the inverse is what's going to become more and more popular, and I've seen it work very successfully both here and at other organizations, is hiring from development and teaching them security. And I've seen a lot of, of great security training programs be put into place, and a lot of great success stories where if you have a very good or experienced developer who has an interest in security, I feel personally it's easier to teach security to a developer like that than it is to take a very talented security person who may not know how to code or develop with latest languages and frameworks and teach them that aspect.
13:11Robert HurlbutYeah, I have seen the same thing and I agree with the kind of the inverse that you're describing here. I guess the thing that I've seen in my experience that is a little different than what you said is that taking that developer, you have to find the developer that has the passion.
13:25Chris RomeoYep.
13:27Robert Hurlbutseen too many times where, you know, I mean, if I hear the word voluntold one more time, like, I'm gonna, I'm gonna flip out because I just, I can't, I hate that as a term. Like, nobody should ever be voluntold because what does that mean? How much effort are you going to put in if your, if your exec says, oh yeah, you're our security champion now?
13:44Ronnie FlathersThat's true.
13:44Robert HurlbutYou're going to be like, this sucks, I want to do whatever I have to do to make these people leave me alone. There's no passion in that. And so, like, when I've run security advocate programs in the past, I want the people that live eat, breathe security and just happen to develop during the day, you know, as their day job, but they really love this security thing and they've got that passion because it's like throwing gasoline on a fire. When somebody's got that passion, it's a big— it's a poof, right? Because all you got to do is throw a little bit more on that fire and it just explodes and gets a lot bigger.
14:13Ronnie FlathersYeah, exactly. It's one of those intangibles that's so important. It's hard to quantify. It can be hard to identify, but when you have it, don't let it go. You got to fuel that passion. And yet the same with our Security Champion program here or working at previous companies. I know that I can recognize those developers because they're the ones who are coming to me in their free time and picking my brain or coming up with a vulnerable app like OWASP Juice Shop open on their machines saying, hey, I'm trying to get this cross-site scripting vulnerability. I'm trying to understand it. Like, can you show me how to work this? Those are the developers that we got to be targeting because those are going to be the next generation of the security professionals.
14:48Robert HurlbutYeah. Yeah. And it's funny. So what Security Journey, what my company does, now is we actually do training things like what I did at Cisco with the Cisco Security Ninja.
14:58Chris RomeoAnd people, our customers always ask us, well, you know, how do we find our security champions?
15:03Robert HurlbutHow do we find them in this big organization? Like, I can tell you some, I can give you a list of people that you should go talk to. And they're like, how can you do that?
15:10Chris RomeoYou're not inside our company.
15:11Robert HurlbutI just go and look and see who's gone through the training at a super high rate of speed.
15:15Chris RomeoYeah.
15:16Robert HurlbutLike, if somebody's gone from, you know, we have 3 kind of primary levels of learning, white, yellow, and green in our system of security belts. And if somebody's gone through those 3 belts, which is like 40 hours of investment time in like 3 months, that's somebody you want as a security champion because nobody told them they had to do that. They decided in their nights and weekends that, oh, this security thing is pretty cool. I want to go spend some time actually getting involved and learning more about it on my own because I see a future here.
15:41Ronnie FlathersYeah. And I think to even make it easier to identify that type of talent, you know, you may have that organic talent within your organization that's just chomping at the bit to become a security professional or an application security specialist. It kind of leads to the next point I was going to make the trends I've seen in software security, which is security needs to collaborate a lot more and more closely with the development side of the house. And the security programs that I've witnessed over my career that I'll say are the least successful are the ones that have built walls and silos around themselves and don't know what's going on on the development side of the house. It's kind of just chucking findings over the wall and expecting the developers to deal with it, or the security professionals who have their heads down in tools and are just scanning code after the fact and then throwing Jira tickets back to the developers. you don't get that collaborative atmosphere in which you can learn from the developers and the developers can learn from security. And when you have that collaboration going on, you're actually hosting joint sessions or learning sessions together, and you're identifying the developers that have that passion in security, it's going to help you grow your security team more, and you're going to build more trust between your security team and the development teams, which benefits everyone in the long run.
16:52Robert HurlbutYeah, I love to hear the stories of security people who are embedded in like a Scrum team. Like, I've heard stories of some organizations where They'll have a Scrum development team and then there's a Scrum Master and then there's a security resource who's assigned to that team. It doesn't necessarily mean they're in every little bit of things that are happening with that team, but they're available. They're in the daily standups. So if somebody brings up something with security, they can be like, they're the ones that all the developers kind of turn to if they need some guidance. And so it's that type of an embedded approach that really gets to the point where it really enables collaboration amongst developers, amongst the security people.
17:28Chris RomeoYeah.
17:28Robert HurlbutAnd yeah, I'm with you then. If I hear about an organization organization that's like still throwing things over the wall, I'm like, man, that's— you're in some trouble here because your security people are all not going to stay very long because we got a lot of options, and if we can't make stuff happen, we're not going to stick around.
17:46Ronnie FlathersWell, yeah, I think that's the other thing too is I can speak for myself, but I think a lot of security professionals, we get burned out if progress isn't being made. Nothing disheartened me more when I was a pentester than revisiting the same client a year later and identifying all same vulnerabilities. I feel like I'm not providing value that way. And, you know, I think it can lead to burnout in our industry if you are just grinding your wheels 24/7 and you're not actually watching security improve. And those types of organizations where security is siloed, security is, you know, in an ivory tower and not embedded in actually helping the developers and the rest of the company get better, not only are you not improving the company's security posture, you're also probably going to burn out your security professionals Yeah, and as we know, they'll just find another problem to solve somewhere where they have better support.
18:37Robert HurlbutSo, um, one of the other things I wanted to discuss with you, Ronnie, was you've got— you've had some experience in building programs from a small company perspective and then building programs from a large company perspective. And so I think there's some interesting lessons to be learned there and some, I don't know, compare and contrast to— because we have listeners who are in small startup-y kind of companies and we have listeners who are in gigantic, you know, mega organizations. And so what, I guess, starting with the small company perspective, what are some of the unique things about building a program inside a small organization?
19:14Ronnie FlathersThe company I was at previously was, was a fairly small company, certainly not a tiny startup, but, you know, around 500 employees. And in addition to being small, if you can call that small still, what I think one of the main benefits or fun parts was, was it was a very young company. And so the company was founded and birthed in the DevOps era. It was founded and it was birthed in the cloud era. So from the beginning, our product architects and our product engineers designed everything to take advantage of the latest and greatest technology. So we were early adopters of Kubernetes. We went full containerization right off the bat. We were 100% in AWS and leveraged all the cool, any security feature we could find with AWS or infrastructure feature we could find with AWS. The main benefit to working in a company like that was homogenization. All of our infrastructure, all of our dev platforms, all of our infrastructure platforms were the same. We knew we had one production environment, and that production environment ran on DCOS on Mesos and had containers and was only hittable from this Elastic Load Balancer. Everything was the same. So my security team there, we were able to design security solutions once that we knew would work and affect the entire company. That was one of the fun aspects there that I think you definitely don't get as a company grows, both organically and inorganically, and you end up with different platforms, different types of applications, different technology stacks. When you can really dive and focus in on like one technology stack and focus on getting that one technology stack secure, you'll find you can make a lot of progress. Now, there's other pros and cons to working in a company that size. One of the cons was everything had to move fast. As an earlier-stage startup, the most important thing was getting product to market. Security came second, if second at all, just security came later. I'm not faulting the company at all. I think actually, for a lot of early-stage startups, security maybe shouldn't be your number one priority. If you're fighting for the survival of your company, and you need to get something to market, that may be a decision you're going to have to make to just put security second or put security third later and focus on on shipping code and getting something out there quickly. That's one of the cons, but it was also a pro because the pro meant we were able to move so quickly that when a security vulnerability was discovered or we identified something early on in the development process that needed tweaking, we could get that change also into production and eventually into our customers' hands very, very rapidly as well. So young or small companies like that that operate in that agile, very, very rapid environment, it, it comes with both pros and cons. The drawback might be you're moving so fast that security can't keep up, but the pro is, well, if security can get their stuff together and tell you what needs to get done, it'll get done really quickly.
22:06Robert HurlbutYeah, I almost saw that as both a pro and a con.
22:08Ronnie FlathersYeah.
22:09Robert HurlbutThings are moving so fast you can't keep up. That's a good thing because if we have a new thing we want to do for security, we could probably just throw it in as it moves through. Yeah, so that's interesting though to think about that.
22:18Ronnie FlathersThat's definitely a pro and a con. Um, and, and the other pro from just being in a small company is that collaboration is easier.
22:25Chris Romeohere.
22:25Ronnie FlathersIf you're running an application security team and you know every developer manager by name and can get lunch with them because you're all in the same office, you're naturally going to collaborate better and have better relationships and be able to just walk over to someone's desk area and ask a question. And you definitely lose that at a, at a larger company.
22:44Robert HurlbutYeah, so that's helpful to get that perspective on programmatic approach to software security, application security in that small company.
22:52Ronnie FlathersNow let's change gears and talk about the One of the bigger lessons I think for a security company or a security organization in a larger company, specifically an application security organization, is you can't do everything yourself. That scenario I just mentioned of knowing every development manager by name and just being able to walk over to their desk and strike up a conversation and ask some security questions goes out the window when you have 15,000 developers spread across the world.
23:21Robert HurlbutYeah.
23:22Ronnie FlathersSo the lessons to be learned there are you can't do everything yourself and you have to leverage whether they're security advocates, security champions, or identify key individuals within each team, within each Scrum team or business unit or product unit that can be security people for you. And having that collaboration in a large organization is absolutely critical. One of the biggest pros I see to a larger organization is when you have that many quote unquote resources at your disposal, hundreds of security champions, tens of thousands of developers, if you can train them right and have them start writing secure code or security, application security teams in the dozens, you can get some amazing things done. It takes a bit more coordination. It may take a little bit slower. We're not gonna be as rapid or as agile as a company made up of 20 developers, but when resources are coordinated, working for a common goal, the impact can be tremendous, something higher than could ever accomplish at a smaller company.
24:25Robert HurlbutSo, when you think about the process, you know, when you think about a large company's approach to the program, there's always a secure development lifecycle that's driving because in the large company experience, you have to have some type of a process to fall back to because if you don't have it, then people will say, well, we don't know what to do, we don't have a plan. And so, Did you see that in the small company experience as well? Is there a process? Do you even have an SDL in a small company?
24:54Ronnie FlathersYeah, I think you definitely can, but especially at a young company, your security development lifecycle is also going to be being developed alongside your software development lifecycle. I like to always say that the maturity of your application security program is going to be pinned to the maturity of your engineering program. You're never going to have an application security program that's more mature than your developers. You're going to have to keep pace with that. So, if you have a company that has a very immature software development process, it's going to be hard to have a very mature application security development process. They have to go step in step, and you have to work kind of simultaneously if you're a younger company to improve your engineering processes and improve your application security processes. Or even better, don't treat them separately, bake them into one, and just consider all of that as part of your SDLC.
25:47Robert HurlbutI'm gonna ask you a question here, kind of 2 different ways, one for the small, one for the large now, so that we can give our listeners some actionable things to think about here. So, if we go back to the small company perspective, let's say that we just dropped you into not the company you were working with before, but a brand new company, similar size, 500 developers, relatively new, lots of new technology. What are the first 3 things that you're gonna do? do to establish your program for that small company? They haven't done anything before. I should have said that as well. They've done nothing except for build awesome software that uses all the latest standards.
26:26Ronnie FlathersI think there's an equation. I can't take credit for it, but it said culture is better than processes, which are better than tools. And that's kind of the, the way that I would organize and apply my efforts. First is building that culture. If we're building a security program, going back to what I said earlier of programs that have walled themselves off or are unhealthy within an organization, that starts within the first 90 days. That's really, really critical to get right. How do you want to build your security program within a company, and how are you going to define it? Because as you start setting that groundwork down, it's going to be hard to change later. So I know that's kind of a cop-out answer, and it's not like a tool that I'm going to go out and buy, but it really is just trying to become much more visible, much more public, and much more collaborative with the development teams and leadership and management as well. One of the tenets the application security programs that I built, both at the small company and that I'm building currently here, is transparency and visibility trumps all. We cannot build security programs anymore that are shrouded in secrecy, that we make decisions and then our decisions are final, but we don't need to justify them, or processes, developers going to a gate and being told, no, you can't go to production, but not having any indication as to why or that that was even coming. And unfortunately, that starts at the top with how the culture is going to be designed. So building and stressing that transparency and visibility is really important from a culture perspective. Now, then that bleeds over into the processes. So how do you want to do your security processes? How are you going to design your security development lifecycle? And then keeping that core principle and belief in mind will dictate how you want to do security scanning, or if you want to do release gates, or checklists or guardrails or automated releases if you're in like full CI/CD, what sort of processes are you gonna put around that? And then finally, the last important third step, but the least important of the 3, is what tools are we actually gonna use to support that? I think I have seen organizations, and to be honest, I have fallen for this mistake myself too, where the tool comes first and I see a really cool, amazing new application security tool, and chase that without first having the process around it on like how we're gonna use it, how we're gonna report on it, and where it's gonna slot in. And do we even have the culture to support it right now? Do developers want this? Are they gonna look at this as another chore or another task, or are they actually involved and want to collaborate with us on this new tool? And doing it backwards will have disastrous effects. You'll end up with tools that nobody wants with zero processes around how to support them.
29:04Robert HurlbutAnd then you get to the point where you're a security team that nobody wants to talk to. And when you come to their cube, like put their headphones on or something.
29:12Ronnie FlathersYep, exactly. The other kind of tenet that I'll talk about of my application security strategy is it's okay to make small improvements. I like to say that DevSecOps, I know that's kind of a buzzword, is as much about injecting security into DevOps as it is taking lessons learned from DevOps and applying them to security. And one of the main principles of like the DevOps Manifesto or the Agile Manifesto is make small improvements often, shorten that release cycle, and it's okay to just like make small improvements and get it out the door faster. And I love that lesson to be applied to security, where we don't need to go from 0 to 100% secure overnight. We're never going to be able to get there, and we're also not going to be able to buy our way there with specific tools. We're not going to be able to hire our way either. All we need to focus on is how do we get a little bit better every day, or how do we get a little bit better every sprint. And if that means that we are looking at scan results that come back vulnerabilities with 1,000 criticals and we can only remediate one today, that means that we are one less critical vulnerability, and that's an improvement. And it's really just focusing on those small wins and just trying to make them happen more often than looking at the big picture and being, oh my God, we have 1,000 critical vulnerabilities, stop everything. Like, what are we going to do? We need to hire, we need more tools, we have to do this. Just focus on doing what you can and getting better over time.
30:36Robert HurlbutYeah, small improvements are definitely the way to go. To learn the lesson about small improvements, all you have to do is build your own web-based application that's a product, and you learn very, very quickly that small improvements are the only way you'll ever receive any amount of happiness or joy on a daily basis.
30:55Chris RomeoYeah.
30:55Robert HurlbutBecause it's fixing a bug, it's making a security issue go away, and it's really a powerful way to get to the point where you're having an impact each and every day. So, if you're going to do this on the bigger, on the large company side, then let me ask you this. Let me change the question a little bit. Is it still culture focused on visibility with dev teams and execs, process ensuring you have the right things, determining whether it's— if the process is there, and then the tools? Or is there a different order for you in a big company?
31:29Ronnie FlathersNo, I think those are the same. It's sort of the same top-down approach and the same core tenets of application security strategy, you know, Here, I've stressed the four foundations of my application security program are visibility and transparency, enabling not hindering, being incremental and iterative, and management through metrics. And I think that that last pillar, management through metrics, is what is really important in a large organization that may be less important in a smaller one. And the reason I say that is going back to my example of knowing all the development managers by name. and being able to sit in stand-up meetings and have an idea of what's going on within the company, that flies out the window. There's no way that in a large enterprise, any one person or even any one application security team will have an idea of what's going on 100% of the time within the company. So no longer can you just rely on one or two people with an idea of what our release schedule is and what products we're shipping out the door and what those security scans might look like or how many vulnerabilities there are per team. When you get to numbers that are outside of the human brain's ability to actually just store and comprehend, you have to start pulling metrics, and metrics have to drive every decision that you're gonna make. And the first step in getting metrics is having visibility. And so visibility in a large enterprise means, what applications do we even have? Who owns them? Where are they? And just building out some sort of change management database, or building out some sort of application inventory list, list is the first thing that I've been trying to work on here in this new role, and I think would be the first thing I'd recommend for anyone coming into an immature security program, is get a handle on what you have, document where it is, what you have, and then make all the next decisions you need to on how you're going to secure it.
33:24Robert HurlbutLet me read those 4 tenets back to you because I only got 3 out of 4. So, the first one was visibility and transparency that you talked about from the small and large company perspective. The second one, either second, 2 or 3, was something about iteration.
33:37Ronnie Flathers2 was to enable and not hinder. I like to tell my application security employees, take no out of your vocabulary. We're not necessarily here to say no. We should always be saying how. And that kind of dives into the culture of collaboration. If we just scream no the first time anything comes up, we're going to get bypassed. So, we need to enable. Our job is to enable developers to make secure decisions, not to hinder them from doing their Okay, and the third one was something about, I got iteration, that's all I wrote down. It was to be incremental and iterative. And that's the concept of small wins often. You know, let's chip away and make our security posture a little bit better every day and never lose sight of the big picture, but don't get overwhelmed by the big picture. Focus on what we can do right now.
34:21Robert HurlbutThat's a list. I wrote it down here. I'm gonna take that with me. I'm gonna use that at some point in the future because I think you're onto something here. Visibility and transparency, it's all about the culture. It's about how do you interact with the people? How do you ensure they can see what you're doing? There's nothing, you're not hiding anything from them. Enabling, not hindering. This is the idea that we're no longer the department of no that everybody remembers from the good old days. Like, we're about, we're not about no, we're about, hey, let's make it happen securely. Thanks for coming to us. And then incremental and iterative. We talked about that, about how we want to be doing things in small changes so that we can have impact as quickly as possible. And then management through metrics. It's all about, you got to know what you got. You got to know, be able to measure the improvement so you can determine, hey, are we actually having Are we getting something out of all this money we're investing, or are things the same?
35:07Ronnie FlathersCan we demonstrate that we're even worth what you're paying us? Like, what is the value we're bringing here, right?
35:12Robert HurlbutYou must have gone to business school. That's definitely a business—
35:17Ronnie FlathersThere's something good that came out of that. All right.
35:19Robert HurlbutNo, I mean, I think it's— I love to hear stories of people that have come to security from different backgrounds and different perspectives because we can't all think alike. We can't all come from the same school of thought. that's nothing but trouble. I mean, one of my primary mentors— we're going back into when the years began with 19, back in the '90s— was a guy named Gary Grossman who was a music— he had a master's degree in music and had made his way into the world of security. Brilliant dude, but he would have never passed the— if somebody had a requirement that said you have to have a 4-year degree in computer science, he would have never gotten hired.
35:53Ronnie FlathersYeah.
35:54Robert HurlbutEven though he'd been doing it for 30 years. He'd been doing security for 30 years, years in the '90s, like old school. So, this is—
36:00Ronnie FlathersI admit that myself too, even with my experience and what I've been doing in security, there were still organizations when I was starting to kind of look for jobs about, you know, 6 months ago before I took this one, that if I didn't have a computer science degree, they just HR blocked me.
36:15Robert HurlbutYeah, that's another lesson learned for companies out there, especially when you're looking for application and software security talent, is you got to look, you got to be more flexible because there's a lot of people with diverse backgrounds. backgrounds that have a lot of knowledge and experience, and, uh, don't, don't block them in your HR process because they don't have the right computer science degree. Which, by the way, I don't have a computer science degree either, so there you go. All right, Ronnie, thanks for, uh, taking the time today to talk about all these different types of programs, and I know it's going to definitely impact our listeners and, and help those that are at different stages of building their programs. And I look forward to chatting with you some more in the future. We'll find something else to talk about.
36:52Ronnie Flathersto Thanks, Ryan.
36:52Robert Hurlbuttalk about.
36:52Ronnie FlathersYeah, I would, I would love to. Thank you so much for having me on. And for anyone who's listening, if you'd like to get a hold of me, I absolutely love talking about this stuff. I'd love to hear what your experiences are. You can find me on Twitter @ropnop, R-O-P-N-O-P, or [email protected]. Just send me an email.
37:09Robert HurlbutAwesome. Thanks, Ronnie.
37:10Ronnie FlathersYep, thank you so much.
37:12Chris RomeoThanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Born and And our outro music is Southern Delight by Stefan Cartenberg. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbut. Remember, security is a journey, not a destination.
7,560 words · transcript by assemblyai
More like this
View all episodes →- November 15, 2023 · 51 minRay Espinoza -- The AppSec CISO, Vendor Relationships, and Mentoring
- May 14, 2024 · 36 minDevin Rudnicki -- Expanding AppSec
- December 20, 2022 · 59 minAlex Olsen -- Security champions, empowering developers, and AppSec training