Insights Podcasts The Testing Show: The Changing World of Cyber Security

The Testing Show: The Changing World of Cyber Security

July 6, 2022

Once upon a time, and in many ways still, there was the sense that Cyber Security was the realm of elite professionals who were trained and experts in all things security related. They were special unicorns who far outstripped mere mortals. Of course, this is not true but it is a perception that persists.

Today, Uri Bar-El joins Matthew Heusser and Michael Larsen to talk about how and where Cyber Security is changing and how it is becoming less about the external nebulous threats (which still exist, of course) and more on the way that everyday testers and software developers need to hone their own cyber security skills and bring the issue of security into the development and testing process much earlier and with an eye towards total quality.














Michael Larsen (INTRO):

Hello and welcome to The Testing Show.

Episode 118

The Changing World of Cyber Security.

This show was recorded on Tuesday, June 14th, 2022.

For many, Cyber Security is seen as an ivory tower, populated by elite practitioners and experts. To that end, Uri Bar-El joins us to talk about the changing role of Cyber Security and bringing it more inline with the development and testing process, much earlier, with an eye towards total and better quality.

And with that, on with the show.

Matthew Heusser (00:00):
Thanks, Michael. It’s great to be back. This week, We have a special treat for you. We have Yuri Bar-El, who is the head of the cybersecurity practice at Qualitest and a vice president. It’s neat that we have that kind of executive representation at the practice lead level. And we’re gonna talk about security. Now, Uri has really grown up in this particular role, going back five, 10 years. He’s been leading cyber security organizations and practices for various companies; Amdocs for a while. Actually, I think you started that practice there. Finally came into Qualitest in 2019. He’s been here a while. So maybe tell us a little bit more, what I’m missing in that intro, and then maybe a little bit about what you’re doing with Qualitest now.

Uri Bar-El (00:51):
Sure. Thanks Matt. First of all, thanks for saying I have 10 years of experience. It makes me a bit younger than I really am. So it’s somewhere around the 20 years and been doing it since the beginning of the internet, more or less. So, yeah, that’s how old I am. I’ve Been with Qualitest for the last three and a half years. Something like that, which gone by quite fast, considering the circumstances. And I’ve been doing this in all different capacities. So from technical aspects of security to building practices, both internal and external practices, selling security, but also internal practices, how to secure the organizations. So I think in a way I’ve earned a little bit of credit on where security is and where it’s heading.

Matthew Heusser (01:41):
Great. We were talking before the show started about the state of security today, and I think Qualitest quality is the name. It’s not just testing. When it comes to security, it’s not just penetration testing. We understand security testing. It fits in with software testing, but security itself is a much broader topic. And frankly, there are aspects of security that are cutting edge and interesting and exciting. And at some companies aspect of security seem stuck in the previous century. Can you give us a feel for… you’re a lot closer to the metal than I am. Where is security at right now? And is it really fit for the problems it was intended to solve in general?

Uri Bar-El (02:26):
Yeah, no, it’s a good question. I think security now, to put it bluntly, is at a crossroads. There is a divergence. The way I like to look at it is when I started my journey in security, the role responsible for information security or cyber security was the same person responsible for physical security. Why? I think because it had the word security in the title, but then after a few years, we all understood that the skillset is completely different and we need a dedicated role for that. And that was the role of the CISO, where it was born, the information security officer. I think now we’re at a similar intersection where security is really much divided into two elements. One is the corporate level, Corporate IT, how do we protect our machines, our servers, our corporate assets? I think that while security has been embedded in the corporate security aspects, whether it is the technology, security technology people process, we’ve done great work there. I think we’ve dropped the ball on security in the development process. While development changed immensely in the last decade, I don’t believe security was there to embed itself into the development life cycle, the changing development life cycle. And I think that’s one of their biggest difficulties for security right now to remain relevant.

Michael Larsen (04:05):
So Uri, if you don’t mind me asking, we’re already on the idea that security seems to be behind the curve when it comes to development and when it comes to quality assurance and what we can do. With that in mind, what perhaps are some things that you might suggest that we as testers or people who are actively involved in quality, how might we be able to approach security in our everyday quality assurance and testing roles so that we might be able to push security farther forward in the process?

Uri Bar-El (04:41):
Yeah. Yeah. One of the biggest things that we’ve done in Qualitest since I joined is actually to try and eliminate the differentiation between quality and security. And when you ask how we, the quality people can also do security, it’s a bit of a contradiction in terms because no one today can say security is not an integral part of quality. Quality product is, by definition, a secure one. It’s not what can we do to introduce a little bit more security into how we test. It’s more of a question of is security and security testing specifically a mature enough domain today, again, both in terms of the processes and the technologies available and the skillset, is it mature enough today to be handed over to the testing experts rather than remain at the security experts hands? And we are all acutely aware of the problems that we have in skillset or missing skillset in the security domain. And I think that instead of constantly searching for more tech that can do things a little bit faster or replace a little bit more people, handing over this huge domain of security testing and embedding it as an integral part of the day to day of testing companies, such as Qualitest. I think that can be one big part of the answer.

Matthew Heusser (06:16):
It’s the bring in a specialist, cause what I was gonna ask next… two particular types of security problems, which you can get with penetration testing. One is find a way to upload a JPEG file that is secretly JavaScript that gets it to run, to get to the point where you can run code on the source computer. Another one is to send in enough data on an input field to override the data, to get you to a command shell on the source computer. And those are both sort of fallen out of fashion as, for the most part, they’re patched on most systems today, if you’re a clueful company, but when you talk about security and penetration testing, those are just very specific hacks that you knew how to do. I’ve seen a few talks lately about security and they’re all about threat modeling. they’re all about Think like a hacker! Where’s the gold?

Matthew Heusser (07:18):
How can the bad guys get the gold? And how can you protect it? That’s all good, but you really need either a tool, kind of like a antivirus that knows these kind of attacks and point it to a webpage and it can try to execute them, or you need a significant amount of expertise to really know how to do those things as part of the feature test cycle. I think what you’re suggesting is that we do security testing as part of feature test. I was gonna ask, how do you get people skilled enough to do both traditional testing and know these kind of techniques and to stay current on them?

Uri Bar-El (07:59):
Let me respectfully disagree about your statement, that you need great skill set or unique skillset. I think that whilst 10 years ago, it was, as you say, a unique skillset to think like a hacker and running a consulting firm, basically 140 hackers, I can tell you that these people are indeed unique, but testing isn’t unique. What we are essentially asking for a long time now security experts to do is to do two things. We’re asking them to think outside the box, right? We are like this expression. We want them to think like hackers and to push the edges of what we know about security and how to break stuff. But we are also asking them for consistency in their testing for great coverage in their testing. It’s not enough if they identify one instance of cross-site scripting or CSRF or choose your acronym. So we are asking the same people that has a specific skillset for two very, very different tasks.

Uri Bar-El (09:11):
What I’m saying is that security testing today and not penetration testing, we can talk about penetration testing next, but security testing in general today, we have enough tools and these tools are mainstream enough. And also people today, testers today, are much more knowledgeable about security, so they can actually take it forward with minimal amount of formal training. So that’s where I think the industry is at today. And that’s where I think their main change in perception about security testing should be. We do not need this expertise any longer. We need a certain level of expertise, but like any new technology or aspect or domain, after a decade or almost two decades now, it is not as novel as it used to be. And we should acknowledge that. And I think that us security experts have a bit of a problem letting go, because that’s our bread and butter. If we don’t need security expertise to do security testing, then what are we here to do? And I think that’s the wrong place for security to be. I think that prevents us as a practice from evolving and from focusing our skillset on where it needs to be focused on. And that’s, I think encapsulates it.

Matthew Heusser (10:45):
Okay. That makes sense to me. We say security is mature enough now. And I’ve said this before, politely and not politely, read a book. Security is advanced enough now, that as a team, we can gather the materials. We can document it. We can create our checklists, just like we did for quick tests, 10, 15 years ago. And we can come up with some standard failure modes for the platform. Now we just need people that are dedicated to doing that work and maybe to continuously improving in that. So maybe a programmer who views their full-time job as programming is not gonna get into it. But it’s an achievable thing to ask of people.

Uri Bar-El (11:27):
Exactly right. I think that the average understanding of security has risen tremendously in the last couple of years. So I think it’s definitely something that we can expect even young testers to know much more than their predecessors. Also the supporting technology to do security testing is much more mature and mainstream now. It’s not so edge as it used to be. It’s all encompassing in a way and been around for a while now. So I think that the supporting technology combined with the increased level of knowledge in our testers, I think this combination is now safe enough for us to hand it over from security experts to testing now.

Michael Larsen (12:16):
Okay, with that in mind, I’m gonna take off my cap right now and I’m gonna put on the somewhat beginner, newbie’s tester cap. Okay. So I’m coming into an organization and now security is something that I should be versed on and I should understand what it is that security entails and what I can look at. Now, abstractly, I can understand that, but what I think many people tend to think is, okay, great. I’ve got an application, I’ve got Kali Linux or JMeter so I can start throwing a bunch of stuff at it. And that’s where many people start. And sadly that’s where many people end when it comes to doing security testing to say, okay, cool. It didn’t fall over when I did a denial of service attack. It didn’t get poisoned when I tried to do a password injection. We’re done… And all of the platforms, devices, Internet of Things at this point, big data transactions and everything that goes on. We can’t just say, poke something, throw some scripts at it. And you’re good. There’s a lot of threat modeling and there’s a lot of unusual areas that even people who are somewhat familiar with security might not know a whole lot about. So how might they go about understanding what those are? In other words, less of a, okay, security is important. What security things should I be considering?

Uri Bar-El (13:47):
I think there are a couple of points to address in your question. One, throw in a few tools and poke a few places and see where we are at. I think that’s less of a relevant approach nowadays. We all say let’s shift security left. Like we are shifting everything left. And by shifting left, what we mean is let’s address security earlier, as early as possible in the development process. And as early as possible can mean different things to different companies, with different cultures of development. There is no silver bullet here or there is no right answer here. In terms of what I need to think about as a tester, it’s a bit of a wide domain. It’s almost like saying, okay, now I’m a developer. What do I need to know in order to develop a good product? There are a lot of things to think about, but I think if we’re shifting things left and maybe adding another aspect to it, we need to really focus on the basics.

Uri Bar-El (14:54):
Because if we deal with the basics, then 90% of the work is done. How do I control input? And making sure that through input users can’t do any harm. And how do I control output? After there is an input, my application throws something back at the user. I need to control both these things. Once I do, it’s easy. Now, input and output, it’s a lot in there. And just like testing or just like developing or writing code, we need to start understanding what we are up against. So if we know how injection works and if we know how CSRF works and if we know how you know those very elementary OWASP Top 10 if you’d like and vulnerabilities work, we can start testing for them. And then we need to learn about how can we automate it? Cause testing it manually is no longer an option. If we look at random software development life cycle, we see very rapid processes with an ever increasing rapidness. We need to also know how to integrate automation into the development life cycle. Integrating this automation is one of the key subject matters nowadays that the security domain is chasing after.

Matthew Heusser (16:19):
That makes sense to me. Correct me if I’m wrong, we see you building up to an idea that security is not external. It’s not the security team comes in every six months and audits and then makes us change this, that, and the other thing. And then every year, the external security auditors come in and make us change this, that, and the other thing. But instead it’s embedded within the teams. We have team members. It’s not DevSecOps as much as it is… it’s all devs and security is devs. Do you think there’s a little pushback or resistance against that?

Uri Bar-El (17:00):
First of all, exactly. And you’ve hit the nail on its head here. As long as there is a SEC in whatever we say, like dev SEC ops, or whenever we keep security as something external, we will never solve the problem because we’ll have this issue of owning the problem without being able to solve it. So security owns an issue, whatever it is, a code issue, a design issue, but security and people within the security domain are not the ones responsible for solving the issue. So I think, first and foremost, what we need to do is to align those two things. You own the problem, you own the solution. That’s the only way that it can go forward. That’s why we are constantly trying to… Not really educate because market is already educated on that, but we’re trying to become a change agent with our clients in who should really own security,

Uri Bar-El (17:59):
And our answer is R and D, development. They need to own security. They own the solution. So they need to own the problem. They own the product. These are the things that we push for with our clients and with our beliefs. And we can see today that DevOps experts, whatever DevOps evolves into, because DevOps is a very wide definition today. DevOps experts today take security as not only an integral part of their role, but a big part of their role, but sometimes security is, is their first concern and first base of knowledge. So I think we are seeing that and the more we’ll see that, the more integrated security will become, and then the more aligned it’ll become. The function that owns the problem is the function that can also solve the problem.

Matthew Heusser (18:53):
I like that a lot. Yeah. You know, longtime show listeners know that I’m, it’s all just quality. So I really don’t like it, for instance, if you say the software has performance problems, the software has load problems. And we come in and say, well, we’re just functional testers. That’s a nonfunctional requirement. And the customer says, exactly it doesn’t function. It’s nonfunctional. Doesn’t work. So we, we’ve kind of, I think in the time we’ve been on the show, Michael can tell me if he disagrees, but the testing world has kind of got a little bit more holistic instead of saying, I’m only a load and performance person. I’m only a functional person. I’m only a usability/UX person… it’s the same thing. It passes all the functional tests. It’s just got some usability problems. So you’re telling me it’s unusable <laugh> and the thing that has resisted a little bit, I think there, for good reason; PCI standard HIPAA standards, there’s lots of regulations around security, has been kind of resistant into joining that umbrella of it’s all just quality. It’s all just DevOps. And I think you’re giving people a way forward to get through that.

Uri Bar-El (20:05):
You know, there’s a little bit of scare with all the different security regulations, but we need to understand. Let’s take ISO as an example. There is two regulations, two ISO regulations that relate to security. I think there are hands or hundreds, more that relate to other stuff, and we tend to get stuck on the security regulations being afraid of them. And basically if you read into the security regulations, common sense, written into bullet points. I don’t think that what we used to call “FUD”, the fear, uncertainty and doubt that we used to sell security with. I don’t think it’s relevant anymore. Regulation in around security today is easy to understand and easy to comply with. If you’re developing your software correctly, if it’s not an afterthought. as long as it is an afterthought, then yeah, it’s a problem, in terms of how much time and money wastes. But if you’re integrating it soon enough, there is no real worry it should be burdening us.

Michael Larsen (21:16):
So if I’m hearing this correctly and maybe this is a tangent, it seems to me that I have a number of friends who have worked in security for a number of years and in a lot of ways, those people that work security, that is a very core element of what they sell. That is their uber-specialty. We’re getting to a point now to where, if I understand correctly what you’re saying, the idea of security as an uber-specialty. Yes, there are going to be times when you have the absolute best of the best, who need to deal with some kind of amazingly mission critical system that you’re gonna call on who’s gonna have that specialty. But the idea of a security specialist as a general term (I realize that’s an oxymoron) is going to go a bit by the wayside. Am I hearing that correctly?

Uri Bar-El (22:13):
Almost. Let me try and give it another aspect. There’s always going to be a need for the Navy SEALS, but giving the Navy SEALS tasks that can be more achieved by the masses or should be achieved by the masses, by the army. That’s our problem. What we’re doing now in the security domain is we are getting our Navy SEALS, our highly skilled people that can and should be tasked with the cutting edge and thinking about what’s next. And we’re keeping them occupied with very trivial things. That’s our biggest problem. So it’s not that the speciality of security is no longer needed. What I’m saying is that the specialty in security testing is no longer needed or getting less and less required. The required skillset security skillset is still a huge thing for us because currently the bad guys are making headway. And I think that the reason for that is because we are burdening our good guys skillset with trivial tasks or with tasks that do not befit their skillset, to be more accurate. I hope that makes sense.

Michael Larsen (23:31):
Yes, it absolutely does. Thank you very much. So we are coming up to the end of our time here. I think we’ve gone through all of the talking points that we discussed earlier. So this is where we usually say, what’s the 3 second elevator pitch or the, where can we find out more about you? What are you doing in the broader sense? If people wanna know more about the topic or about you in particular?

Uri Bar-El (23:58):
Okay. That’s where it gets awkward because I’ve spent my life out of the limelight. You can always reach me on my, qualitest emails and learn more. And I’m always happy to have a conversation around these or other topics. But yeah, I mean, I’m now all over the place in getting to me and reaching me. So I think it should be easy for everyone.

Michael Larsen (24:19):
Fantastic. And of course, we also have your contact information, which we will include in the show notes and other details that will be included there. With that, I wanna say thank you very much for joining us, Uri, and for everybody who is listening to the testing show, thanks again for listening. And we will see you very soon. Take care everybody.

Uri Bar-El (24:39):
Thank you. Bye bye.

Matthew Heusser (24:41):

Michael Larsen (OUTRO):
That concludes this episode of The Testing Show. We also want to encourage you, our listeners, to give us a rating and a review on Apple podcasts, Google Podcasts, and we are also available on Spotify. Those ratings and reviews, as well as word of mouth and sharing, help raise the visibility of the show and let more people find us. Also, we want to invite you to come join us on The Testing Show Slack channel, as a way to communicate about the show. Talk to us about what you like and what you’d like to hear, and also to help us shape future shows. Please email us at thetestingshow (at) qualitestgroup (dot) com and we will send you an invite to join group. The Testing Show is produced and edited by Michael Larsen, moderated by Matt Heusser, with frequent contributions from our many featured guests who bring the topics and expertise to make the show happen. Additionally, if you have questions you’d like to see addressed on The Testing Show, or if you would like to be a guest on the podcast, please email us at thetestingshow (at) qualitestgroup (dot) com.