Building an application security program is really about ensuring that security is built into that software development life cycle, but not just into the software development lifecycle. But also, how do we respond to vulnerabilities or findings as we move along? That development pipeline all the way into the operational environment.
Hey everyone. My name is Henry Surya with Robin. And you're listening to the technology, you know, podcast the show where I'll be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. Hey everyone, welcome to the Tecla.
You know, podcast the podcast where you can learn about technical leadership and Excellence from my conversations, with great thought leaders in the tech industry. If you haven't, please follow the show on your podcast app and social media on LinkedIn. Twitter and Instagram for video content. Steckle Journal is also now available on YouTube and Tick-Tock. And if you want to support my work by me, a coffee at technology. Not deaths. Last tip or subscribe as a
patron at technology node. Death, /, Patron. My guest for today's episode is Derek Fisher. Derek is the author of application security, program handbook, and also a security instructor at Temple University, in this episode, direct shared about building, an application, security program, and how to implement it in our
organization. First, we discussed some security fundamental, concepts such as shift, left, CIA Triad and threat modeling direct then outline how to start an application security program and measure the programs. Success, direct also touch on the security program maturity model and gave his tips on how to build and higher application
security teams towards the end. Direct also give his insights on how to address zero day vulnerabilities, when it becomes prominent I think we don't need a reminder. That security is very important to get, right? And regardless, if you're building an application or just using an application, there is an inherent security, risks in the Technologies and software, we use. And I hope you enjoy listening to this episode and learning a few things about building application security program.
And if you do, it will be really awesome. If you can share this with your colleagues, your friends and communities and also leave a five star rating and review on Apple podcast and Spotify. It may sound Simple, but it will help me a lot in getting more people. Discover, the podcasts on the platforms. Let's go to the conversation with Derek after our sponsor message. Are you looking for a new cool swag? Taglit Journal. Now offers you some swags that you can purchase online?
These wax are printed on demand based on your preference and will be delivered safely to you all over the world where shipping is available. Check out all the cool swag is available by visiting technology. You know dot f / shop and don't Get to break yourself. Once you receive any of those tracks, hey everyone. Welcome back to another new episode of the technology. You know, today I have with me, a guest named Derek Fisher.
He's the author of a book titled, application security program handbook, as you can tell from the title itself will be talking a lot about application security and how to build a program within your company or within your team in order to put security at the Forefront of the software development that you do. So direct. Thank you so much for Time. And I'm looking forward for our discussion today. We have thank you, Henry. Thank you for having me on and looking forward to discussing
this topic. So Derek, I always love to ask my guess to share about himself or herself was in the beginning. So maybe if you can spend a bit of time, telling us who you are and what are your highlights or turning points that you think are worth to share your, so in engineering for probably close to 30 years. Of this point, I started out and Hardware engineering actually designing the circuit boards and working in mechanical engineering.
I then moved on to software engineering after pursuing a bachelor's degree in computer science. And while I was working in software engineering got introduced to someone product security officer at Siemens, who then got me interested in to cybersecurity and decided to pursue a master's degree in cyber security from Boston University. At that point got into security engineering security, architecture and started leading
a team and never look back. So I currently run a product security Not a leading Financial technology company. I teach software security at Temple University. As you know, I've written the book on building an application security program and also have written several children's books on cybersecurity as well. Try to stay active in the community. There's always a lot going on and I tend to keep myself busy, but it's been a good journey.
The Foley go to actually your book, the application security handbook. I'm interested when you say, you also wrote a book for children about cybersecurity, maybe he can tell us Little bit more about that book. What made you wrote the book and what kind of content that you are sharing to the kids here? Yeah.
I think we like to use the term shift left in cybersecurity and I think you're going to shift left, it doesn't get any further left and add so the reason I wrote the it's a series but it follows a couple children as they can introduce the technology and some of the pitfalls that you have to deal with. Obviously, you know, being able to set up a device securely password hygiene staying away
from strangers, using game. Some being able to not get scammed during games, so there's a lot of different things. So there's like I said, three books. So, there's a couple things that Concepts that we've through those books, but it's intended to be kind of light-hearted and want a story format. So it's not the typical textbook that. I think we're all kind of accustomed to reading it's developed for children that are in the six two nine, six to ten year old range, they called
middle gray chapter book. So it's meant for that date range of 6 to 10 and you know we look at the way we are. In society today, and a lot of children that age are obviously getting their own devices if they're not using their parents. And so, I think it's important to try to impart some of that security Concepts to them as early as possible. Thank you for sharing that. So, yeah, you are right. Some, it is always better to have the shift left mentality,
right? So, in case of software development, lifecycle shift life means in the earlier process, but I think you go beyond like earlier face of life, right? So teaching kids about cybersecurity, I hope they also get it that these days, we all have to be aware. About security and make sure your data or privacy and security. Best practices being implemented in our day-to-day life, right? Including talking to strangers. Sharing out identity, sharing
our data and things like that. Which brings us to the topic today that we would like to talk about which is to implement application security program in a particular for example company, right? As we all know application security has been at the Forefront. We have seen in the news about security breaches hacking and things like that. Maybe if you can give a little bit of background What is the current urgency for people to start thinking about building application security program
within their company here? I think in the book, the application security program handbook. I talked about how every company is a software company and whether you're actually developing software or using software, you don't companies that their core product may not be software, but they're certainly utilizing it. And so, I think that all of us that work in the software space and understand how software gets made knows that at the very least, there's Body issues, if not security issues.
And so these companies that utilize that software will oftentimes collect data from again, even if their core function is in software, they're collecting data about their clients. About the customers about their product. They may have IP that they're trying to maintain and all this is being housed and utilized by the software that they bring into their organization and it's
only getting more complex. When all of these different products talk to each other and And integrate with each other and send data to. And from each other, there's opportunity there for weaknesses or vulnerabilities and so that exposes the organization suppose the data, that their housing to
malicious activity. So again, even if your core competency is not software development and if your product isn't in-house, develop software, you still have exposure to this and it's critical to understand. What are those vulnerabilities? And how do you resolve those vulnerabilities? When they are detected.
Yeah. And I read in one particular chapter, you also mentioned even though the company is seems to have just a little bit of Technology like enabling website or maybe just exposing something to the internet, right? They also have this kind of risk so that for example, they are being defaced or something data is being leaked out, right?
So all this becomes very relevant, even though you may not be a technology pure company, but once you introduce some kind of Technology, especially internet, right? So things are Coming more dangerous. So to speak you mentioned about building security program. So maybe four people here who are not yet familiar, because we always think security is somebody else's job. Maybe if you can explain to us a little bit more, what do you mean by building application security program?
If you're have any familiarity with the security organization within your company or if you're already working in a security organization, you're probably pretty familiar with the fact that we are very good at being able to protect the perimeter. And that's an old kind of mentality because I see things shift to the cloud. And as we have more sass tools that were using where things are kind of decentralized and not house within a data center, we understand where those entry
points are into our system. We understand kind of how the controls around that, but when your core competency is developing software and when your core product is a internally developed software product, its on that organization to ensure, Sure that we're building security into that product and protecting the data that were collecting and using in order to protect our clients building, an application security program is really about ensuring that
security is built into that software development life cycle, but not just into the software development lifecycle. But also, how do we respond to vulnerabilities or findings as we move along? That development pipeline all the way into the operational environment. So when you develop software and Push it out into a production environment for development, that's not where it ends, right?
There's a constant iteration you're constantly getting feedback from your clients, you have defects that you have to resolve and so forth. And those get pulled into the next set of requirements and development and security is no different one. We find vulnerabilities and operations, or if we find a new 0 days or so forth, those things need to be pulled back into the development environment and
resolve. So having a program in place that is able to really look at that, That entire software development life cycle and integrate security. As part of that entire cycle is what building an application security program is all about. Yeah. So I think I do get what you mean by saying traditionally, we always try to protect the perimeter right, whether it's in pesos the outright and maybe it will class time.
But I guess these days and security threats have becoming much more sophisticated, not to mention, there might be also inside a security threat, but I think these days, there are so many entry points where it's at The vulnerability is can be found and even if you don't do anything sometimes it could also happen that security vulnerabilities are being exposed. Think of like the log4j vulnerability last time, right? Even though you didn't change anything. But yeah, you still exposed
once. These vulnerabilities is found which brings us to the phrase that we commonly hear in the security world and also separate development world, is that you quoted this in the book saying that fixing issues in production is significantly more expensive than fixing prior to production. So this comes back to our Our discussion earlier about
shifting left, right? Maybe if you can explain a little bit more about this philosophy, what does it mean by shifting lab, and why do we always have to care about fixing it earlier than the production? Today, if you look at discovering a vulnerability in the production environment, there's a long path. I mean it's a long and actually relative depending on the organization what type of release methodology that they're in.
But there's a path from the code being developed on a development environment and then all the way to production and there's tools. There's people there's processes that are all in place along that entire Pipeline. And that can involve QA individuals, there could be scrum, Masters project managers leadership that are all involved. In the process of getting that code from a development environment into production and that's real cost, right?
If you think of, we're looking at code going from development to production, but think about it. But vulnerability going from development, environment into production and all along that pipeline. There's been people that have been involved with that code that is potentially vulnerable going along, until it gets into
that production environment. Then when it's discovered in production, you now have support individuals that have to get on bridge calls to figure out what The issue is security, people are called in. You might have to get pull in incident, response forensics depending on the severity of the vulnerability. You now have a very costly of vulnerability. Of course, results May Vary.
You may find a vulnerability and production that's relatively easy to resolve or get to a good spot with and you may have ones that are very extreme, right? But the goal of Shifting left and the goal of being able to push the discovery of that vulnerability earlier in the process is really About bringing security and detection as early in the process as possible. And the way we do that is through training developers to
number one, not real. Its security vulnerabilities in the first place, or at least be able to understand the code patterns that result in Secure software. Additionally, try to layer in security scanning tools as early as possible, so that could be things like static analysis, software, or what we call SCA, or We're composition analysis to look for those vulnerabilities is early in the process as possible. Things like Secrets, management
secrets of Discovery tools. All these can be kind of used early in the process to detect any potential security issues that could manifest in a production environment and then all along that pipeline, you can also integrate other scanning tools that are designed for runtime environments like Dynamic scanners or integrated software testing.
So the goal there, Is to just continue to implement security tools along that path to discover those vulnerabilities before they get to a production environment and there's many different ways of doing that. Now, not to kind of step on the term shift left here, but we're starting to move away application security, the individuals are starting to move away from the term shift left, just because not that we don't want to focus on discovering those vulnerabilities early, but
we don't want to forget that. There's other methods of detecting. Ting, vulnerabilities, and ensuring, that security is integrated across the entire life cycle. Because I think we're now trying to kind of over. Correct for the term shift, left and pushing everything into left hand side at the development lifecycle and sometimes forgetting about the rest of it. Yeah, you made a good point, right?
Security. He's not finished just by having so-called secure code and secure development practices, right? Once you put the code into production, that's where the rubber hits the road. So to speak that way, you have a Because maybe constantly trying to look for vulnerabilities or things where they can attack. And I think I even see it within my company from day to day, they are some just anomalies traffic's like trying to attack by injection or attacked by
other means, right? And there are so many security scanning tools, as well, like hacking tools that people are exposed with easily so that they can use free software to scan any kind of internet port websites and things like that. So I think you are right that we should not be relaxed. Once we adopt secure coding practices, Element pipeline practices. But always try to look holistically before we actually go into all these techniques that you implement in the program, right?
One thing is for people to understand the risk and normally the risks associated with security is summarized as a CIA Triad, this thing about confidentiality integrity and availability, so can you also explain to us what this CIA Triad is? And can all security risk actually be summarized into these three components only. I mean it's not just Those three components, there are other acronyms that leverage the CIA to also include things like
authentication accountability. But when you look at what we do from a security standpoint, it does pretty much come back to ensuring that data is secure and not expose to somebody. That should be that the data is not corrupted and is known to be trusted and that data is available and I say data.
But it the application, the system, it's confidential the data and there's confidential the data The systems are running the way they should be. And that there hasn't been anything tampered with the system when you look at the CIA. A lot of it comes back to those three kind of main principles.
And when we talk about the different ways of trying to integrate security to ensure that we're maintaining the confidentiality integrity and availability, just from a high level with confidentiality primarily. We're talking about encryption making sure that data is encrypted at rest and Transit and in use with Integrity were ensuring that we have. Of hashing and check sums being
used. Just to ensure that the data that was sent is the same data that was received and with availability your building, highly redundant, highly available types of systems to ensure that when something is needed, it's available. I used to work in healthcare space and I think the CIA was definitely I think more prominent in the healthcare space than I would say in some of the other fields that I've worked in.
Not that it's not elsewhere but definitely when you Talk about using clinical applications, that doctors are using to make decisions on patients potentially life and death types of situations. You want to make sure that that prescription that the medication that the doctor is prescribing,
is what the doctor. Prescribed, as what's actually being administered in operating room, you want to make sure that the systems are up and running so that the doctor can get access to that information when they need it and you want to make sure that patient data is well protected and not release again in other fields. Obviously the CIA is still critical but it was very abundantly clear when I worked in the healthcare space, how critical the CIA was, thanks for
explaining that. So now assuming that people understand security risk and you know why it is wise to actually Implement some kind of security program? Where do people start fighting in your book? You mentioned about this thing, called threat modeling as the first step. So maybe if you can explain us, what does it mean to do track modeling and what does it entail? Yeah, there's a couple different ways. Of doing threat modeling.
And I think that we do threat modeling on a daily basis whether we know it or not, we get in our car and we start driving and our mind is already doing whether we consciously think about it or not, we're doing threat modeling. Yo am I going the right direction? Is you're going to traffic is this person going to stop at
this? Stop sign that I'm about to go through and you build in certain mitigation and you determine like whether you're doing the right thing on the basic level threat modeling is essentially asking what can go wrong. There's a lot of Normal processes around threat modeling, including using tools to do threat models. But It ultimately comes down to asking that, basic question what can go wrong and once you identify what that wrong is, you start developing those mitigation and Remediation
efforts. But if you want to get started with threat modeling, there's a couple different tools that I usually recommend. One is the Microsoft threat model tool, which is free to download a wasp also has called a threat Dragon, which is also a threat model tool. Purpose-built for Designing threat models.
Other individuals and organizations will use things like PowerPoint or Vizio or something like that, just because essentially, when you're doing a threat model is that you're drawing out the architecture of the system and you want to understand what the different touch points are in that system, whether the third-party Integrations, or whether they're internal users or external users, you want to know, basically what that attack surface looks like for that
system and then start asking those questions on each one of those integration. Ask the question. What can go wrong? Can somebody spoof this call? Can somebody tampered with the data that's coming through? Can someone perform at the denial of service? Can someone change their access level from a simple user to an
admin user? And you go through that with each one of those interactions with the system and as you do that and identify like, oh yeah well somebody can perform a denial service while is this high enough risk for us to integrate highly available system for us to be able to to mitigate or remediate that denial of service attack. And so that's the basic process of threat modeling is designing
that architecture. Identifying the interaction points and start asking those questions about what are the different attacks that could be performed. And then what are we going to do about that? Now, there's also a more what we would call like a manual threat model process, which is essentially getting a bunch of individuals into a room with a whiteboard and doing the same thing where you draw out the architecture, you start asking
those questions. But the tools using something like owasp threat dragon or Microsoft, threat model tool, or there's commercial off-the-shelf, threat model tools as well that exist. But using any of these tools means that an individual or a very small group of individuals can work on that threat model. You can put into maybe a central location where you can store those threat models their
digital format. So they're easy to maintain and handout that's the benefit of using a tool for threat modeling. But when you look at doing a manual threat model on a whiteboard, It's more time consuming you can't really take your white board and check it into a repository somewhere, but you're going to tend to get better results in those manual type of threat model environments because you're going to get more collaborative responses from the people that are in the conversation but it
doesn't scale as well. So yeah, there's some trade-offs. But again, it all comes down to ask that question. What can go wrong and what are we going to do about it? Thanks by explaining about threat modeling. So, for people who haven't done this before, how frequent should they do this?
Exercise is it like every time there's a new thing in the architecture or is it like periodic thing like maybe every quarter every month is that some kind of advice that you want to give people when they should do track modeling, and after we collect all these threat, modeling findings, how should people collect and prioritize? This and also explaining to the whole company or maybe the management that okay. At some of these are real risk that we should work on here.
Are it comes down to understanding what the risk level risk tolerances of the Organization. And that's a very key component that I think we're missing in many companies is, how do you really know what the risk is of the findings that you find in your software? And we don't always do a good job of that.
We know generally what our Flagship products are if you're working inside an organization, you know what your Flagship products are you know where your crown jewels are in terms of data, you know what, the critical workflows are and So you can determine like, okay, well this vulnerability that we found impacts this application has potential to compromise this
data, that's high risk. So we should tackle that however, again we're not great at being able to make that decision quickly and in a very calculated way, it tends to be more individuals making. I don't want to say gut reaction, but it sort of is people saying, oh, this is our Flagship product with a lot of sensitive data there. For, it's got to be high risk. But risk really comes down to technical risk and business risk.
There's technical risk of, are we going to lose confidentiality the Integrity of the data, the availability of the system? And then from the business side, do we have compliance concerns? Do we have contractual concerns? Do we have dollar amounts that are assigned to downtime for this application and marrying those two together? Really? Give you the overall risk of what that vulnerability might be in the context of that application.
I think we're kind of missing that context and a lot of organizations, in terms of, how do we frame those into those vulnerabilities that we find? How do we frame them into the right context of the, we know what we're tackling because prior to zation and really understanding how we prioritize, the vulnerabilities that come in need to be put through that lens of risk. But the other side of that is from a technical standpoint is, what's the exploitability of
this vulnerability. And that's another kind of piece that we're not as a An industry, graded getting to, and we can find application. Security teams can find vulnerabilities. All day penetration testers can find vulnerabilities all day two, and we have no shortage of ability to be able to find vulnerabilities and talk about like, hey, I found 10 new vulnerabilities today. Great. What are we going to do about? It are these really actual issues that we need to be
concerned about? Are they going to actually go into a production environment if they go into that production environment? Are they actually going to Exploited because if in any mature organization, you're going to have runtime protection, you're going to have segmentation, you're going to have all these other controls in place that may make that vulnerability on exploitable. So understanding, how to prioritize, vulnerabilities and understanding. How to really contextualize them
is not easy, it's understanding. What is the organization's risk? What's the exploitability of that vulnerability? And, you know, putting that together and making it a decision quickly? When you do find those, and you find one that hey, this phone, Ability here is in a very high-risk application. It has potential to expose a lot of data which is going to put us at compliance risk.
And yes, it is exploitable because we have no mitigations in front of it. That should be a, I don't want a slam dunk, but I think that's a typically, a slam-dunk for organizations and say, hey, that's the one we need to go after not the other 50 that we found that are unexplainable. And I think, for most of organizations getting to that point and being able to show like, hey, here's a valid vulnerability, that Is going to be impactful.
That's what they want to chase. They don't want to chase the other 50 that are just not, you know, of a concern and you. All right. Oh so like we can always find vulnerabilities, right? But what to do about it because sometimes it could be in hundreds and thousands depending on what tools you integrate. And speaking about tools, you earlier mentioned things like Dynamic equation, security testing, static analysis of a composition analysis.
What are the possible things that actually a company or organization can introduce within their security program up? Art from those that you have mentioned. And where should people start? Because we have so many. Right. I don't think any new company can easily just introduce all of them, but where should people prioritize?
Maybe start as the easiest one first, or maybe the most impactful ones, maybe you can give us some guidance here, securing the development, life cycle can be done, a hundred different ways, and there could be any combination of calls and I know talking to some of my peers and looking at others in the industry, you can see where some are doing things that are completely Different and some are doing things that are very similar to what I'm doing my company.
And I think it really comes down to a few things. One is, what's the budget tolerance? You know, if you're on a shoestring budget, when you don't have a lot of cash, it just throw it problem, then you
have to be creative. If you are less constrained in that area, then you can have a little bit more leeway and being able to build a more robust security development program, but it does come down to at some point finding more vulnerabilities isn't making you more secure and but in fact it made Make you you're not going to get invited to the Christmas party and stuff like that because all you're doing is finding more vulnerabilities and making everybody angry.
So I think at some point you have to get quality over quantity and you know with all that being said, I think it really does depend on the organization. What is the business budget tolerance and what is your risk as an organization? If you're a company that has no sense of data, you are not processing credit cards, you're not holding client data. There's no It's information.
You're not going to want to integrate all the security tools that Gardener puts out there and layer them all into your development pipeline. You're going to be a little bit more measured in that sense. But if you're a large organization with high risk data, high-risk workflows, then, yeah, you're going to have a little different context. But the way I usually try to approach it is that think about
what are you trying to discover? And if you're looking to discover vulnerabilities, the way to start with, that is in those runtime type of, to Tools. So dashed or I asked the other thing is get a penetration test. If you're going to use a third-party that's fine, if you have people in house that can do
it, that's great. But you want to find out what are our surface vulnerabilities that we need to be concerned about ones, that would actually show up in an environment and those tools Bast. And I asked and using a penetration testing engagement, will help you get that information relatively quickly, but there's the concerns around scope. Like that, we get everything. When the application, are there any hidden Corners that didn't get caught by the scans? And then SCA software
composition analysis. To me, it should always be integrated. It's very low friction, usually low cost, there are open source, tools out there, that can help you. You can build your own based on some open apis for access to things like the nvd national vulnerability database to get, just basically look at your libraries and understand which one of these libraries He's have known vulnerabilities in it, that we need to replace.
And that again, to me is just low-hanging fruit set, aside the code that we're developing, the code that we're pulling from repositories and third, parties. Are those vulnerable and tools, like, SCA will certainly help with that. And so I think those, you know, the getting the surface level vulnerabilities, and getting the vulnerabilities that exist in the libraries are using our core application security planks. I would say, in terms of building, Program.
And then you start turning the screws are a little bit looking at static analysis because they tend to be noisy. And they tend to turn out a lot of vulnerabilities but you can integrate them in the development environment and if you have a properly tuned, if you're using a good tool and if you have Smart engineers and smart application security individuals, then you can get some value out of those and be able to try to head off things before they go into a production
environment. Additionally, started looking at your training program, your security retraining program and making sure that Engineers are getting the security training that will help them try to again, reduce adding those
vulnerabilities. And last thing I would say is like security Champions program, which is really a sign of a mature application security program when you're firing up a championship program because that's usually where the tools are integrated, you're getting the vulnerabilities.
Now, you need additional help in trying to resolve those vulnerabilities and that's kind of where Champions team comes in. Yeah speaking abuzz SCA, So if I composition analysis, I think these days, I just want to highlight, like we all use many software that are open source or are free to download, and it's not just in terms of libraries or Frameworks, right? Sometimes also the container images, your VM images, and things like that. There are so many things that people have built.
I'm not saying that open source is not secure, but they are always points where maybe some kind of hackers include some kind of malicious software inside those open source tools. And hence, having this SCA is actually very important. And I think I I heard maybe last time that people called it, the software that you write in an organization, maybe even like more than a half of it is actually coming from these open source under the party libraries, right?
So that is actually the potential risks that you are. Assuming if you use a lot of Open Source, software tools, these are a lot of attack surface. And speaking about maturity, you mentioned just now. When we talk about maturity it's always coming to this maturity model. Is there something like maturity model for implementing security program within an Action. Yeah, there are beasts M and Sam are the two that probably come
to mind for most people. And they're two different ways of looking at a maturity model and be Sim building Security in maturity model, is what be some stands for is looking at other organizations and doing basically an assessment of that organization and saying? Well, here's where this organization is from the maturity standpoint and you as your organization can then look at that and say well where are we at? It's essentially measuring yourself. I'm up against your peers and
understanding. Okay, what are the other organizations of my size in my industry? What is the one or two? Three things that they that everybody in this category is doing? Am I doing those things, right? And so that's a good way of looking at, okay. Are we doing things that our peers are doing with owasp Sam? That's more of classic maturity
model, where? Okay, here's the level that you're starting at and here are the things you need to do to get the One and then here's the things you need to do to get the level 2 and so forth. And the goal there is to really look at those steps in the maturity model and having targets for where you want to be. You may not have to be at the highest level of maturity.
Again going back to understanding what your organization does if you're not processing credit cards, if you're not holding client sensitive data and into your not a critical app, you don't need to be at the highest level. Maybe level one level two is just fine. But what that does is it allows you to look at That if we want to get the level to hear the things we need to do, you can build out a roadmap that says, here are the steps were going to
take to get to that level. And here's a timeline that we're going to go to be there. Personally, I have the Derek maturity model so it's a little different. I think be Sim is more valuable to me than Sam. And the reason is I want to know what are the other organizations doing are we in line with that? But sometimes just having conversations with your peers is just as relevant.
I've had conversations with peers and just trying to see what they're doing, compared to what I am doing and we'll kind of exchange notes and you get that sense of like, hey okay we're doing mostly well but at the same time, we had the same challenges trying to figure out how we deal with the vulnerabilities that we detect and so forth.
And just having conversations with your peers is just as helpful I think I like the direction of maturity model so you just even speaking in conferences or in networking or even within PS, right? I think you can also maybe find insights of what kind of security practices you should include. And speaking about building this program, obviously we need people, right? But like I mentioned in the beginning, sometimes the mindset is that we always assume security is somebody else's
problem. In this case, it's like application security team in your experience. How should people go about hiring this application? Security team and what's the ratio size? And from my experience as well, hiring a good security Engineers are really really tough, and it's not just that they are highly in demand, but the supply is also not that many So what would you go about building the security teams? How do we find good security engineers?
And yeah, how do we scale this with an organization? I think the first thing to realize is you're never going to scale to what you need. Don't even bother. It's not possible. I've had very large teams, I've had very small teams my team right now. I would say it's relatively large compared to what I've had in the past and anybody that follows Miriam has heard me on other conversations, I'll say it again. Like I could double the size of my team and it probably still
wouldn't be sufficient. And a lot of it is because application security is very different than Security operation centers. Very different than network security and so forth. The way I always describe it is that application security teams are the sidecar to engineering. We are the ones that have to be part of that development process, to ensure that security is integrated.
Now, that doesn't mean it has to be an individual and if it is an individual doesn't have to be an application security individual, which is why things like champions. G for security education. Programs are very helpful in the sense that you're helping to drive security education across the engineering organization. But you are tasked with building an application security team, it comes down to asking the question. What do we want to do? Do we want to just be a team of penetration testers?
Do we want to just be a team of Engineers that are working with the developers in engineering and helping? Them to create secure code, do we just want to integrate tools and not do anything other than create integrate tools? Find, vulnerabilities, and tell some a go fix them. So it really comes down to understanding what is your organization going to tolerate and what are the actual needs
for the team? So every organization is going to have a different kind of view on that and it really comes down to understanding. What is the budget, tolerance? What is the need from an organization perspective? And what is the road map for the And security team is it again just developing integrating tools and finding
vulnerabilities. Do we want to get more proactive in terms of blue, teaming and purple, teaming and red, teaming to determine discover those vulnerabilities or are we just going to stick to architecture and design?
So there's a lot of different ways of tackling that but again, I go back to my first comment is that being able to hire the quote unquote, right size in terms of individuals that you're not going to do it. And I don't recall the numbers off the top of my head, but I know be simple. Had some numbers around what is the right size but again, it varies it could be for every engineer. You have or for every 100 Engineers, you have one knapsack person for every 50, you have one.
It really depends on the organization but when it comes down to hiring, one of the things that I typically try to look for is somebody that has some type of development background because if you can speak the language with the development team, then, you know, you're already at a disadvantage, not that you can be an application security because obviously, We have plenty of people that didn't come out of development that are in application security but it's
certainly helpful to have those individuals on your team to be able to really translate these vulnerabilities that come out of these tools and penetration testing and go back to the development team and say, looking at your code, here's exactly what the problem is. And here's exactly how you can resolve it. I think that goes a long way, not just in making the organization more secure and making the application more secure.
But also building that relationship between development, I meant team and the application security team where we both understand each other. Therefore, we're on somewhat Common Ground there. So I do, typically look for people that have either come out of the development space or have some type of development background. I would say that I agree with your opinion as well, that we should hire a security engineer with some development background.
What I find in the industry. Typically is, there are so many security so-called experts, but they are mainly specialize in tools. Like, I'm a specialist of these tools. I know how to implement these two. And use it, but not necessarily going back into the development lifecycle and even advising developers. Okay, you should not do this or even looking at the code, right? How things should be prevented
in the first place? So I think you're having this kind of knowledge of development, background will be first of all like you mentioned, right? Build a good relationship. But obviously if we can prevent security issues in the earlier, phase again, coming back to the shift left. I think that makes a lot more impact. So speaking about doing this security program, building some kind of roadmap understanding, what do we want out of? This security team.
And if we have established, this security team, what could be a good indicator of success? What are the measurement of success? How should you evaluate? Is it just by number of findings? Or is it just number of security breaches incidents? Or is there any other measurement that you advise people to look at for measuring the success? Yeah, I think there's two main ones that I would focus on one is for the downward trend on vulnerabilities.
Not upward again, we have no problem, finding vulnerabilities we can Find them all day every day, but it's really, are we moving the needle on reducing that backlog that to me is better indicator of a security program where we're ducing that backlog, not adding to it. And to be honest there's been times where we've had scans done or tests done and there weren't any vulnerabilities that were found and all of us that work in the security space here like that I call BS on that.
That's why there's no way and you kind of second guess yourself. I swear, it's like, wait, that can't be right. You know, there's got to be something. And after seeing several of those I'm starting to come around to the idea is like, well, hey maybe the program is working, you know, maybe we're actually stopping these things from going out and that's a good thing. But like I said, all of us in the security space immediately when you see a scan, the comes
back with no results. You're like, wait a minute, that can't be right. But yeah, I think it's always. You can validate that know. This is right. I think that's a good indication as well as that the program is working, right? We're not finding things as much. We're not adding to the backlog. Reducing it. I think the other thing too is something I'll steal from the operational spaces. You know? Meantime to remediation how quickly are we resolved in those vulnerabilities.
Do we have vulnerabilities that are sitting out there for weeks months maybe even years? If that's the case, that's the problem and there's a couple things with that especially ones that are very long. Lasting vulnerabilities, past several months or even a year or more.
If they ask question, is this even still a valid issue of something that's been out there that long that there's something not Right there, but I think looking at the amount of time that it takes to actually remediate a vulnerability is also critical indicator of how successful the program is.
Because again, we can find vulnerabilities all day but if critical vulnerability is found and we're able to remediate that within a few hours or a day or two or something like that, it's very strong indicator that your program is humming along the way. It should. Yeah. Speaking about remediation, I think the ultimate thing will be the zero day vulnerabilities, right? Whenever it's found. And how long does it take for The organization to actually
take an action. May be in your opinion, you are in the security space a lot more. How should people build this kind of zeroed a capability? Yeah, I think that comes down to that mean time to remediation, right? I'll go back to the sca example, the software composition, we can develop software and you can have zero vulnerabilities when that the software goes out into production. The next day, some component that we pulled in from a repository could be vulnerable.
Whether it's a zero day or whether Saint identified public vulnerability. Either way, it's vulnerable, right? And you did everything right time will result in vulnerabilities being found. And so, it really comes down to how your process is in place to take those vulnerabilities that have been discovered in a production environment and get a remediation out the door.
And in short period of time, that goes back to that mean, time to remediation, where if we find an issue in production and we're able to get a remediation push to production in a very short period of time, that could be hours, that could be He's could be week or so. Then great that means that your programs is again doing very well, something that we didn't really touch on and it's not because I was ignoring it, but runtime protection, there are tools out there whether it's
laughs web application firewall or runtime application security protection. Those also go a long way and being able to provide some cover for a period of time until you can get that remediation out the door.
So there's a lot of levers that we can kind of pull from a security perspective to ensure that we are Are providing that protection against especially things like zero days, where something like runtime protection does come into play because it allows you to do virtual patching, that allows you to potentially stop any malicious activity. Until you get code out the door, thanks for the plug for the runtime, the Woof, and all these things.
So I think that sometimes can be very useful, especially if you are being attacked as well DDOS. For example, when suddenly somebody from the internet, just Target your system. So having this kind of run time, protection definitely is very Spoil. If you don't have it, please Implement that as soon as possible. So direct has been a great conversation. Learning about security is very exciting as well.
Unfortunately, we reach the end of our conversation but I have one last question that I normally ask for all my guests which I call the tree technical leadership, wisdom. So think of it just like an advice that you want to give to the listeners here. Maybe if you can share us your version of three. Technical leadership wisdom here I think one is stay curious. One thing with technology is that it's always changing, right? And the prime example, everyone's on the A I trained
right now where it's everywhere. It's inescapable and everyone's trying to figure out what to do with it and it's just a prime example of how things change. And I think there's a lot of people trying to figure out, is this a danger or is this going to be helpful? I think there's pluses minuses. There's two sides that it's just again. It's an example of where technology is always changing.
One of the things with my application Security in general or more specifically, is that we have to stay up to speed with what developments doing. You know, the things that we were doing five years ago, or vastly different than what Doing today. And so you have to be able to stay curious. Stay engaged and be able to know where the new technology is heading.
I think the other thing is be a mentor if you can or be able to help others again especially in this space with security Henry mentioned earlier about how there's a lot of openings in security and we're having trouble filling them and I think
we need help in this space. We definitely need people that want to get into security and I think being able to to help Mentor people and be able to bring them into this space is going to help all of us. So find somebody that might be interested in security and try to help them along the way. I guess. The last point I would make is I know, we were kind of sorted on the same thing with in terms of hiring and Staffing but certifications aren't always the
answer. I know that I could probably sit down and probably take the certification test and pass it today without studying on many of these. That doesn't mean that I've achieved anything, right? I'm not saying certifications. Long or anything like that because there's definitely value and certifications. I know a lot of organizations look, specifically for certifications to make a hiring decision.
But what I've often found is that I like studying for certifications whether I take the exam or not because I had to learn from that. I think especially in this space, we see a lot of people that just want to get into security and the first question is, which certification should I take? And it's like well you don't necessarily have to get a certification in order to get into space. I mean you need to know
something, right? So So start dabbling start getting involved when you're looking at application security, specifically start understanding how software is developed. Start understanding about cicp pipelines and integrating tools and how code gets delivered and deployed and maintained.
If you're looking into getting into other aspects of security, you know, start understanding those different corners and really, really understand it, not just understand enough to pass an exam, so that's my advice, right? Thank you for including The certifications. Yeah, I think now that you mention it, I'm very aware that a lot of people in the security space ones to collect so-called
certifications right there. So many security organizations and things like that and people tend to chase these certifications or but it like you mentioned, right? It's always about the practicality. It's not just the knowledge only, you can accumulate all this knowledge but the practicality I think, is the most important. Like, how do you actually deal with security, vulnerabilities, or even prevent it from the
development life cycle? So directly, people enjoy this composition, they would want to learn from you. Maybe the directs maturity model, right? Is there a place where they can find you online here on, try to stay pretty active on LinkedIn? Like I said, I'd stay pretty busy but I try to get on LinkedIn and post and things like that and I've been creating some content that I've been releasing. Anybody that's been following me
on LinkedIn will see that. But yeah, the best way to get ahold of me as on LinkedIn. I've seen some of your YouTube videos. I think that's really cool and fun. So yeah, maybe people should check those out as well. So thank you again Derek for this opportunity. I'll really Learn a lot from security the conversation today and I hope people do as well. So thank you for that. Thank you. Thank you for listening to this episode and for staying, right until the end if you highly enjoyed it.
I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you are new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot in order to
grow this podcast better. You can also find the full show notes of this conversation on the episode page at technology, not death website, including the full transcript and Arresting courts and links to the resources mention from the conversation. And lastly make sure to subscribe to the show's mailing list on tackling Journal dot f to get notified for any future episodes. Stay tuned for the next package you know, episode.
And until then goodbye. Arresting courts and links to the resources mention from the conversation. And lastly make sure to subscribe to the show's mailing list on tackling Journal dot f to get notified for any future episodes. Stay tuned for the next package you know, episode. And until then goodbye.