Ep. 1 – Secure by Design: Building Safe Applications

    Secure by Design – Episode Transcript

Welcome to Logically Speaking, where we discuss the latest trends and challenges in cybersecurity with the top experts in their field. You’re going to learn how to keep your data safe, your operations sound, and your business ready for whatever comes next.
This is Logically Speaking.

Today we’re speaking with Ben Denkers of Quiet AI. And Ben, thank you so much for spending some time with us today. Wanted to just start out by asking if you wouldn’t mind sharing your role and your experience in cybersecurity.
Yeah, absolutely.

Steve, I appreciate the opportunity.It was great to catch up.
As Steve mentioned, my name is Ben Denkers. I’m the Chief Services Officer here at Quiet AI. My background has been in security consulting for the last 20 years with an emphasis on application security, incident response, and overall risk management. I have had the pleasure of working in all industries, finance, manufacturing, healthcare, helping organizations not only identify vulnerabilities and potential risks, but helping them mature their security and application programs. So it’s great to be here, Steve.

Why don’t we start out just by starting with why is it that you specifically wanted to work in DevSecOps, a rather unique niche part of cybersecurity, and wondering why wasn’t that attracted you to DevSecOps? For me, maybe it’s a glutton for punishment, I suppose. But realistically speaking, I think the more appropriate answer is if you take a look at applications in risk in general, where fundamentally they begin is within coding. So you can have vulnerabilities without an application, and you can have an application without doing development of said application. And so for me, figuring out where I can have the most impact on change, DevSecOps is a great example of where I would want to start. As somebody who’s interested in APPSEC security, they want to have the most positive impact as it relates to security or maturity of an organization. And you mentioned vulnerabilities in the application arena.

What are some of the greatest weaknesses that you see today that companies are struggling with addressing or identifying? What are some of those weakest areas in that arena?  Yeah, I mean, that’s a very long list, but I’ll give you some ideas. I think for some of the top of mind that are, I should say, some of those weaknesses that come or at the top of mind include things like lack of security awareness and training. You have developers and other stakeholders that may not be well-versed in secure coding standards and the latest threats. Obviously, if you’re not, then this can lead to security vulnerabilities being inadvertently introduced in applications. So you’re writing code, you’re not sure how to most effectively write code in a secure manner and that results down the line into vulnerabilities and potential compromises. I think also a lot of organizations have inadequate security policies and processes. This can be clearly defined security programs or APSEC programs. These are all examples of areas of weakness that a lot of organizations have, especially if they’re doing active development. I think if you take a look at the security testing of the applications within the environment as well, oftentimes organizations aren’t doing enough primarily due to resource constraints, but relying solely on manual testing and not conducting security testing at all obviously results in vulnerabilities going undetected, putting applications at risk as well.

If we move into kind of the more generic security controls, we often find that a lot of organizations have controls that are in place that aren’t properly configured. Misconfiguration of those controls such as your typical firewalls, access controls, even encryption settings often leave application vulnerable to attack as well. In development or DevSecOps, a lot of times developers are relying on third-party components and we find all the time that many applications that rely on those third-party libraries or components often introduce vulnerabilities that the organization isn’t even aware of. They’re leveraging something as part of their code base that is obviously potentially vulnerable as well, yet they don’t have the ability or skill set to identify prior to being introduced into the application. Other areas that I could talk about are things like legacy systems, outdated technology, and just more standard process. Think about how instant response within an app sec environment might play into effect. So an application gets compromised, do the organizations have those instant response plans in place in order to properly identify or be able to respond to those instances? How quickly can that code be changed? Oftentimes that’s not a trivial thing.

You have applications that have complex APIs and those APIs introduce risk.
And then lastly, one of the biggest challenges that we see is just culture in general. So think about it like organizational culture, a culture that does not prioritize security or really foster collaboration between not only the development or engineering teams, but the security teams often hinder the effectiveness that that organization, that organization’s application security or DevSecOps program, how effective it is from a general perspective. Yeah, I wanted to just interject something because in my experience, I find that developers typically want to provide an end user experience that’s easy to use, the user interface is accessible, but security isn’t always front of mind. Do you find that as a challenge as well? And how do you suggest that people address that during the secure lifecycle development of an application?

Well, I think sometimes you have competing priorities or the perception of competing priorities, but at the end of the day, when you realize and you have this collaborate, you have this environment of collaboration between security, between product and between the business needs, I think if you have that open form and are discussing what do the developers need in order to do their job the best that they can, what does security need, and how do we apply the resources to ensure complete coverage that everybody gets what they want? I think that’s really the best answer. And as easy as that, putting that into practice obviously can be more difficult, but ultimately it’s about recognizing what the business needs are and then adjusting priorities based on that.

Yeah, I appreciate you mentioning that.
I want our listeners to know because I’d love for you to explain kind of this concept of DevSecOps and how it differs from the more traditional DevOps practices, right? Because I think it’s an evolution, but I want to get your kind of your opinion on how you would explain that concept between DevSecOps and traditional DevOps. Yeah, for sure. I mean, DevSecOps is really the integration of security practices into the DevOps process, right? It’s aiming to kind of make security an integral part of that software development and deployment lifecycle. So, traditional DevOps focus on collaboration between development and operation teams, whereas DevSecOps brings security into the mix. Really the point of that is to enable kind of this continuous concept of security throughout the development process.

That’s great. Thanks.
I want to do a little shift because I know that your company, Quiet AI, is very much focused on the integration of artificial intelligence. So can you talk a little bit about the role that AI plays in that integration of security practices along with kind of AppSecDevSecOps lifecycle? Yeah, absolutely. So for us, AI is the future, right? It’s not even like there’s no question, which is why we’ve developed as part of our product models that allow us to enhance security by finding what we would like to call pre-zero vulnerabilities, right?

So the idea is if we’re so early in the development process in terms of being able to analyze code and to identify vulnerabilities, that we want to identify those vulnerabilities before they even become zero days, let alone anything else. And one of the ways that we do that is leveraging advanced AI models that allow us to not only be more effective, but scalable, especially with organizations that have thousands of applications, large code bases, et cetera. So this is just something that came up. Is that then becoming even more predictive than what your traditional kind of signature-based systems are able to detect? Are you anticipating those? It’s night and day different, right? So from our perspective, the efficiency that the models are getting in terms of not only vulnerability identification, but just the reduction in false positives is absolutely fantastic. And so think about if you’re doing a manual code review as an example, all of the opportunities that the human element or human error could potentially introduce. And so while you have to have a person reviewing code in this particular example, if you’re reviewing a million lines of code, that’s not going to be very efficient.

It’s going to take a long time. But if you can train models and have applications that do the heavy lifting for you, imagine the amount of coverage that you’re going to be able to have. And then you have the reliability of the AI model to identify those vulnerabilities. It’s really the way of the future, in my opinion. And you talk a little bit about that a little bit further. How are AI-powered tools enhancing that security? You mentioned it, can you give a couple of examples of maybe beta testers, customers of yours that are actually utilizing that to enhance their security?

Yeah, so today we have AI built into the product as it is. And so anyone who’s leveraging the product has that capability. Quiet AI specifically evaluates code during the development process. So we want to make it easier to address potential issues, find vulnerabilities very early on in that development process. So we integrate within the CIDI pipeline, analyze essentially large code bases, not only quickly but accurately, leveraging AI as part of that process to ensure security is built in from a continuous perspective. And then we also highlight what vulnerabilities are reachable. And I think that’s primarily one of the coolest things that we offer other than the AI is you have a lot of, you might have a lot of vulnerabilities or issues that you might identify as part of kind of static code analysis. But not everything is necessarily exploitable or reachable within the application. And so we kind of take it a step further and say, hey, we’ve identified all of these thousands of vulnerabilities that you need to address, but then we help prioritize leveraging obviously AI and then the concept of reachability to have a tailored focus view on what an organization needs to do to fix from a prioritization perspective. You brought up an interesting topic and I want to kind of shift the conversation into the maturation of the security application program.

If you could share, so our listeners can learn what make up the key components of a mature application security program, how do they work together to maintain that robust security?

Yeah, I mean, there’s a lot, right? But I would say the key components include things like a well-defined security policy. You have threat modeling, secure coding practices. Obviously security testing plays a role. Just monitoring, you have all of the kind of ancillary services as well, like things like instant response and ongoing training. To me, these components work together to really create a comprehensive and proactive approach to not only application security, but DevSecOps in general. And with the ultimate goal of obviously reducing vulnerabilities and risk and help if the organization happens to be compromised by a vulnerability, then you have a clear set of processes or in place like from an instant response perspective to quickly identify and then mediate.

That’s fantastic. And how does Quiet AI help organizations kind of assess their maturity? Let’s say they have an existing application security program.
How can you walk in and assess that and help them mature that?

Yeah, absolutely.
So part of our consulting practice is really around helping organizations evolve or mature their application security or DevSecOps programs or practices. And we do that by really leveraging NIST and OWASP frameworks to evaluate how effective what they’re doing today is and if there are gaps that might exist as it relates to things like best practices. Really we’re looking at processes in place, technology, what training is happening. And then kind of like the collaboration between security and engineering to help steer or build a roadmap for those organizations to say, OK, these are the types of things that you need to do in order to have a more effective and more mature program. And here’s either the resources or technologies that you can implement to kind of solve some of those systemic issues. Yeah, that’s a great point. Can you discuss a little bit more about how a company could take advantage of various types of consulting services if they’re looking to improve or build an actual application security program?

I mean, so so app second DevSecOps is full of opportunities, right? I mean, most organizations, you know, they have minimal skill sets, but really the biggest challenge is just resources. And so, you know, consulting opportunities include things like security assessments, gap analysis, policy development, risk assessments, pen testing, threat modeling. I mean, the list is really goes on and on and on. But the goal here is really to not only, you know, help assess where an organization is and kind of that maturity, you know, of the program, but also potentially help them assess the technical aspects of maybe their applications, their environment, their users, to really identify, first of all, do they have the proper security controls in place? And second, how effective are those security controls in protecting against various types of risks and threats, et cetera?

No, that’s great.
I appreciate you sharing it. In your opinion, Ben, why should an organization invest in AppSec or DevSecOps and maybe even talk about kind of the barriers of entry? Why wouldn’t they? So first, why should they and then why wouldn’t they? Well, I would say the first thing, and this again, long list, but you have it’s really to protect since sensitive data, right? I mean, you know, applications often handle sensitive data such as PII, maybe financial transactions, you know, or even IP. Investing in AppSec and DevSecOps helps really protect this data from obviously unauthorized access, potential breaches, ensuring, you know, maybe even ensuring compliance with data protection regulations and really ultimately maintaining customer trust, right? But if you want to talk about a little further than that, right, you have things like mitigating security risks, right? You have improving deployment efficiency, you know, so by integrating security practices within the deployment process, DevSecOps specifically can help kind of identify and resolve some of those issues earlier. So for investing in security and DevSecOps is identifying vulnerabilities and threats prior to, say, an application going live, well, the downstream effects of that are just multiplied, right, because now you’re identifying vulnerabilities before it even reaches a production stage and therefore the users aren’t impacted, the data is impacted and your risk of compromise is significantly obviously goes down as well. And so, you know, ultimately, like, if you’re going to build it, build it right and introducing security as early as possible in any program or process, just overall helps ensure that DevSecOps customers can trust what you’re doing, so on and so forth.

I want to pivot a little bit on and talk a little bit about data privacy rights. And you’re aware, lots of states are coming out with regulations about data privacy. How does application security address the data privacy rights or things like GDPR in your opinion? Yeah, so, I mean, obviously, application security really or really app sec programs in general should ensure that the sense of data such as PI is, you know, like encrypted both in transit and, you know, at rest and you have those kind of basic blocking and tackling. But you also have application security that controls things like access control, right? And so those applications making sure that, you know, when proper access control or making sure that I should say access control is properly implemented also helps ensure that only obviously authorized individuals can access or modify data.

You know, these are all types of things that help ensure the safety and integrity of the data itself, right? So secure storage, you’ve got obviously privacy by design where you might be incorporating privacy considerations, whether they are regulatory or not, into the application process from the beginning, right? And so again, if we take a look at where, you know, if you want to have the most effective app sec or DevSecOps program, and in this case, privacy by design, doing that from the beginning really helps establish, you know, what needs to be done when and where, right? And so it really helps allow if you if you want to follow the concept of privacy by design to do it from the beginning because it gets so much harder if you’re trying to bolt it on later.

And I would also say like data minimization is also another big deal, right? So as it relates to privacy, being able to ensure that the application in question, right, is only collecting minimal data, it’s only retaining minimal data, and you’re not, you know, introducing additional risk by collecting too much and storing it in proper mechanisms, I should say. You know, I was thinking about and interested in your thoughts about application development in cloud infrastructures and or, you know, infrastructure as a service, does that introduce any inherent vulnerabilities or security concerns if it’s done in the cloud versus on-prem? Do you see a difference in that at all? So I mean, anytime you’re talking about the cloud, you have your own set of security concerns as well, right? So there’s certainly going to be additional things that organizations need to look at in order to, you know, maintain a secure environment. And so that could be things like how are developers accessing that particular environment? Do you have things like defense and depth strategy or using two-fact authentication, you know, principle of least privilege, right, into those environments? But now think about, you know, from a cloud perspective, you have generally a larger attack service you have to worry about and, you know, more accessibility, which makes the efficiency go up, but potentially also, right, if that environment were to be compromised, it has its own set of unique, what I would call unique issues that organizations have to be prepared to deal with.

Yeah, I want to ask you about zero-day attacks. I read a report recently that found like 83% of all applications that were tested by this one provider over 85,000 had at least one security flaw. And this one provider found over 10 million flaws in the 85,000 that they tested. There’s tons of gaps in application security, which I, that’s why you’re in the space. But how would a company, or how would you suggest a company identify zero-day? Is there a way to prevent that zero-day attack that’s not, you know, that exploit that is not quite, you know, in the wild yet?

Yeah, I mean, for us, we, like I said, I think I mentioned at the beginning, you know, we kind of coined this concept of pre-zero, which is a little bit cheeky. But the idea here is, is like leveraging quiet AI as part of a, you know, part of your application or DevSecOps process ultimately allows us to identify vulnerabilities before they become vulnerabilities, right?

And essentially before they become a zero-day, you know, that an attacker might have identified and is now leveraging to compromise, you know, that particular application. But, you know, outside of that, more generically speaking, you know, preventing zero-day attacks can obviously be challenging due to the nature, you know, of that most organizations don’t have the proper SDLC processes in place. They don’t have mature DevSecOps processes in place. So a lot of these get missed during the development cycle, right? And so my recommendation is, is that if you, if you focus your efforts during that, you know, as far left as possible during the development phase, you’re able to identify potential issues before they become, you know, large headaches. And so if you can do that in pre-production, well, guess what?

You’ve just now potentially saved your organization within an application, right, of having a vulnerability that could potentially be exploited or compromised. And so for me, like the focus really needs to be in DevSecOps or, you know, the SDLC process in terms of identifying and helping prevent that.

That’s a great point.
All right – I’ve got two more for you.
What are the top three challenges in AppSec that you would say would help our listeners if they had to prioritize? Because as you said, there’s a plethora of challenges that are out there. And if there are just three that in this space for application security, if they addressed, they would be better off than most.

So I would say like my number one would be integrating security into the development lifecycle, right? Because I think that if organizations do that properly, then a lot of the downstream effects of application vulnerabilities goes away, right? Because if we can identify it before it becomes production and we can identify it in code and we’re doing things based upon a set of best practices, it inherently helps ensure that the application is more secure. And so, you know, making sure that those security practices are seamlessly integrated into the SDLC process is obviously challenging. But to me, it’s one of the most important things that an organization has to get right. I would say the second thing, and you kind of touched on it right at the beginning was is balancing speed and security. And so, you know, I think there’s the concept of managing the business requirements, but I think also DevSecOps needs to kind of deliver secure applications at a rapid pace, just in order to make sure that, you know, the organization is meeting those business requirements. But the challenge is like, what is that right balance, right? Between speed and security. And that is often something difficult that organizations struggle with. But if you can, you know, if organizations, you know, really they should ensure that security measures do not slow down the development process. And that’s why like QuietAI and building into the kind of that CIDI pipeline and doing it continuously helps make sure that its, you know, applications can get reviewed and pushed to code or pushed to production much more quickly. But obviously that would be probably one of the second things that I would highlight. And then third, I would say managing third party components. Applications often rely on kind of those third party libraries and components, which often times introduce security vulnerabilities, especially if they’re not being managed. And ensuring that all of those kind of third party components are vetted, securely configured and kept up to date is really essential for reducing kind of security breaches. Because, you know, developers like to save time, right? And then it goes back to the speed thing. And so often they’re using snippets of code or libraries that may already have vulnerabilities. And, you know, introducing that into their applications, obviously, it becomes problematic very quickly.

No, great point.
Thank you for sharing that.

Final question here.
If you have one kind of tagline for QuietAI, what would it be?

Oh, that’s funny. You know, we hushed the noise and amplified DevSecOps. That would be kind of my response. Our goal really at QuietAI is to, you know, kind of silence the noise and squire, but amplify DevSec’s opportunity and ability to identify vulnerabilities quickly and to ultimately make the organization more secure.

Excellent. Ben, thank you very much for taking the time to kind of educate our listeners, but also sharing just your insights and your experience. And I want to just thank you for taking the time to be with us. Well, that’s all for this episode. Make sure you tune in next time to Logically Speaking and Stay Cyber First and Future Ready.