Welcome back to Pentester Diaries. In this episode, Cobalt’s Grahame Turner interviews Core pentester Stefan Nicula on customer communications. Exploring the importance of transparency, alignment, and empathy.
Pentester Diaries is multi-formatted, with audio, video, and written versions of the episode below.
Watch the video podcast here:
Prefer to read the episode? Below you can find a transcription of the podcast:
Graham Turner [00:24]:
Welcome back to Pentester Diaries. My name is Graham Turner and I am your host for this episode. And today I am talking with Stefan Nicula about customer communications. Thanks for hopping on the show.
Stefan Nicula [00:32]:
Hi. Great. Thanks for having me. It's good to be here.
Graham Turner [00:40]:
It's a pleasure. So before we get started, let's talk a little bit about you, who you are, and what you do.
Stefan Nicula [00:47]:
Yeah. So a couple of details about me. I'm a pentester. I've been working on pentesting for the past seven years. I've been doing this actively and professionally for more than eight years. In the past three years, I've actually been studying more about expert development, reverse engineering, and windows internals. And in terms of pentesting, I'm doing all the stack, starting from web to mobile networking and engagements.
Graham Turner [01:20]:
That's awesome. And along the way, you were also dealing with customers from time to time?
Stefan Nicula [01:26]:
Yes, of course. That's a big part of this job.
Graham Turner [01:32]:
Absolutely. So, we're going to be talking about how to communicate with customers, how to make sure that your pentest is set up for success from the start, that kind of stuff. Just kind of getting everybody on the same page at the start. So I wanted to talk a little bit about, how do you kind of set the stage for a customer, how do you walk them through what to expect when they are starting off?
Stefan Nicula [01:56]:
Definitely. So I think the first step would be me actually preparing ahead of the client's communication, so suppose that we are speaking up after the initial steps of deciding the pentest and actually going through the documentation and preparing ahead of the project. And I think one of the quite important initial steps would be actually preparing a kickoff call and some customers are available, some not, but usually, this is a strong start, especially in a complex project because after I prepared myself by going through the brief to the documentation, testing the credentials, the scope, the access, it's also important, to have that first kickoff, just so everyone gets together and talks about the scope.
Graham Turner [02:56]:
What does the anatomy of a kickoff call look like? Where do you start? What do you try to make sure you hit?
Stefan Nicula [03:04]:
One of the most important aspects in terms of a kickoff call would actually be seeing the application from the customer's eyes, like seeing their perspective on the application while also answering all of the ad hoc questions because, I mean, let's face it, we cannot answer every question during the kickoff call. Most of the questions, actually the technical ones are asked during the pentests because that's when we also uncover functionalities, we uncover many aspects of the technical parts, but I think the first thing would be just getting familiar with the application and seeing the application through the customer's side while also a quick walkthrough always helps because you can ask quick questions regarding functionalities and you can also spot the crown jewels, or understand the business logic behind everything.
Graham Turner [04:08]:
Okay. So you're seeing what they're expecting the application to do, so you can find ways to make it do what it's not supposed to do.
Stefan Nicula [04:17]:
Of course. Yeah. And also when it comes to customers that are not really familiarized with the pentest project, with the usual workflow, it's important to just sit together and just quickly walk through what tests will be done maybe address any concerns that they might have any out of scope tests or targets, it's also a good way to familiarize the client, the customer with the usual workflow.
Graham Turner [04:56]:
When you're working through, you're talking to the customer, at what point do you start talking to the other people on your testing team and kind of getting them in? Do you meet them before the kickoff? Do you meet them after?
Stefan Nicula [05:07]:
Yeah, so usually on a Cobalt project, the team meets up ahead and has a couple of days to sync and really discuss if anything is unclear or what questions we want to highlight, or what we want to address on the kickoff call. And yeah, I think at least from the communication perspective, the earliest that we can start the better because you can just get everyone on the schedule, get everyone familiarized with everything so that we are on the same page basically.
Graham Turner [05:48]:
Do you find that there's a lot of stuff that you want to talk about with your team before you bring it to the customer or do you kind of prefer to talk about everything with the customer present? Is there any sort of a wall between those two communication lines?
Stefan Nicula [06:06]:
Personally, I'm a fan of transparency and being as public (with the customer) as possible. So, if there is a direct communication channel. For example, Teams channel or Slack channels that Cobalt is using, I think this is one of the best ways to keep close communication with the client and also with the team though, because if you create a channel with everyone involved, and if you address all the concerns and questions there, everyone gets to see what's going on with the project and everyone gets to pitch in their ideas or can contribute something. For example, if we have some issues during the testing time, or maybe the client had some late endpoints, or late targets, that they would like to cover. I think it's important to have this direct communication with them. And, I usually prefer to keep it public, too. Because the thing is that if you start collaborating with the team more internally, rather than publicly with also the client in the channel, let's say, the customer might be intended to think that there's not a lot of activity going in the background. But it's important that the client sees what questions we might have or what technical concerns we might have, because they can also pitch in with their ideas, and can respond on different matters.
Graham Turner [07:36]:
That's a very good point. If you're talking somewhere and they can't see, they may not realize that you're actually doing the work.
Graham Turner [07:36]:
That makes sense. Is there anything else that you think we should be thinking about from the customer's perspective when it comes to communication that we haven't talked about yet?
Stefan Nicula [07:53]:
From the customer's perspective, having a dedicated person would be ideal. In a project, it's good to have not necessarily a technical person, but rather a dedicated person to handle the communication. Because not all the companies are the same and not everyone can join some integrations with direct communication channels. Maybe you're discussing via email or phone and having someone that knows the application internally and also knows internally teams that the person can quickly reach out to if there are any issues or any specific questions. But everyone can work. That would be ideal, but everyone can also work outside that with the least amount of communication.
Graham Turner [08:46]:
Right. So it's important to have somebody. If they're technical, is that a bonus or does that technical background sometimes get in the way?
Stefan Nicula [08:58]:
Yeah, if it's technical then that's perfect because you get to ask the specific questions and you have no boundaries between explaining situations or getting certain information. But it doesn't have to be. I think it's enough to just know the right people to forward the questions to or involve other people in the communication. Yeah. It will be more than enough.
Graham Turner [09:28]:
That's really helpful. Definitely having one person. We've talked a little bit about the customer's perspective, but what about from your perspective as a pentester and from the perspective of other pentesters. What kind of things are important to set up for communication?
Stefan Nicula [09:56]:
Yeah, the direct communication channel really helps us. I've seen that an increase in the team updates, methods of reporting, or keeping in touch with the clients lately. If we look back a few years ago, there wasn't quite that direct communication through the client, or at least from the pentest perspective. You'll get the report, let's say, at the end of the day or at the end of the project in the engagement. And that was it, of course, there were some communications during that phase, but you couldn't express what you've tested before or what you've accomplished so far. I think right now, the trend of providing direct updates and constant updates to the customer.
It's also good for us, as pentesters, to index everything that we've done so far. It helps us communicate with each other better and overall it results in a better coverage. Because if I see some notes from a fellow colleague that has tested an endpoint and has found some interesting scenarios but couldn't quite manage to get it done get to the final stages, I can pitch in and maybe help on that. Or, that would be also from my side, if I have trouble identifying something, I can just shout out in the channel, it increases the team play, let's say. I think from the pentesters point of view addressing questions quickly or issues, or immediately addressing critical findings, let's say, it's really useful for us because it makes everything much smoother for everyone.
Graham Turner [11:42]:
Are there any tools that you like to use for that sort of thing? We've talked a little bit about Slack. Do you have any other things that you like to do to kind of make sure the communication is going through?
Stefan Nicula [11:55]:
Yeah. So I think Slack would be one of my favorites. There's also Teams and other tools, but I mostly prefer Slack, I think this is a personal choice, but at the end of the day, any direct communication tool would help.
Graham Turner [12:10]:
Okay. So it's mostly about putting something into the channel. Because that was something that we talked about, that there are no stupid questions and we talked about making sure that we communicate. Nobody likes looking silly, right? Nobody likes asking a question that they think other people are gonna think is silly. So do you have any advice on making sure that people either feel comfortable asking those questions or a way to know when a question should be asked?
Stefan Nicula [12:56]:
Okay, I think this strongly translates into speaking your mind rather than forging the perfect question, I'd say. So if you have a question you most likely haven't understood something fully or you have something that's not thinking right. So I think just explaining what your understanding about the issue was and what's your question, at least in technical aspects that would be really useful for the ones that answer. For example, the customers, and also from our side of the pentesters, it would help us understand how the question or where the question originated from, because as you said there are no stupid questions. I think overall, we should do better in terms of how we explain our questions and how we got to that question in the first place.
Graham Turner [14:00]:
I think that's a very good point. So have you had any situations where either good communication and asking those questions ahead of time really helped to find something more interesting, or on the flip side, like we were just talking about a situation where not asking that question sooner may have created a situation? I've given you two scenarios, so feel free to tackle either.
Stefan Nicula [14:24]:
First of all, regarding the good communication part, to be honest, I think some of those findings or critical findings, maybe even deep tests, deep coverage tests, some of them are done using direct client communication and strong teamwork between the pentesters and the client. For example, I've had a lot of past projects involving complex applications with a lot of set-ups to be made with a lot of verification steps that you could not go through if the client would not help you through the process of the steps and reaching to that point that deep coverage point I think is really important because let's say you're just trying your way in, or you're not familiar with the processes, or it might take quite a while.
Those sometimes are never reached in terms of a pentest or let's say bug bounty process you don't have the client that can guide you or help you validate some steps, in order to move forward to make the proper validations. So you can reach into the application. And I think this also includes not asking questions fast enough, because if you have a question, if you have a concern, or if you're stuck in a specific process, I think, the quickest and fastest way to resolve this would be to ask the client about it. Of course, try to figure out first why this is not working, or what specifically do you need, because that will also speed up the process. The question should be as clear as possible so that the client can answer as fast as possible.
Graham Turner [16:19]:
Okay, can you talk through any examples of a situation where communication kind of helped you get the customer and your team to the same place or to understand the impact better? Not naming any names, obviously.
Stefan Nicula [16:35]:
Yeah, so complex applications, for example, a past project was testing a CI/CD kind of solution. And those solutions usually involve a lot of setup, usually involve a lot of configuration on both the application that you're testing, but also in your local setup that needs to contact directly the application. And I think the most important part actually in that process was communicating with the client and syncing regularly in order to make the proper setups. So we can actually reach out to the functionality that the learning target or any scope, and also providing constant team updates helped us reach out to the client more in terms of visibility and the customer also understood what we were testing and how much we should change our tactic or our testing scenarios. So we can get the coverage needed for that specific project. I think that was a good example.
Another example would be trying to identify the line vulnerability that you cannot get feedback from, so sometimes for example, in some specific vulnerabilities, you can exploit them, but you cannot see the actual result of that. And some projects were very successful from that point of view because the customer was right on point with feedback on output and showing us exactly the actions that we took, how they reflected in the backend, in their internal systems. And yeah, we managed to confirm some of those vulnerabilities, which were rather not very accessible from the user's perspective.
Graham Turner [18:32]:
That's really interesting. So I want to talk a little bit about some different scenarios that folks might find themselves in while they're pentesting. We've talked a lot about the best-case scenarios when everybody's in the channel, everybody's talking, the customers responding, the pentesters responding. What do we do when we've got a customer that's just completely absent? There's just no response. It's you're asking questions and getting no answers.
Stefan Nicula [19:03]:
Yeah. So that also can come in place. And I think it was more common in the beginning when the communication with the client started going off, but now we see this less and less. In those situations, I think, first of all, we kind of need to understand that not everyone has the resources to allocate to be in contact with the project, especially when you don't have the direct communication integration. For example, your internal company does not allow Slack or Teams, or any other tools of that search. In that case, the communication can be quite limited, or maybe one person installs that and has limited access over the working days for that. I think we need to be, first of all, understanding that not everyone can allocate that resource in that time, but from a pentesters perspective, we should also not rely or comply with that. But actually ask the questions that we need to ask, not really spam them but just as the questions, and if you get the answer then that's ideal. If not, just leave them and address them later on or, make them aware that there were some questions at the start, and at the end of the project, there were some questions, there were some concerns that can maybe be addressed later in a project.
Graham Turner [20:37]:
Do you find that sometimes there's sort of a flow of communications or people respond when they can versus people being around every day? Do you find it more common that people are like 'I'm around at this hour' or are people kind of hanging out all the time and answering Slack questions?
Stefan Nicula [20:58]:
I think that not everyone can allocate a lot of time for this. Especially on the pentesters side, I think there's more flexibility to it, because everyone works different hours and if you could work any time of the day. For example, a lot of pentesting teams are international, so you would always find someone in the slack channel, at least from a pentester's perspective, that can answer any questions or address any of that stuff. From the customer side, I've seen that most of the customers are active during their business hours because they are also doing this from the business perspective rather than projects like pentesting.
Graham Turner [21:48]:
So we talked a little bit about customers that aren't getting back to us. What about when you have customers who are getting back to us, but are not being very helpful or potentially trying to ask more than they should be getting that kind of stuff that people who are being, I hesitate to say difficult, but they're being difficult.
Stefan Nicula [22:09]:
Yeah. Certainly, we encounter some difficult situations, but honestly, I think it's more from the communications perspective, because if there are some difficulties in the communication between the pentesters and the clients, usually something was not fully understood or something was not fully explained even like, for example, simple stuff like the scope, or maybe a vulnerability wasn't fully explained or better explain we need to kind of remember that not everyone has the same background and not everyone has the same technical background, technical details. So it's our responsibility to be as specific as possible, as detailed as possible. So everyone can understand what's going on or you can easily refer to the details. So you can understand if you have certain questions and I think it's also important to address everything with a positive attitude because at the end of the day this is what really matters.
Stefan Nicula [23:21]:
Just to add, for example, in terms of communicating with the customer in terms of expectations and aligning them with reality. For example, in some particular cases, clients might be intended to think that maybe just one pentest project per application would suffice or would cover everything that they needed, and oftentimes some customers are surprised that findings keep piling up even after the second project or so.
Usually, it's good to communicate this early on and to align the expectations with the actual reality. And by that, I mean, if someone were to find all the vulnerabilities one time, especially for example, in complex applications, complex solutions, no one would say no, but this is the actual process and it takes a lot of time. It takes a lot of choice. That's why it's also important to have pentesters taking regression tests or new functionalities just to cover everything and go as deep as possible.
Graham Turner [24:37]:
This may be a question that you'd asked during the kickoff call, but it just popped into my head, how important is it for you as the pentesters to know why the customer is asking you to test something? Whether it's compliance driven versus 'we're putting this new application out and we want to know if it's broken' that kind of stuff. Is that super helpful or is it less useful?
Stefan Nicula [25:00]:
Definitely. I think this is also pretty important and it's a good question because it also helps us understand the application, how mature it is in terms of security, and it also helps us better understand the scope and the expectations. And also it guides us on our scenarios of attack. For example, if I would know that a functionality or an application was tested like 10 times before, I would not be as concerned as much about the low hanging fruits, let's say, or a vulnerability that you can easily find, rather, I would start creating more complex scenarios of attacks by targeting the business logic behind and overall trying you find other ways rather than the common vulnerability, so to speak, because most likely those have already been found in previous tests.
Also, a counterexample would be the opposite. For example, if an application wasn't as it was before I would be more focused on those ones initially, just so I can get the low-hanging fruits and everything that's can be found really easily. And then we can work our way up to more complex tests.
Graham Turner [26:25]:
Okay. The difficult question, the one that I always have a hard time with when I'm talking to a customer is, when do I know whether I should say no to something? And the follow-up question is what's the best way to say no in a way that they're not going to become difficult.
Stefan Nicula [26:41]:
Yeah. That's a tricky one because I think the partial question would be explaining what is possible and what is not, because if the coverage is huge enough, you can do as best as possible to get that coverage while also explaining the process. But ultimately from the process that you're doing from the workflow and from your transparency you can draw the conclusions that there was not enough time, let's say, to get some coverage. Or maybe there are impossible tasks, like finding vulnerabilities when they're not there, that would also help explaining that some implementations are okay. And not all the functionalities have some flaw in them.
Graham Turner [27:33]:
Yeah. Definitely. I find that very helpful when I am trying to say no to somebody is having something concrete to tie it to, because it's harder to argue against something like: 'we didn't have enough time' or 'it just doesn't exist' versus 'I don't want to.'
Stefan Nicula [27:51]:
Exactly. And I think it's also a good example where, in one project you find something, whereas in another you find different thing. I think it's important to understand that each pentaster, each researcher, has its own test scenarios and its own perspective and someone might find something while the other might not. And it's also, I think it falls down into one of those tricky questions, like why hasn't this vulnerability popped up during your tests, or something like that. I think the answer is more complex than that because maybe the target was different. Maybe the scope was different. So there are a lot of variables on that.
Graham Turner [28:37]:
Yeah, definitely. That is also something I will say that I also sometimes rely on somebody who's got a little bit more authority than me to say no, so a project manager or a manager. I've worked in retail, so I've had to sometimes ask my manager to come and tell a customer no.
Stefan Nicula [28:56]:
Yeah. That can be difficult, I imagine.
Graham Turner [29:00]:
So just kind of to recap, what were some of the top takeaways that you want people to go home with?
Stefan Nicula [29:08]:
Yeah. So I think in terms of communication, a direct channel would be ideal. And also, if you get a time as a customer, please allocate that time because it will be useful from everyone's side. If you can monitor what's going on in the channel, if the pentest project is having more transparency or more public information that maybe you should totally follow up on that because those are basically the skeleton of the pentest and what's going on.
And as a closing point, I would say that not all the communication is based on a kickoff call or during the pentest. I think it's also important that we should not overlook the retesting phase because that's also an important aspect, or after the project. Most of the customers like to retest or fix bugs just after the pentest has been done, which is usually the ideal workflow, just so you don't tell alter the testing environment. Having that communication during that phase, maybe the customer is not able to produce some findings or maybe it's partially fixed, or the patch has been applied but they need some guidance on how to retest them on their own. That also falls in the communication category, and I think it's also an important aspect to just keep in touch with the client and answer those questions.
Graham Turner [30:43]:
Cool. I did also want to point out two other takeaways that I got from some of the things you were saying. One was just the communication begins before the test even starts, before the kickoff call. You're spending some time preparing, looking at the materials, connecting with your colleagues and getting everybody on the same page. And that's really cool. And the other thing that I really liked and to want it to call out was the notion of understanding and being a little empathetic and just realizing that not everybody's got the same schedule, not everybody's got the same background, just, you know, understanding that everybody's coming from a slightly different place, I think are two very good points that you made. Cool, was there anything else you wanted to add in before we call it a podcast?
Stefan Nicula [31:28]:
Oh yeah. I think that would also be all from my side. I think the social aspect of a pentest is definitely important. Of course, the technical part gets you the juice, but the communication is also important then combining them together I think is the way to go.
Graham Turner [31:50]:
Yeah, definitely. Awesome. Thank you so much for stopping in and chatting with us and thank you to everyone else tuning in for this episode of Pentester Diaries. I'm Graham Turner, this is Stefan Nicula, and I hope you enjoyed this conversation.
Stefan Nicula [32:03]:
Yes, thank you for having me.
