The Testing Show: Cyber and Security

Panelists:

References:

• Pentesting Primer: You’re Getting ‘Hacked,’ so Read The Fine Print
• (How) should we change Cyber Security testing?
• Chief Information Security Officer
• OWASP Top Ten Project

Transcript:

Michael Larsen: Hello everyone and welcome to The Testing Show. Glad you could join us today. I’m Michael Larsen, your show producer, and today we would like to welcome our regulars, which includes Mr. Matt Heusser.
Matthew Heusser: Good time zone.
Michael Larsen: We’d also like to welcome back to the show, Elle Gee.
Elle Gee: Hi. Thanks for having me back again.
Michael Larsen: And our special guest today, we would like to welcome, I believe all the way from Israel, Uri Bar-El.
Uri Bar-El: Yeah, all the way from Israel. And thanks for having me.
Michael Larsen: Fantastic. All right, well our topic this month is cyber and security. So Matt, let’s get this show on the road.
Matthew Heusser: Sure, yeah, thanks. So Uri, tell us a little bit about your background in cyber and security and what you do so the audience can get to know you.
Uri Bar-El: Yeah, so I’ll be as brief as I can. I’m not used to talking about myself. I started my way in the cyber domain 20 years ago, way before it was reinvented by a marketing genius and called “cyber”. So I started leaning towards information security or data security, computer security, and I started my way in the Israeli army actually establishing their first cyber defense unit. Then it wasn’t called that way, but that was my start. From there, I moved to a cybersecurity consulting firm based out of Israel, did eight years in the UK establishing our UK office there and managing it. After we sold the company, I focused on establishing cybersecurity practices in various organizations; the insurance, tobacco, finance industry. Then at the beginning of the year, joined Qualitest with this very fascinating, I would say, challenge for me.
Matthew Heusser: Tell us about the challenge.
Uri Bar-El: I think I used to say that this move into Qualitest was not a trivial one given my career path. Qualitest is a testing company. Cybersecurity is a completely different niche, but the 20 years that I’ve done cybersecurity got me to understand that there must be a different way how we do cybersecurity testing. I always liked to give the example and nice quote by Albert Einstein that “it’s a miracle that curiosity survived formal education”. I like this quote. It holds a lot of value for me. Education is one of the areas that I’m most interested in. For me it’s very strange that a classroom today looks suspiciously similar to a classroom 20 years ago. The way we teach our kids, the way we deliver the materials, the what, how and who… Is suspiciously similar. And the equivalent for me in the cyber domain is that 20 years ago I sold penetration testing and today people still sell penetration testing as the assurance. But everything else changed. Technology changed the way we develop product’s changed, but security hasn’t changed, at least not rapidly enough. So for me, the opportunity with Qualitest and the challenge with Qualitest was how can we do security testing in a different way, not in an incrementally different way, but in a paradigm shift different way.
Michael Larsen: So that brings up a point that I’m curious about. Why do you think it is that penetration testing seems to be where everybody focuses their attention? If there are other threats that we need to be concerned about, why does penetration testing get all the attention? And if there are other threats we should be worried about, what are some things that are happening out there… to borrow a Matt phrase, what is the “new hotness” in security, I guess, that we’re not even paying attention to?
Uri Bar-El: Yeah. I think the reason that penetration testing still holds such a prominent role in security assurance, there are two aspects to it. One, it is a great fig leaf for organizations. They did their pen test. That’s it. They can check the box and say they’ve done their security. It is of course wrong. The second reason is the enabler. In this case, security is still an outsider to many of the processes within organizations, so even if we have the security organization inside our corporate, it is still an outsider to, for example, development processes. The R & D team develops a product, they have their dev ops teams. The accountability is very much clear today and then at the end comes security from the outside tells us what to do and how to do it and dictates exactly what needs to be done and so accountability is being split and it is very convenient for the organization because they don’t need to be accountable for security on one hand and security can not be accountable for this real level of security in the product because they don’t have overall control. So that’s why I think penetration testing is still being considered a legitimate assurance tool where in practice it’s just not enough.
Matthew Heusser: Well, it sounds very similar to the problem in traditional testing we have this group of outsiders that is brought in frequently at the end and told to figure out if it’s good enough that is disconnected from building the work itself and because of that they find big problems and we have to do it all over again and fix things. It would have been easy to do right in the first place.
Elle Gee: I think that that’s the problem he is describing and I think it also, Uri touched on the fact the disconnect between the security teams and the software teams. I think that’s a very real problem. It’s affecting a lot of development teams now. His teams want to be more embracive of an environment where security testing is part of the process from the ground up. They’re fighting a tradition where security and the checkpoints are held by another team and there’s this battle. Who’s responsible? When can we get into the game? How can we influence the game? And that battle is being fought at the administrative level and the security testing opportunity in the development life cycle is still being lost.
Matthew Heusser: Yeah, and I think it’s worse for security than for traditional testing because with testing, at least over the last 10 years, I see testers getting closer and closer to development teams being in the development teams. When there’s outsourcing, they’re working hand in hand. When they’re behind there a day behind. They stick around when the sprint or the release is over for the next sprint or release so we know each other’s first names. With penetration testing, I think you’re right that it’s a frequently check box. It’s done for compliance. We bring in some outsourced firm and they do some stuff. We just give them the credentials. Here’s the fake log in, here’s a webpage, go do your thing. There’s no relationship. It’s one time, it’s for two weeks. We get some feedback if we’re lucky. We fix it and retest and that’s it. It’s much more disconnected from the actual flow of development work, so getting into the flow, I would think it’s going to be very difficult.
Uri Bar-El: Yeah. I think in my experience, when I was on the other side, when I was running a cybersecurity consulting firm, this disconnect was our toughest challenge. While we enjoyed doing the penetration testing to some extent, I think the disconnect with the development and with the testing teams put us in a place where our value add was always very limited. Even if we did find interesting vulnerabilities or interesting breach points, et cetera. It was always the single point in time and the single point in the application, we all knew that there would be other issues. We only pointed towards the problem. We were never a part of the solution. This disconnect has caused security over time to look like we are only pointing at problems. We’re never part of the solution and that is something that until we solve this disconnect, we won’t be able to really provide the value that security should and can provide in securing our products today.
Matthew Heusser: The great hope for a lot of companies, I think was the Chief Information Security Officer. Here was gonna be a C level role that asked the tough questions and had a seat at the table and directed resources. My experience has been that the promise of the role and the reality of the role, there’s still some promise yet to be realized. What do you think about that role? Is it relevant? Is it important?
Uri Bar-El: Yeah. I usually say that the “C” in the CISO is there by mistake or in organizations today it’s not really acting as a C level. It’s usually sitting underneath the CIO, for example, reporting to the CIO, which is the real “C. I think in terms of relevancy, the best example I like to use is 20 years ago again when I started this, the role of the information or the data security officer or the responsibility for data security was with their physical security officer and the main reason was because of the similar word, “security”, the physical security. Let’s take the financial sector as an example. The physical security, chief physical security officer, same person responsible for securing the branches and the vaults and everything else, was responsible for the data security. Now the more data security and information security domain evolved, the easier it was to understand that the skillset required is completely different and the role of the CISO was born. That was two decades ago, more or less. What we see today is in my opinion, a similar situation where in the last couple of decades, CISOs had focused very much on corporate security, malicious software and on the lateral movement and on threat hunting and all sorts of different technologies and methodologies. That for me in my opinion, almost perfected the corporate security side of things. But that was the focus of the CISO role. Where the CISO did not focus enough was around software development. And that’s where we see now a very big gap. Just like the physical security and data security 20 years ago, the required skillset, the required knowledge, the required technology to secure the corporate is completely different than the knowledge, knowhow, methodologies and technologies which are required to secure the development process, the development life cycle, just by chance it has the same name in it, security, but what I see now is another need for this divergence of having the CISO role focus on one side on corporate security and having another organization focusing on software security where it is again, a completely different set of skills which is required. So that’s why I think that CISOs today in this organization is not providing the value that it should in the product development side.
Matthew Heusser: Yeah, I see a lot of CISOs looking at things like passwords, usernames, audit trails, documentation, logs, policy compliance and that’s necessary but there’s not much code inspection. Penetration testing is a compliance activity that is disconnected. They’re not changing the requirements process to consider security. We’re not doing much threat modeling. Those are all things that I’m just not seeing a lot of happening.
Uri Bar-El: That’s true and again, there is two problems here. One is the direct one. We are not securing our products in a good enough way. We’re seeing the results of this issue and the second problem is something I mentioned before which is around the accountability because the CISO does not have the skills to actually become a part of the solution. Then it is a part of the problem and accountability is then shared between the R & D and the security and it’s almost like a hot potato situation. We throw responsibility around and eventually without a very clear accountability of this risk, it falls between the cracks.
Elle Gee: Uri, how do we change the narrative? How do we bring security into more relevancy in the current development life cycle?
Uri Bar-El: That’s a great question and that’s the challenge I joined Qualitest to actually try and solve. I’m air quoting, but the traditional cybersecurity consulting firms are not in a position to solve this problem. They are building other ways and we need a completely different setup. The key aspects of how to solve it is, again, I know I’m repeating myself, but I do believe this is the cornerstone of making this change. It’s fitting the right skill set to the right task. Currently we are asking the security experts to have two hats. One to be the evangelists to be on the cutting edge, thinking out of the box and find those zero day vulnerabilities in those business logic bypass and all those kinds of very complicated and a very specific mindset things. On the other hand, we are asking them to be consistent and to have the coverage and to look for vulnerabilities throughout applications, using code reviews, et cetera. We’re asking the same people to have two very distinct skillset. That brings me to the point that I saw the opportunity within Qualitest is security testing is mature enough and we have the tools and knowhow to test for those well known vulnerabilities to a level where we can now hand it over to the testing experts where we do have this again, tool set knowhow methodology to get the greatest coverage possible at the best point of time throughout the development life cycle. So I think the key point here is that we can now bolt on security to whatever testing is doing right now and the best example is looking at testing five years ago where it focused on specific testing, but accessibility testing was different and now it’s an integral part of testing. So I think security is in the same place now. It’s now something that is mainstream enough that can and should be tested by testing experts.
Michael Larsen: Okay, so of course this is going to be the obvious lead in here if you don’t mind… “but I’m not a security tester or I’m not a security expert. Therefore I don’t know that I have much value that I can add here”. Let’s face it. That’s probably what a lot of people who are listening to this right now are going to think, “well, if I’m going to be focusing on security, I don’t even really know where to start”. If you’re a functional tester and somebody who is more focused on traditional testing, we’ll just use that and they want to move more into being able to do security testing. Where do we start?
Uri Bar-El: Yeah, it’s a good question. First of all, I think that the actual statement is not completely accurate today. If you are a good tester with enough experience, onboarding security into your skill set will not be so difficult. It does not require that very unique skill set that we mentioned before. That’s one part of my answer, but there’s still truth in what you said and I’ll give you the example of what we’re doing in Qualitest. Qualitest is 3,500 quality engineers across the globe. What we’re doing is we’ve developed a training program with two levels. One is a basic level where each of our quality engineers goes through the security training program and this training program gives them the skills and tools which we’ll discuss in a second, to actually onboard security into their day to day jobs That’s one level. The second level is where we do a more advanced training, teaching them more about additional tools and techniques, identifying the more complex vulnerabilities and uncovering the more complex vulnerabilities. That’s what we’ve been doing in terms of training. In addition to the training, we’ve developed a framework of thousands of test cases, which are cybersecurity related that any quality engineer at Qualitest can access and you use them as part of their testing plan. Together, the technology and the knowhow and the training provides our people with the tools to actually overcome the problem you stated,
Matthew Heusser: So that sounds great. I don’t disagree with any of it. I am going to push back a little bit and this is something that I’ve seen. So we say, wait, wait, wait. We got to bring security. Wait, wait. We’ve got to bring performance in. We’ve got to bring usability. Whoa. We’ve gotta bring risk management. I was working with a North American based team at a branded company you’ve heard of recently and they showed me their definition of done and it was “your security requirements are identified, security is tested, performance is identified, performance is tested, usability is identified, usability is tested”… like this huge overwhelming set of things. And I thought, Oh my gosh, this team is never ever going to actually get any software out the door. They have to do all this stuff and you’ll never guess what happened. Anybody take a guess?
Elle Gee: Missed deadline.
Michael Larsen: Let me guess. The testing never got done? Dot. Dot. Dot.
Matthew Heusser: No! Well, sort of like they just ignored all of it. They just did nothing. Every single story that came through was like usability requirements, not… they didn’t even fill out the forms, but if they had it would have been not applicable. Not applicable, not applicable. They just didn’t do anything. So I guess what I’m asking is is there a risk that we either burden the teams down to the point that they just ignore all of it or it’s one of those things where there’s just so much, how do we help people sort the wheat from the chaff to figure out, “No, this is a login screen. We’re going to look at security.”
Uri Bar-El: I think you’re mentioning exactly the current problem where security dictates what needs to happen. Long forms to fill in. There is risk management processes and eventually everything gets disregarded because we need to get software out. That’s our livelihood. Everything else is an add-on to me. It needs to be there as long as it contributes and as long as it plays along and that’s the problem that we see now. The solution is very similar to what instigated dev ops. Dev ops was created or agile was created to overcome certain, I would say logistic issues. Now everyone’s working together. It’s that much easier to get stuff out the door. Now, if security will be a part of this DevOps, not the CISO organization lending someone to be sometimes a part of dev ops discussion, but security is a real part of the delivery team. Then it’s no longer about lists and should have and going back and forth. It’s about doing stuff as it needs to happen.
Michael Larsen: I guess that also brings back to… ’cause we’re talking about the idea of CISO, right? The whole point being, maybe Elle, this might help on this end, too… the thought that I have here is that we’re looking at the idea of “is CISO a person or is CISO a role and responsibility? How do we address that?” Do we look at this as somebody who has a knighted noble title and that they’re the ones responsible for all of this or is this something that an entire team needs to embrace and embrace from point one?
Elle Gee: I think that’s going to vary from project to project. In my role, I’ve seen both outcomes. I’ve seen where we’re still seeing security handled separately and on the other side of that coin, one of the projects I’m working very closely with at the moment they’re in like sprint 10 of a brand new development and they are thinking security. They’re asking the testers to be a part of that security solution from this early in the process. They’re not waiting to check a box, they’re not worried about do we have those checklists in place? They’re actually taking the approach that we want to make sure from day one that we are considering all of the important aspects and we want to make it a part of the normal development process. It’s very exciting to see,
Matthew Heusser: Well, I think we got a vision for what testing could be. We have a way to move it forward for security and it’s a more expansive view of risk management. The classic story I see is we marginalized testing and then wonder why it doesn’t deliver good results for the investment. So I’m very pleased. I think Michael kind of asked before, but I would say to to Uri, specifically, concretely, what can people do to learn more? Where can they go to learn more? What should they be doing to self-educate beyond “These are great arguments to make”, but then what your boss says, “fine, do it.”
Uri Bar-El: First of all they should come to us. That’s the obvious answer, but I think there are quite a lot of online resources today that help testing engineers improve on cybersecurity testing skills. There are quite a lot of resources online and we are using some of these resources in our internal training and we see great results. What we are mentioning here, while it is a paradigm shift, the market is very ready for this paradigm shift and I think on an individual basis that’s how things happen. Evangelists that decide that they are trying to do that within their team, their organization, their development process, et cetera. So one of the main ways to get yourself educated on cyber security vulnerabilities and how to test for these when their abilities are resources such as the OWASP organization, which maintains the famous top 10 list of web application vulnerabilities. They have a lot of online resources that help you test for these vulnerabilities. They have the juice shop, just as an example, it’s one of their projects which is an eCommerce website full of vulnerabilities and a lot of guidance on how to uncover these vulnerabilities. That’s just naming one of the key resources online to get yourself educated about cyber security testing.
Matthew Heusser: What does OWASP mean?
Uri Bar-El: Open Web Application Security Platform
Michael Larsen: I guess at this point we are… it’s always arbitrary. We say, well you know we’re, we’re running to the end of our time. What we really mean is we realize that people who are listening to this their is valuable and we want to honor that. So to be able to wrap this up, I guess last thoughts and comments for anybody who wants to get them in. Uri, you are our guest and you are the expert, so if you got… Famous last words, what might you throw?
Uri Bar-El: I was really hoping not to say the famous last words so early, but there needs to be a paradigm shift. There might be many ways to do it. We chose one way, we believe is the relevant one and it’s the relevant one because in our opinion, it helps both the traditional current CISO and cybersecurity roles for people doing good jobs that they are doing and maybe for once gained some headway in this cat and mouse game that we’ve been playing for decades and it helps us get an overall better quality in our products. And security is an integral part of quality.
Michael Larsen: Fantastic. Ell e, famous last words or last thoughts.
Elle Gee: I think that the testing industry has always been awesome at evolving and moving forward and reshaping itself to stay relevant. And the next stage in staying relevant for those in a QA testing role is to make sure that security like accessibility is a foundation skill and a foundation testing approach. And I’m excited to see the direction that that goes.
Michael Larsen: Excellent. I guess my thought that I would throw to this, just because I’ve been pondering it in another section I’ve been focusing on, and I’ve done a couple of talks recently about testability and part of the questions and thoughts behind testability, and I keep bringing this up, is it’s not the be all and end all answer, but of course we tend to focus on the things that we tend to focus on. And so if we’re curious about, what can we do to improve testability? The first question we say is, how would I test that? That starts the conversation. So it seems early on in the process of when new features are being implemented, how do we secure it? Or how do we consider the security of this? It sounds trite to say it that way, but I think that if you do start to have that conversation very early on to where at least you’re considering what are the security aspects we want to or need to look at. It’s not just that the “Well, we’re about to push the release out the door. Let’s go through our security protocols. And if we find anything wrong we’ll fix it then”, which isn’t often very pleasant if you do actually find something. Whereas if you’re looking at it and say, let’s think about security up front, I think that you would probably have a much more pleasant outcome. That’s just an opinion. Matt, what you think?
Matthew Heusser: Well and if you don’t think about security upfront, you’re going to get in a stupid argument with the CISO so who might or might not really understand what it would take to actually resolve and might or might not be able to weigh the business needs versus the security impacts. I’m just not a fan of stupid arguments. I’ve had too many of them. I think we’ve got a compelling vision for how we could move testing forward and to a more expensive role. It’s not going to be consistent. There are going to be companies where you sit in a cube and follow the checklist and do what you’re told, but to stay relevant tend to have a more expensive vision for what testing is over the next five years. Really happy with how we laid it out today. The question is, are we going to get there? So I’d love to have this podcast again in two more years and talk about the gains we’ve seen moving this thing forward. It’s a real pleasure. Thank you.
Michael Larsen: So Uri, expect us to call you back in a bit.
Uri Bar-El: Two years is a long time.
Matthew Heusser: It does feel that it might be nine months. Yeah, you got it.
Michael Larsen: Good Point.
Elle Gee: who knows. Maybe we could revisit in six months. You never know.
Uri Bar-El: No, just kidding.
Michael Larsen: Uri, since you are our guests, if people want to know more about you or they want to be able to contact you directly or you know, learn more about what you’re about. What are some links that people can like, are you on LinkedIn? Do you have a blog? Are you on Twitter?
Speaker 2: Yeah, I have a LinkedIn. It’s all new to me because I used to be in the shadows more or less. So they can contact me through LinkedIn. They have my email address there, they can contact me on my work, email in Qualitest, whatever is most convenient to people. We can provide it in a link or something.
Michael Larsen: Fantastic. And as everybody knows, and if you are a regular of the show, we always include our contact info at the very front of our show notes. So if you want to get in touch with any of us, that’s the best place to look.
Matthew Heusser: Get on the Slack and bug all of us and ask us any question you want, we might even answer it and the price is right.
Michael Larsen: Definitely.
Matthew Heusser: Which is Free!
Michael Larsen: All right. With that, I want to say thanks to everybody for being with us and, uh, we will catch you on the next episode of The Testing Show. Have a great day, everybody.
Matthew Heusser: You too, Michael.
Elle Gee: Thanks guys.
Uri Bar-El: Thank you. Bye. Bye.