Product security has greatly changed over time. How do humans contribute to the changes going on? In this episode, Joern Freydank, a Lead Cyber (Application) Security Engineer, dissects the human issues in product security. He emphasizes the value of humans in providing a higher level of order intelligence operating the systems. Joern also shares the key component of the antipatterns and discusses how threat modeling works in the modern era. There is so much to unpack in today’s episode. Tune in now!
—
Listen to the podcast here
Dissecting The Human Issues In Product Security With Joern Freydank
Our amazing guest is Joern Freydank. Joern, it is a pleasure to meet you. Good to see you. How are you doing?
I’m good, thank you.
I have the pleasure and opportunity to dig into your background and to look at your history. I rarely get a guest on a show I’m hosting that has been around application security as long as I have. I’m sure we know a lot of the same people. I’m positive that we have historical experiences dating back to DEFCON and Black Hats in the early 2000s together.
Let’s start with a little bit of background on yourself. My understanding is you are a Principal Product Security Engineer with many years of experience working at Splunk, and you are securing the company’s products and services. Without diving too far into Splunk, we don’t want to spend too much time there, talk to me a little bit about the high level of what you do day-to-day, what you enjoy doing day-to-day, and a little bit of your historical experience in application security.
Thanks for having me on the show. I’m at Splunk. I secure Splunk’s product itself. My day consists of doing assessments, looking through what the developers do and shouldn’t do, going from threat modeling to the very left side of the SDLC, all the way down to when they implement it, and then going even further into the setup and the product.
Usually, we start at the business side following the business behavior, all the down. I’m talking about all groups of people working on this and digging down into the code, starting from a business need. The business function is implemented somewhere in the cloud, most likely, sometimes on-prem, and looking at that setup too so that nothing can happen. My role is more like the military police for the military because Splunk is securing everybody else’s data and systems. If that gets breached, it would be a very bad thing.
That particular product and company line is used all over the world. That would be an extremely bad thing, and we thank you very much for spending the time to secure those product lines. I have been around application security as long as you have. We have come up over time through the ranks together, and we have seen a lot of change.
Let’s start a little bit with how modern cloud infrastructure and modern infrastructure changes affect how application security is done. Has it changed things? There was a transitional period for DevSecOps where that became the hot thing. There then was a transitional period where everybody was focused on CI/CD security and pipeline security. Has cloud infrastructure and cloud-native applications changed how we tackle application security, and if so, in what way?
It has changed a lot, and that is because they have different levels of people now dealing with the business logic, and you have to secure that business logic. What I’m seeing is that I like to point out patterns, one of those is the inversion of roles. In cloud security, you have at least 2 or 3 layers when you are dealing with a cloud security set.
That role would be the highest in the company, and usually, can touch any end-user data and refund money. In the middleware role, where the admins are, some of them have CI/CD access, so that’s in the middle, and then lower is the cloud infrastructure. You have another set of admins. The admins are not supposed to see all the transactions, and the CI/CD folks are not supposed to see them either. They run it.
Between that, there’s a lot of opportunity for something bad to happen. That’s what changed because the typical thing you said was the build master role. That’s not one build master anymore. Several years ago I was the build master. Nowadays, it’s hundreds of platform engineers touching systems and building systems that run on convention based on somebody checking in code and that CI/CD pipeline code. Something gets transformed, and then it runs in the background.
Back years ago, it was a single developer who relied on a single infrastructure engineer or network engineer, maybe even a host layer engineer to build the operating system, and then they deployed this stuff. It still sounds like it’s human-dependent in the sense that we are relying on cloud engineers to build the cloud infrastructure. We are relying on pipeline engineers to build the pipeline and maintain and operate the pipeline, and we still have to have operational individuals at the code development layer to write the code.
At the end of the day, there are humans involved throughout that process. Do you see that changing over time with Generative AI or code basic automated, no-code, low-code approaches, or infrastructure as code approaches so that we can get more and more automated or do we need these human beings at these levels to provide higher level order intelligence on how we operate on a day-to-day basis?
There are two parts to this. The one part is the efficiency. Somebody else like the engineers builds something for their clients, which are other developers and engineers. They make it so that it’s easy to use by bringing up or setting up a system configuration. Something that runs in the pipeline and the developers have access to pipeline checking that runs pretty much autonomously based on certain rules, but that means that the human aspect of the check is not there anymore.
I call it behavioral pivot. You have instructions that are checked in or they are sitting in a file system and the developers implement those instructions. They might not even know that those are instructions. That’s one of those dangers there. With that, there’s a behavioral pivot that somebody else executes.
It was not the same person anymore, not the same role. It’s picked up by the system automatically and then gets transformed. The second part is the AI part. I’m not too worried about it. It’s more like a threat because what we are constantly fighting in AppSec is Stack Overflow answers that somebody put in. The developers have a different goal. They want to get something running.
The secure folks want to make something run securely. If the developers go to Stack Overflow and lock and say, “How do I make this web service run?” then the answer might be, “I turn the security off,” and not get a correct certificate. I don’t know yet, but I’m assuming that ChatGPT or some bots will pick up potentially bad behavior too. If you look at Stack Overflow, those things will be listed first and then the correct answer will be further down.
You brought up an interesting point. I appreciate that line of thought about the collection of garbage in and garbage out by the AI system. That’s been a problem that we have been trying to tackle for years and years. As developers go to Stack Overflow, they garbage in themselves and garbage out back into their code. That’s something from an application and a product security perspective.
We have tried to do our best to get our arms around and to stop that from happening. At the end of the day, it’s a human problem. There’s a human issue within that. What I have found is that human issues can largely be sound, solved, or at least influenced heavily by incentives. Have you had any experience in working with your development teams and helping to incentivize developers who are not incentivized by a lack of security bugs? They are incentivized by KLOC, with thousands of lines of code created per day. What they want to do is to create amazing code fast. How do we fix the incentive structure or the incentive problem with developers? Is that something you have had to tackle in any of your former lives?
Human issues can largely be sound, solved, or at least influenced heavily by incentives.
Yes. There are two things. If you find at least one engaged developer, some of them make it to the AppSec team. There are some people like the developers who like to learn things. It’s incentivized by learning. It goes along with the Security Champions program. The thing to think about is that it should not be the place where somebody who doesn’t want to be in is getting pushed off to administer some bureaucratic overhead in the security area.
There needs to be an opportunity for the developers to learn something new and get into the details. Do you have those corporate incentive systems that we can give them some points and they can go buy some stuff? I have done that before where developers volunteer and tell me about other areas, or they go and find the security box and say, “We are not the only ones doing this.”
This is good info as feedback because, on the product security or AppSec side, you go and write a tool rule to look for more like this. That is the feedback that we want. We want to keep developing and be engaged in that conversation. Unfortunately, that’s a hard thing to do because this application security or product security is counter-opposed to developers sometimes because of the timeline. Each side has a timeline pressure so they go out of their way and do something that’s against the timeline, which is hard to do.
Let me double-click on the timeline commentary because that’s another thing that I often think about. A long time ago, development timelines were eighteen months. The Release of the Windows operating system was on an eighteen month schedule many years ago. Now, we are pushing eighteen times a day or more to some of these real-time production systems. That time difference has a massive impact. Can you describe how you see the time difference as an impact on application security? What does it impact when it comes to doing the day-to-day product security, code security, and application security?
First, you have to have a foundation. The whole build system has to be set up to be deployed with a push button. If you can’t deploy something in the spur of the moment, you have a problem. A lot of systems are getting redesigned because of that. If they can’t be fixed in a line of code or upgraded a library in a hurry, then that’s a real security flaw in itself. It’s a real threat to not be able to do that. If you don’t have that in the CI/CD pipeline, then it becomes a hassle to put a security fix in a certain timeline. If it’s in there already, the mitigation, you will fix it with the next most opportune time spot. It’s like a concurrent build. They then say, “Fix it,” and then you have a lay for fixed flaws and they get pushed out later on.
The problem with that is the rollback is also the problem. There’s always the testing period. You want to have time to test too. It’s in the way of the immediate deployment, too, because if something breaks or something down in a catastrophic sense, that could be the security patch that does that. If you have certificates, for instance, they break down whole organizations. If you have a certificate that can be validated and they push it out in this for a moment without testing, we can roll it back.
Speaking of anti-pattern, that’s the typical thing. You can’t roll back, even though you have the cadence of deploying something right away. If somebody revokes the certificates and puts a new one in that’s not signed properly, you can’t roll that back, and then the development team gives them to Stack. You have to think about this even though you have the time. It might be building in time, deploying on the spur of the moment like on a push button. Certain things can’t be redone.
You keep using the term anti-pattern. I find it to be a wonderful term. We use anti-patterns a lot of times in investing. We use anti-patterns in contrarian decision-making processes that we do in business or engineering throughout the process or the day-to-day operations of business. Can you help me understand some of the key anti-patterns? You have mentioned a couple of them. There are a couple more. Maybe we have hit the key 1 or 2, but it sounds like you like to focus on those anti-patterns. Can you help me understand any additional ones that are jumping up?
Before I do that, let me get your background on this. I came across it when I started object-oriented programming for the first time in a book called AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. That’s from 1989. Part of it’s still new. Later on, when I was working with the development teams, they were asking the same questions.
What I can point them in those patterns and point them to other teams, telling them what not to do and what’s missing. A part anti-pattern is part of what is missing. I like to collect those, take notes, and speak about them. They come in different levels. The first one is the inversion of behavior, like when the admins think their role is the highest.
The pattern there is the misconception that the role is the highest one that accompanies the admin. In the real world of security, the highest role is the business user who can deal with people and money because they make business decisions. The business system is implementing the business behavior and the admins utilizing that.
If you only focus on the computer itself, then the admins and the nodes are the highest. If you have a cloud-based setup, that’s the admin role. They might have multiple levels. It’s not the highest. That’s one of them. Another pattern that is very similar to what you described with the CSD engineers, and I don’t have a good name for that, is the deferred execution pattern or a pattern where you encounter instructions that are put somewhere like a CI/CD system and either code or configuration.
There’s a role shift that some other system picks up on a timer, drone drop, or by automation, and that runs in a different role set. The initial set we have created for that instruction set is a different set of people than the ones that execute that pattern. That comes across even more now. It’s like an engine concept. You have a command with an engine. People don’t see developers. They don’t see that abstraction layer because they don’t think in those terms. Our role as a security engineer, to point out, is that they have an engine that’s sending custom-built commands to a system, very similar to the defraud pattern.
The engine has another threat to it and that is you can run that remote somewhere else. For example, if you hook up a message system like Slack and then hook it into your internal system, that’s a typical engine because, in the message itself, it was only meant for information, not the command and the message. You have to think about that.
The other one is that the stripping of authorization authentication is a big one in that the authorization isn’t carried into the backend. That comes from when the shift occurred between the monolithic state full web source to the stateless web sources, and then the service implemented behavior in the back and the authorization part was almost always implied in the web server. That user who logs in can do almost everything on the web server.
When you have a web source or API layer, the authorization is divided into multiple different clusters or Kubernetes engines or the systems that run those APIs. Each API vertical is a different business. It might be a different business vertical. In that case, you have to carry the authorization into the backend. If that’s not done either explicitly or implicitly by having a dispatcher proxy set up in front of those API layers, you lose the capability of checking who initiated the interaction.
That’s interesting, this antipattern of product security and product development. The first one you mentioned, the true layers of security ownership hit home with me because, at the end of the day, if you leave off that top tier, the business decision tier, or the ability to understand and thoroughly make a decision that’s relevant to the business at that top authorization level, you can be making extremely poor decisions from the center level down or from that second layer down, which could result in an extremely secure product in a traditional computer science sense or a code level sense. That wrecks the business. At the end of the day, you have to understand risk versus security implementations. Without that top layer, you can’t understand risk. Is that one of the key components of that first antipattern?
You have to understand the risk versus security implementations. Without that top layer, you can’t understand risk.
That’s exactly that. If I talk to developers, sometimes I get feedback. They ask me, “Can you explain your application to me?” They start talking in a passive sense. “The application does this.” The first thing I try to identify is who’s using this system in an active sense. Developers think not from the way the business starts. They think in the middle of where the system starts. Working that out initially in this threat model session is a very important step. Who’s doing what to whom?
Let me double-click on that term. Modeling has been a term forever. Adam Shostack wrote some books on threat modeling several years ago that I have read. There are a lot of strong experts on threat modeling. Can you describe in your opinion, in modern times, the right way to implement threat modeling into the SDLC practice back in my day as the traditional old gray beard here?
Back in my day, you did it before designing the threat model, then we designed, and then we wrote code in this long waterfall process. You can’t create a threat model in that approach anymore. You have to somehow do some continuous threat modeling. How does threat modeling work at a fundamental level? For the readers’ understanding, you did threat modeling specifically at a large cyber insurance company before working with Splunk.
An insurance company, yes.
That’s fantastic. It’s a cool experience. Give us a little bit of understanding of how threat modeling works in the modern era.
I’m still doing this too. It’s part of the role because it’s required in the SDLC pipeline. There’s an ideal setup and then it’s a real-world setup. In the ideal world, development teams come to the application secure team or pro-secure team with an idea of what they want to implement. Based on the business use case, you take notes, and that’s what I’m doing. We take notes of who’s doing what and whom. Identify names and processes. I call it the name-dropping phase. That’s in the design phase, looking through what they are dealing with. You build a glossary and lay that out.
Developers or business people are pretty good with this because it’s at the top of their minds. They blur everything out in a few sentences. You have to be very fast writing everything down, and this is the manual approach. I put stuff in a diagram, so I have to think of something. They call it point and explain. The diagram might be scrapped later on. Eighty percent might be modified, but at least you can point to certain things.
It’s not with a data flow diagram. Certain elements mean something and then the implementation goes on in the development cycle. The design phase might find flaws or issues. Part of the flaws you find in the beginning are controls that are not implemented and bypasses because you have the god mode on the diagram. You can look at this high level and abstract things out. You can see some backplay that comes in.
The performance testing person mentioned that they have a performance testing server, for instance, why do they have an entranceway segue into the application? Those are the bypasses you can point out, for instance. If eventually it gets deployed at a pentest end, we are good for the first iteration.
Now we come to the iterative approach. Ideal case, you should have a baseline model in place, and then you go, look through, and see what has systematically changed that wasn’t there before. I’m not talking about building a service number B that does the same thing as service number A. You want to know if some web service or some component does something differently on a behavior level than what’s already in the diagram, and then you can expand the threat model like that.
In the real world, most of the time, we start with a second part already. The developers have something in place based on whatever their features are going and putting up a model that represents most of the system that’s already there and fixes certain things. The approach is pretty much the same, but the only drawdown is that if they find something that’s broken at the design level, that’s going to be harder to fix for developers.
If you find things at that lower level, you have pushed it further out in the life cycle, which means you have to double back, which is going to increase your workload. That’s the trade-off of the speed of the iterations that come from a modern development model.
It is. There’s another set. This is what I have described as the regular business use case implementation. There’s another set, and that is teams now rely on middleware platform services that the CI/CD and the platform engineers implement. There are cases where threat modeling where you have to zoom in on a different level and then see what that system looks like.
There’s always the discrepancy where the developers say, “I’m relying on the underlying cloud system or some controls to be secure.” You say, “There’s a conflict there. Who’s doing that first? Who implements the thing first? If you find something, is it the platform team or developers that use it first?” The ultimate responsibility will be on the business owner, but you can’t say that. Those are gaps that I usually see in modern implementation.
Let me put a little twist on it because I like that you went down this line of delineation between application security and some of the infrastructure security stuff there. You implied a demarcation point there, where it’s an ownership level. Talk to me a little bit about the rise of the term security engineer.
That term has been relatively new in the lexicon of application and product security in the last several years. It has become a hot term in the last few years with the rollout or continuous rapid adoption of cloud and cloud-native architectures. How does one become a security engineer? What is a security engineer from a human level? What are the differences between a security engineer and a traditional AppSec person in your eyes?
There are two different areas where security engineers or AppSec engineers focus on. The terms AppSec and security, there’s overlap depending on the company’s structure. From where I came from, I came from a development background and then implemented security. Because they implemented security, the term in my resume, that took off from there.
There’s another area that people come from, the admin area like the security admin and business admin folks. They get more and more into the admin programmatic level. The program has something on it. The developer level or an admin script level like the python middleware for instance, and running those CI/CD jobs. That’s the DevSecOps engineer. That’s that role.
In between, what they most share is the ability to write program code and inspect program code. That’s the key product security engineer. The term might be still used in other areas like administering security systems. That’s another area. It’s still used in that area, too, and then incident response. They also have an engineering title. In my previous company, they had a whole security platform engineering level. Those are the ones that built the infrastructure for the cloud to be secure.
I feel the concept of a product security person has been blown apart into a more focused version of oneself where you have infrastructure security people, code SEC people, and CI/CD pipeline build SEC people. That concept has caused specializations within application security as a broad terminology to take hold.
I’m going to spin it a little bit here again and talk about innovation and application security and innovation and product security as a whole. I struggle, and I am sincerely looking forward to your answer to this one because I want to learn from you on this one. Where do you see as a day-to-day person focused on executing and operating on this every single day to secure a highly used product that’s out there in the world every day?
Where do you see innovation occurring in vendors and tooling? You don’t have to name vendors, but what are the technology and technical concepts that are being done differently that have you excited about the future of application security, product security, threat modeling, and any of those subspecialties? Are you like me, and you are looking at it going, “We need some innovation?”
The threat monitoring space needs some innovation. I talked to a team, a startup that wants to use AI to help with threat monitoring, which is not the worst idea. It’s a pretty good idea. Innovation in the security space is in two areas. One of the more famous innovations would be to take on more threats. The biggest bang for the buck is to be more efficient when you do a security system because, at the end of the day, there’s a factor of 1 to 20 between developers and security engineers. You want to keep the workload of the application security engineer. You want to keep that too low. You want to have an 80/20 where 80% should be done by conventions and automation in a self-service mode and 20% should be done with some manual interventionists done by the security engineer.
We can’t do everything. That’s the problem. That helps a lot in that area. In terms of innovation, there’s another shift, and that is the whole cloud infrastructure. There’s a more behavioral shift towards gateways, like in the cloud. The typical SaaS desk and/or SaaS tools shift towards gateway functionality. That’s on-demand in real-time if you have more intelligent gateways that can pick something up.
I would say the shift is towards runtime, too. If the cloud infrastructure, Kubernetes containers are running, you can pick up certain things at runtime. That has a side effect because if it’s at runtime, you are getting real-time events, and that goes against the efficiency. What are you doing with this? You can’t process it in time. That all has to be worked out at some point. What to do? You can’t turn systems on. They spit out a lot of alerts.
I love that line of thought because I think that there are lots of different ways that we can innovate in application and product security nowadays. As you mentioned, everybody immediately goes about how we detect more stuff. I would argue that the vast majority of innovation in product and application security isn’t about detecting more stuff. It’s about integrating it into the day-to-day usage models of modern security engineering, modern threat modeling, and modern application development in a way that makes things smoother. That’s the efficiency comment you were talking about.
That’s a typical thing. That’s why we abstract in threat modeling. You don’t want to be flooded by little stuff that can be turned off. A typical example I always tell is to think about HTTPS and TLS in between nodes internally. If you create a threat model and name that or have to name this, then there’s something wrong. This is something you can have to CISO, somebody high up, write an email to everybody a standard, “Please turn HTTPs on,” and then we don’t have to do a threat model. If you take those issues in the threat model, we are acting on the wrong level. Those things can be mitigated by patterns like implementation templates, patterns of awareness, and saying, “This is the standard, and those things have to be that we solve this issue.”
We have never been in a position before as a security world, universe, or whatever you want to call the proverbial us. We have never been in a position before where everything was as code infrastructure automation and API accessible. It’s never been like this before. What’s driving change within the last few years is the ability to programmatically remove a lot of the day-to-day tactical security risks that get put into play.
If you can programmatically remove it with security tooling, filter it out, remove it fast, and fix the bugs quickly in an automated way, that allows our people, our humans to elevate to something higher order. We are not pushing our people out. We are giving our people the opportunity to not worry about the running of the engine fundamentally anymore but to be much smarter at a higher level.
It’s like robotics in the ’80s. The role shifts up to programming the robots. In the application security world, the creative step is the more work you do, you have to do the work on the creative level, use the feedback, and then implement that on the lower level.
I’m not going to take any of the bait and talk about AI and robots taking over the world. We are not going to discuss that on this show. I would love to open up the floor for you to talk about any topics that you think are interesting. Anything that you want to bring up and dive into? I do have some additional questions we can shoot for if you don’t have any topics. Do you have any interesting things you want to bring up that we haven’t managed to discuss?
We touched on the antipatterns. I would like to make the developers read this and make them aware to keep an eye out for those patterns. Developers copy and paste on the high level too. Set them my way. I like to collect them and see what I can do with them. Publish something. It’s a community effort. We should discuss those and identify those things.
Keep an eye out for those patterns.
I love that concept. I will personally be sending you any antipatterns that I come across. I love that concept of looking at things in almost a mirror image or a fractal image that allows you to see things from a different angle. It’s a wonderful way of approaching application security and product security in a very modern way.
You are a very well-known expert in this space. I appreciate your time coming on the show. We have come to the end of another episode of the show. I would like to extend a heartfelt thanks to you, the incredible guest, Joern Freydank, for coming on our show. You have immense, profound knowledge and passion for product and application security. It’s very inspiring to have you on the show.
At the end of the day, hopefully, we helped our audience safeguard something in their digital lives to improve the day-to-day human side of cybersecurity. Remember, cybersecurity is a collective effort. We don’t operate in silos. We don’t operate one-on-one. Every step that we take as a team to educate each other will help to fortify our defenses across the board. To my audience, stay tuned for more compelling discussions on cybersecurity. Until next time, stay vigilant and stay secure. See you soon.
Thank you.
Important Links
- LinkedIn – Elevate Security
- Facebook – Elevate Security
- Splunk
- AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis
About Joern Freydank
