From Payloads To People: The Other Half Of The Job - Dumisani Masimini

All yours. >> Hi, thanks for coming. Um, my name is Disani. I'm a penetration tester from Paint People. Um, I won't waste any of just get to know each other after after the talk. Um I chose this talk here um because we've had a lot of tinkle talks that we've um listened to today but um none of it actually um speaks to the consultancy part of it um as far as actually um how to present what you have found. They're very good um technical people that are give us findings but um how do you come back to that? How do you communicate that to your client? So that's what we're going to be talking about today.

Um let's um so what is um my slide over this is lost. So when people think of penetration testing um they think about basically the pillows that can getting SQL injection um credits you are basically um you you're pinging but you already ping unnecessarily hard um so now we going back to where now how you going to translate what you have done into um into actionable um tasks. So um we move on to the people side, the documentation part of it as well as the the explan explanation of it and how you actually um get your point across into actionable um content. So the the report is basically what we are delivering. This is what we are selling

through all the value chain where it comes from the CEO down to the person who's actually cleaning and in the what we're selling as a as a consultant company is the report is our deliverables um normally a good report we have uh three sections the executive summary this is basically for decision makers this is for the CEOs for for for basically the nontechnical And then you get where you put your you clarify define your technical stuff uh where your IT people need to actually action these particular um features that you found the bugs that you found um and then basically you actually lift them into terms of prioritization. What is important? Um what do they need to do

now? What is impacting them now?

So like I said the client actually are wonders um what is this? What does it mean to me? Um where do we go from here? So us as the consultants who have actually done the job we become basically the bridge between um thinking the technical part as well as the business part showing basically the the impact that whatever what binary you found how you compromise the domain for example how how how does it actually translate into r into sorry not rans so I'm a South African I'm saying r um into pal pounds and dollars. Um, so yeah, but really here's where the really uh the job expands. It's not about finding the vulnerabilities. It's about telling

the story of risk. Clients actually do care about CVS. What keeps them up at night? Data loss, downtime, compliance, financial impact. Our role is to really translate and detail it into a business language that they actually understand.

Part of the tool that we need to actually have is running deep calls. Um I don't know if you've sat in a few deep brief calls after you've actually brought down the domain and now you need to explain this. Um it's it's it's not a it's not an easy part especially if you have tricky um see or um admin that is personally not so keen to hearing what you want to say the debrief where the debrief call is where everything actually comes alive but in a deep call itself don't just read the report tell the story what did you do how you got go across I mean like use example make makes the risk relatable to the client,

pause questions at times, listen to what they have to say and then and when tricky come question comes basically you try and navigate it think about it pause for a second and find an answer that actually is both going to help the the end user which is the current this

soft skills that maybe set you apart. This is the part that isn't taught in a tactical in technical training. Basically listening carefully, showing empathy over of the situation um adapting to your tone basically of the room itself. These skills will say to you about and build trust amongst the amongst your clients. Clients will forget CBS, but they'll remember how you made them feel when they were lost and confused in terms of how do we

what I've learned that way. So, I've been a penetration test for 5 years. the first two or maybe the first couple of months they weren't the smooth sailing as I thought it was. I had to be um I had to go into debrief calls. I had no knowledge of what I was doing at that particular time. knowledge of actually doing conducting a deep proof call as so um that that particular anxiety build built up quite some up until actually stepped into it learned from it adapted to basically how I conduct myself when I'm actually busy um engaging with a client I've broken a few networks of explaining that to a client but The most important part is just to

keep calm to relate what you have found in a in a sensible manner that will won't make you or the client feel out of um out of your debts. Never miss a growth moment cuz each and every step that has happened in life in general that there is actually a growth um a growth moment or a learning moment. Oh, I think I went too fast. This is the last line. Give you 10 minutes back. So there are practical takeaways. Always connect findings back to the client. The reports basically don't write reports or audiences. I said it's for all the technical people and the nontechnical people which is mostly the decision makers lead debrief calls with confidence.

Focus on the business impact of your findings and build soft skills as well as um technical skills deliberately and wow wow the point you guys out. >> Yeah. Thank you. That's that's that's my

>> Do you have any questions?

>> I think I Great presentation. I think you're really to the point. I love the storytelling. I think that's really really important as part of that. I think but I find also I think in your experience I previous experiences. So if you're doing a financial application and if you've seen others I don't know if you see kind of being able to tell that story. How how do you find that >> for for specifically financial >> like if you're doing infrastructure and you see two different infrastructure you to tell the customer this is what I've seen before and this is the sorts of things you can improve on. Is that sort of thing? >> Well, I think when you relate to a story

that of that you've done and when it brings you credibility um you've seen this before and this is this is this is how you're going to fix it as well. You actually know um how you're going to fix that. Um the story that you tell it's it's it's going to be said to to to the client say, "Hey, um this is what what is happening. We've seen this before and this is how you would normally fixed it depending on how long how long ago it was actually um if it's relevant for the time as well.

>> What approach would you take to talk about um linking it to business impact? It's not necessarily something that we talk about. How did you find that business impact? >> For one, um you I spoke about downtime as well. Um servers are down. Um your your web applications are down. They're not accessible. Um the what the what the consumer consumes externally that we can't see the front end. If if if that is down, if the back end is down, we need to uh convey that in a way that says, "Hey guys, once down time is um you'll be losing x amount of money on on on a product that is not currently online at the moment. So you if it's

consumed by human or from that side, I think you mostly in terms of money basically that's what it's all about. It's the biggest impact is are we making a financial loss? Are we making a financial inner part at that time? So yeah, >> makes you tell them about it is going to hurt their pockets. They'll they'll make >> I have a follow question on that. Um when you're trying to put stuff into perspective in terms of money um do you get access to financial records for the company or you use publicly available ones? >> We use what we find. Okay. >> Normally it would be if we find um basically information that's not supposed to be seen by anybody

>> um we use that be like hey you able to access your your payroll or anything else like that. Um so in order to you just put mitigation so that people who are interning or extern can don't have access to such records >> right >> you say more about personal growth that can improve what would you say was one of your best moments was beneficial you for personal growth >> realizing that I don't know anything Yeah. So, yeah, I I was always trying to to run to to to master and to learn everything for for there's not enough time. There's not enough life in a lifetime. I can't um you can always try to be better as well

as like up the mistakes that you made. Um that's how we grow. We own up to the mistakes that we make. We take accountability to that and

question actually. What's what's the part of pentesting you really enjoy? Cuz I'm guessing you do a whole load of applications and you do infrastructure and you do a whole is there something you really really enjoy? um when it impacts real life um situation um it varies really um because I've I've done a lot of mobile tests >> that I would actually be able to track live cars um from a very company and um for banks you were able to basically manipulate um funds into person's account so it it varies the I think The job for me is actually trying to the other person. >> Yes sir.

>> Both I think they think that they need to be both there. Um you you'd find that there will be executives who are technically savvy and maybe you don't need them to be there. Um but you'll find um um where you need the ITI or the person who's actually in charge of the system that needs to be there in order to actually say hey this server we don't need we can actually decommission it and then see the the executive would know such information. So um when you run debriefs with both the technical and nontechnical guys, you kind of basically um you you you you're not um cutting corners so to speak. You are covering both sides of the technical part and the

business side of it. Um cuz at times you sit at a call where they are at each other. You're just you just you're sitting back. You're just listening to them. All you just did for saw the finding a technical guy is trying to explain why is it back. So yeah um it's it's beneficial to have them both um in a great when you're doing your penetration test do you ever come across things like that might be doing that are you know illegal or something

like

I've never come across a situation like that. Yeah, I want to speak on that. >> Yeah, sounds interesting. >> Yes, sir. >> Do you use information to make contest? I think um AI is a powerful tool. If we going to use it, I feel like we're missing out on something as well. Um and if you use too much then um stepping away from the traditional way of doing things. Um >> yes, we say I think that's a short answer. any examples of these cases? >> I'm bad at coding number one. Um, but if you would actually want to run a simple task, um, so you I want to do A, B, and C and will you do it for me? And then as

it goes along, you basically tell it to basically do what you want to do. Um so yeah here you're basically telling it what you want to do in sort of actually relying on it you know the outcome of what you want and then um you just tell it hey this is the outcome that I want and yeah

>> I currently work in a stock with you being a consultant is there something that uh like some kind of myself to keep in mind what you receive that report. Is there some sort of collaboration you would like to see from the team? >> Don't shoot us down, man. We we are finding stuff that's that's that's environment and you just you just like um some some SIS admins they don't like that. Um yeah, you you you'd spend a couple of hours defing a medium finding while we have high findings that have much more greater impact. Um so pick your

thank you very much for your time.