In this episode of Redefining CyberSecurity Podcast, host Sean Martin and guest Francesco Cipollone discuss the security vulnerabilities in pre-made website development tools and the importance of threat modeling and secure defaults.
Guest: Francesco Cipollone, CEO & Founder at Phoenix Security [@sec_phoenix]
On LinkedIn | https://www.linkedin.com/in/fracipo/
On Twitter | https://twitter.com/FrankSEC42
On YouTube | https://www.youtube.com/@phoenixsec
____________________________
Host: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]
On ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/sean-martin
____________________________
This Episode’s Sponsors
Imperva | https://itspm.ag/imperva277117988
Pentera | https://itspm.ag/penteri67a
___________________________
Episode Notes
In this episode of Redefining CyberSecurity Podcast, host Sean Martin is joined by Francesco Cipollone from Phoenix Security for a riveting conversation on the vulnerabilities associated with using pre-made tools for website development. The dialogue revolves around the inherent security risks these tools pose, especially when used by non-technical teams like marketing.
Francesco shares a fascinating account of discovering a potential SQL injection in a well-known CRM system. This revelation underscores the importance of input validation and the necessity of secure defaults in any tool. The discussion also brings to light the fact that many systems do not consider these potential security risks as standard, often requiring additional licenses or configurations for basic security measures.
The conversation takes an interesting turn as they discuss a new concept of a Workflow Bill of Materials™ (WBOM)—a term coined by the host, Sean Martin, for the first time. This idea extends beyond the typical focus on software bill of material security (which often focuses on source code, services, and APIs) to include a broader view of the tools and systems that teams use in their daily operations. The WBOM concept emphasizes the need for organizations to understand the associated risks of these tools and implement more secure practices.
Sean and Francesco highlight the importance of threat modeling in identifying potential risks. They also discuss the challenges organizations face in ensuring security, especially when these tools are used by teams with zero security knowledge. The episode concludes with a call to action for the industry to move towards security by default and the ethical use of technology.
This episode offers listeners an insightful look into the complexities of cybersecurity in the context of commonly used tools and systems, and the urgent need for a shift in perspective when it comes to securing these tools.
___________________________
Watch this and other videos on ITSPmagazine's YouTube Channel
Redefining CyberSecurity Podcast with Sean Martin, CISSP playlist:
📺 https://www.youtube.com/playlist?list=PLnYu0psdcllS9aVGdiakVss9u7xgYDKYq
ITSPmagazine YouTube Channel:
📺 https://www.youtube.com/@itspmagazine
Be sure to share and subscribe!
___________________________
Resources
Francesco's LinkedIn Post: https://www.linkedin.com/posts/fracipo_bit-of-a-rant-on-the-security-tax-of-certain-activity-7139650868064202753-LZ21/
___________________________
To see and hear more Redefining CyberSecurity content on ITSPmagazine, visit:
https://www.itspmagazine.com/redefining-cybersecurity-podcast
Are you interested in sponsoring an ITSPmagazine Channel?
👉 https://www.itspmagazine.com/sponsor-the-itspmagazine-podcast-network
Please note that this transcript was created using AI technology and may contain inaccuracies or deviations from the original audio file. The transcript is provided for informational purposes only and should not be relied upon as a substitute for the original recording, as errors may exist. At this time, we provide it “as it is,” and we hope it can be helpful for our audience.
_________________________________________
Sean Martin: [00:00:00] And hello, everybody. This is Sean Martin, your host of Redefining Cybersecurity here on ITSP Magazine Podcast Network. You're very welcome to a new episode where I have the pleasure of chatting with some really cool people who know much more than me about a lot of things. I know enough to be dangerous, and I know enough to ask, I think, interesting enough questions to help folks think a little differently about how they think.
Implement the security programs, not to just, uh, protect the business revenue that they, they create, but also protect the value and generate value in the business as well. And today we're gonna be looking at the world of AppSec application security, and I'm thrilled to have, uh, my good friend Francesca on.
How are you?
Francesco Cipollone: Hello, Sean. Very good. So. Across the pond
Sean Martin: from each other, but, uh, but a big warm hug to you. Nonetheless, [00:01:00]
Francesco Cipollone: we'll miss each other at Upset Cali. So next time, I didn't get
Sean Martin: to the beach this time. We did, we did see each other this year in London, which is a nice street. Nice street.
Francesco Cipollone: You came to the cold area.
I
Sean Martin: went to the gray and wet and cold, uh, but I love it there. And it was a treat seeing you there. And, and, uh, we've been talking about getting on another show and having a deeper conversation and a post you put up on LinkedIn, which is where I get a lot of my inspiration these days, prompted me to connect with you to say, let's chat about this.
We're not going to name any, uh. Any companies here, but I think what I, what I saw in the post and in the thread, this particular site gave me pause, let's just say, um, one, one for just, I know you can't fix [00:02:00] everything overnight, but it's been a while, some of these things have existed, we can point to the OWASP top 10, we can say, why are the, why is the top 10 the same?
You just kind of reshuffle the numbers, but it's still effectively the same list after all these years. And. Yeah. I think we're going to get into the point that this isn't just an engineering thing, right? No, it's a business. I'm going to leave it right there. I'm going to, uh, we'll get into some of that. I think people find this interesting.
Before we dig in though, uh, Francesco, uh, I certainly know you and people who've listened to this show have heard you here before, but, uh, a few words about what you're up to now. Uh, that'd be great.
Francesco Cipollone: Thank you, Sean. So, um, I'm a AppSec practitioner, uh, by heart and by trade that, uh, turned startup, uh, and long time ago, and then fundamentally took, was frustrated on how things were looking like from an AppSec side.
Um, the fact that we [00:03:00] had fragmented tool across the board and started, um, a company called Phoenix Security that, um, It's basically out there to solve this kind of problem. And as an app sec company, uh, you know, we are constantly targets, uh, by people that want to prove that we know how to do application security.
And, um, we continuously test because that's our ethos, um, our internal attack surface management, our external attack surface management, because that's what we do with our own dog food instead of just selling it. But in this kind of exercise, and I think that's where the conversation started. With Phoenix Security, um, is where we found kind of an interesting gotcha and that sprawled into a whole piece and research and, uh, rabbit hole that then ended up in the post that you mentioned, um, but yeah.
Sean Martin: Yeah, I love it. And, uh. Yeah, I think we connected. You were, [00:04:00] uh, you were a CISO for a fairly well known, uh, financial institution, helping them with some of this stuff as well. And, uh, yeah, I enjoy following what you do and, uh, the work that you, you, uh, that you produce and the results that you get from, from some of the stuff you engage in.
So, This isn't about your company. This isn't about necessarily your, your research, but you're, you get to see a lot of things. So maybe let's paint a big picture here, kind of some of the stuff you've experienced over the last 12 months as we approach the end of the year here. Um, yeah, I was kind of joking, not really about the OWASP top 10 kind of being still relevant.
What's your thought on that looking back on this year?
Francesco Cipollone: Though, I think I'm fairly optimistic, um, on the past couple of years, I've seen really a [00:05:00] shift in GIEM with Phoenix Security. We engage a lot on the vulnerability management side, on the application security side. And I've seen these two words finally coming together, together with the cloud security side.
So really team talking for sure about making prioritization and vulnerability management cool again with the CISO. Uh, kind of stepping in heavily and, uh, generally speaking, uh, needs to here in Europe stepping in heavily on saying this is our crown jewel. We shall protect them properly and really stepping on with the SEC mandate on reporting breaches in a timely manner, but as well putting in a good and a bad way.
Liabilities on the CISO if the product security and if the product is not secure enough. And I think I've seen with that a whole motion of [00:06:00] organizations start taking application security more serious or putting it in the center of their strategy. Now FUD and a lot of, um, fear and fear mongering on this BOM, uh, kind of Legislation and people needing to produce Spawn without understanding what that purpose or what that mandate was for.
That is really understand your asset inventory from what you build and where you run it. But in general, there was a whole motion of application security now is in the agenda of a lot of CISO. The challenge is not a lot of CISO understand or coming from a development environment. So they've been the question of.
Okay, what do I have? How do I paint that picture? And how do I give direction to my developer that is not just silly SLAs? And a lot of people understand OWASP top 10 and assessing by OWASP top 10, but [00:07:00] application security is much more than just the OWASP top 10. It's what you build, that is now very complicated, and where you build it, and where you deploy it, and who owns it, and who needs to solve it.
Because luckily, Over are the days where we just use service level agreement or just pure silly timers to actually mandate what needs to be sold. Because that has failed massively. And I finally appreciate Garner putting the nail on the coffin of SLA saying SLA don't work 100 percent of the time with a couple of interesting use cases.
Um, that really brought forward the conversation of like, okay, how do we prioritize things? And how do we apply SLA to things that are priority? And finally, cyber risk quantification that as a finance industry, we used to be a bit more advanced in this, um, fairly 10 years ago, five years ago is where we really brought it forward.
But then the rest of the world [00:08:00] start catching up with the finance industry, uh, that is very heavily regulated on, on this, um, and being trading desk, being managing a lot of money. Um, the regulation come, come naturally and, uh, needs to, and critical national infrastructure kind of mandate across the world really with India.
Uh, US and Europe in general, mandating a better security posture as several kind of heart of element in the heart of the financial institution, uh, between banks and trading organization kind of got hit between ransomware or breaches related to obligation security. So in general, there was, okay, we need to step up our game.
Um, maybe relate to CHAT GPT or other AI tools, but I've seen Um, and I was discussing this with another another CISO friend of mine at a very known cloud security company. It also does threat intelligence research. And he saw as well as shortening [00:09:00] times between a vulnerability being published and being weaponized.
It used to be 30 days, 40 days. Now it's 3 days. So. I don't know if it's a coincidence, but definitely we are learning how to defend ourselves faster using AI, um, and automated tools, but also attacker are going that much faster and they're not subject to regulation. So they are developing. definitely exploit faster than what people can defend upon.
And we've seen this with the breaches with the last two years, there have been more breaches around software security, either supply chain or through stealing of keys or any variation of the sort. Um, so I'm really glad to see more regulation around, um, liability on one end because it's going to bring really the subject in front of the board saying, I don't want to go in prison.
I need to understand what is the risk of the stuff that we're running. So give me the tool [00:10:00] to actually do that or I'm out of here. And I think I've started seeing CISO having this kind of conversation around. There is a lot of nervousness, um, but I like to see the positive aspect of it, uh, of this debate that is, uh, now the regulation has teased.
Sean Martin: Yeah, and I think you, you summed it up quite well the whole year with the SEC, uh, notification, the, the cases around, uh, CISO responsibility and liability. And you mentioned SBOM as well, the Bill of Materials. And. I want to go to that last point with you as we start to transition into this particular case that prompted our connection today.
Um, The Bill of Materials, the SBOM stuff, a lot of effort in there. A lot of work from CISA here in the US, um, to help at least US companies. And I think a lot of, a lot of folks around the world follow it as well. [00:11:00] Really get a handle on what's in the stuff they're building, Bill of Materials. Right. And, um, I'm wondering your perspective on this, cause what we're going to get to here isn't necessarily what an organization is building from a code perspective.
It's what they're building from a workflow perspective. They're using services to build out business processes and workflows that drive action. Right? Some, there may be points where humans interact with the workflow. There may be points where the systems just do their thing on their own. But there are teams like marketing in this case, have selected a tool, either they're using it in the cloud, or they're getting IT to help them deploy it in some fashion.
And then it goes into the business process. And in this case, there are some problems. [00:12:00] That leave, certainly that system, that system exposed and perhaps even the business process exposed at a, at a grander scale. So talk to me a little bit about, we're not going to name names here. Well, I'll include the thread.
So if people are interested. To, uh, to dig in deeper than they can, but tell me a little bit about what
Francesco Cipollone: you've done. Yeah, let me give a little background, but before jumping in that, I think you raise a super interesting point. That was the spam regulation has driven kind of a laser focus approach on third party open source supply suppliers.
And, um, nobody wants to share what they're building for a reason or another. So The whole purpose of Spawn with the VEX and the Vulnerability Exchange and that was a good initiative without, I think, understanding how organizations want to protect their IP and what they're building [00:13:00] or how they want to share.
In my opinion, and I'm going to close out this because otherwise we're going to talk about Spawn for the rest of the day and week.
Sean Martin: There's plenty to talk about,
Francesco Cipollone: that's for sure. Yeah, I think from that perspective, having a more risk based approach on like what you build and where you run it would have been a little bit better, but maybe more complicated to demonstrate.
So Spawn was the initial approach, but not the end goal. But let's close it there. Um, on the point that you were mentioning, um, I think I put my marketing hat and my non technical hat in there and that's what kind of scared me but also made me think and I'm pretty sure, uh, you thought in the same way on.
There is, there are kind of PII and confidential information or kind of user information that travels through websites that probably are not built with security in mind or are used as [00:14:00] I'll spin up an event, I'll build this form with this CRM kind of systems. 90 percent of the time, because development is expensive, I'll build it with pre made tool.
And that's WordPress in most of the cases, with kind of some plugins that are usually run by marketing people that that don't have expertise in security, uh, neither in business development. So they run, um, sorry, neither in, in developing a website. So they run these tools, maybe they forget about it and they become the gateway, uh, of, um, a lot of customer data because once you build it and once it works, it kind of gets used all the time.
And in my previous careers as a CISO, respect. Regardless, if I was running enterprise, I kept on seeing WordPress popping up that should never appear in an enterprise organization, but because it was free, cheap and cheerful to run, people spin it up in a docker [00:15:00] container with a website, customize it a little bit with a form.
And then forget to plug it in there. And because Attacker knows this, they target those forms specifically. So there is a lot of vulnerability that comes from these forms. Um, probably once per month we monitor. We've been writing about this on WordPress specifically. Um, at least we've seen six major vulnerability on forms or WordPress of likes this year alone.
And now you take that problem and you say, okay, I'll use an enterprise tools. Um, and there are several CRM, well known CRM systems or calendar registration tool that are the bread and butter of how marketers nowadays and how salespeople are running campaigns, small events. They don't want to build a website.
They actually want to form. And we use it as well. Uh, as, as Phoenix, as Phoenix Security, we use this because, uh, we don't want to build a whole website if there is a tool that [00:16:00] does the job for us and does the, uh, CRM for us. But as a security company, we're constantly bombarded by people trying to prove that we're actually a security company and we can do what we say we do.
Uh, And 90 percent of the time ends up in an interesting conversation, uh, with, I've seen probably both aspects of the word or both ethical hackers that just say, you know what, we discovered that this is a potential thing. And then you spend two or three, um, cycles trying to explain to them in a nice way that's That doesn't lead to anything, but in this particular case, a conjunct testing with an ethical hacker, I'm going to leave the name as well in there, uh, for reference ability, ended up with the discovery of potentially SQL injection, uh, on a well known CRM system that, um, wasn't acknowledged as a security risk.
That's what surprised me the most, as, um, yes, you can inject, inject HTML tags in a form [00:17:00] that should contain a name. And I stopped there for a second and said, how on earth anybody would accept an HTML tag in a name? Like, I don't know. I know pretty much a lot of the people around the world, but I've never seen one with an HTML tag.
Especially,
Sean Martin: think about the context for a minute as well. This is a marketing person, right? Or a marketing form, engaging with somebody who's interested in that company's products, not an engineer who's trying to be clever. So for me, there's really no context where that that's. Use case, anyway,
Francesco Cipollone: no, but apparently there are use cases for it.
So when we raise the particular issue with a well known, um, calendar shattering company, uh, they acknowledge the issue immediately. They fix it quite quickly. And that issue [00:18:00] was a known issue at all. Because they say that there is an on earth, uh, why somebody will put, um, a hijacking link in the name of a field or in a calendar invite that normally people will click, um, and in the worst case scenario, people will weaponize this link because.
All of a sudden, this invite comes from a very well known, trusted company. Um, so you trust them. So your guard gets slower. If it's your company, even worse. So you send to your CEO a click link from your own website. likely, chances are that somebody will say, what's happening in here? Let me check on it. Um, so it's, it's a, it's an easier way to actually weaponize those, uh, tools.
I'm not going to disclose more information because we don't want to weaponize those tools, uh, or, or widespread these, but raise awareness of. Um, I'm a security practitioner. I saw this immediately and this has raised a [00:19:00] red flag. Now, I'm pretty surprised this is not, uh, considering we're 20, almost 2024.
This should be, this practice are pretty much the basic and the bread and butter of application security. Any input validation or field validation against things that shouldn't be in there should be the norm. But a parity for some CRM system and other system is not the norm. It's another benefit, um, you need to buy additional license, you need to buy additional things just to get the basic security.
And I think as an industry we're pretty much fed up with the single sign on tax, with the security tax, of things that are really basics. and shouldn't require additional configuration. We keep on trying to spread the word of security default, but if the tool that we build are security insecure by default, then we kind of lost the battle because We can't protect the whole organization and we can't convince any marketing person to [00:20:00] actually rewrite all of the forms that they've wrote To actually put input validation because there is no way on earth any organization does and any organization that use a CRM system right now is vulnerable of input validation of SQL injection or any form of injection If it doesn't rewrite So
Sean Martin: I'm going to spend a minute here because this is an important thing.
You made a number of important points in this one, one section here. The, you said it early on, this is marketing team. They probably have a, an event campaign that's coming up next week. They want to get as many people to it as possible. Cheap and cheerful, get a page up, get a form up, drive people to it.
And get them to register. They don't want to spend a lot of money. They certainly don't have a lot of time to, to work on this. And if [00:21:00] you're, if you're requiring them to do special configure, we're talking marketing people are no offense to marketing people, but they're not engineers, they're not it, they're not ops, they're marketing.
Right? They know messaging, they know how to connect with people, they know how to generate interest and get them to do things to connect with the company. They're not engineers. So to, to, to require engineering, to require additional expense, to allow them to engineer the form.
Francesco Cipollone: That's even more scary.
Sean Martin: Right?
That, that's a scary piece. Um, so, and. To your point to kind of wrap it in a bow as you said it, I just want to make this very clear for everybody listening is if, if those hurdles are there in terms of time and money, and it's not there by default, we're, we're kind of doing ourselves well, the company's doing themselves a disservice, [00:22:00] right?
And I think everybody who's using this stuff are thinking, well, how do we then. determine if a, if a company we're using, a form we're using, a page we're using is secure enough. I'm going back to the marketer who's making this selection,
Francesco Cipollone: right? And the scary part is it's not. It's insecure by default. And honestly, we're a security company.
We didn't thought about that because we assume at least this basic stuff that they were And when we found this, we were fairly surprised that even those basic mechanisms weren't in place. And actually you had to re engineer very hardly the form, uh, causing a lot of friction in basically rewriting every form with input validation.
We had workaround put in place to actually do that through another third party system, [00:23:00] but it's not trivial to do that. And, uh, it required quite a lot of thinking, quite a lot of reworking. Now, as a startup going to scale up, we have 20 50 forms flying around. So that was a fairly amount of work to actually sanitize at least the core one.
If I imagine a company that runs this at large scale, first of all, it will probably not be aware of how many forms are around. And second of all, it will probably Sanitizing all of them will require a platoon of people to actually rewrite them. Quality testing and seeing if they work. This is insane. And that's what I thought.
It's like, no, there needs to be a better way. And it wasn't. And that's what shocked me.
Sean Martin: So talk to me a bit about, and I don't want to over sensationalize this, but I want to go back to my point on the SBOM typically being focused on [00:24:00] what's being built.
So what's open source services? What commercial services are you bringing together? What's in your software basically, right? But let's look at the bigger workflow picture. So a forum, presumably, is at the front end of a lot of stuff. Um, certainly in this CRM, it, you can envision it sitting in front of a lot of, well, all the marketing pipeline stuff, naturally transfers to sales stuff, which translates or gets connected somehow to revenue systems.
So, depending on, depending on the flow, you might find this weaponized field throughout the entire organization.
Francesco Cipollone: I don't know if I'm mistaken. I think there are two aspects. No, no, [00:25:00] no, you're perfectly right. And I think there are two aspects of it. There is the probably SQL injection or a number of injection that could reveal kind of customer data.
That, that is probably, I hope so, handled. We haven't seen a case where that was. Enact enacted because probably there are compensating control on the back of it. So if you manage a system, um, now if you're using WordPress, there've been a lot of remote SQL injection or remote, um, RC that are. probably more dangerous from that aspect perspective, but a more interesting case and probably the most scary case was where this was used to weaponize and run phishing campaign on your behalf, uh, injecting HTML tag saying, Hi, Mr.
Click here, so you will be suspicious, but if that is a hyperlink of Hi, first name with a hyperlink, you would say weird, but it [00:26:00] comes from a trusted SPDX. So, um, Trust them. Verified, uh, domain Phoenix Security, for example. Um, let me check. Um, because it passed all, all the check through Gmail and Gmail still interpret HTML tags, um, in a specific way.
So it can be used to use your company and you have absolutely no knowledge until your client base comes and say, look, you're sending phishing emails and this is not a trivial way to block it. Um. Because it's, it's, it's widespread across your whole organization is using your trusted system. So back on your point, yes, we mean the whole point of.
secure default and threat modeling, but then we kind of hyperfixated on just a way to build application, um, that is just SBOM. Um, there is much more in application security than just how, which [00:27:00] open source tool do you use. Um, even just in the case of SBOM, SBOM wasn't purposely built to just look at what you build.
But what's the gateway to say, look at your asset inventory, how you build application, where you run it, what is your risk profile, and how can you be smart about fixing or who you should be aware. But in conjunction as well with secure code review and good practice around application security and threat modeling.
And this particular problem falls exactly in the place with threat modeling, where You look at a business process, regardless if like in this particular case, it doesn't have any code linked to it because you're using a third party supply tool or a third party tool to run business process and because there's no code, it's actually going to be used by very low skilled people with zero security.
And this will probably more likely go through pre [00:28:00] approved or not even pass through security at all. So wouldn't even pass through the normal gate that you will go through for a threat modeling exercise. Um, and, and that's, that's kind of where I was thinking of, this is a very easy subject weaponizable case, and this is why you have these, um.
good white hackers that are testing these forms at scale and raising this awareness across the board. And, um, I want to kudos, um, the good folks that actually do this without blackmailing, because we had other people that were trying to blackmail as well as saying you have this and it end up being in unknown things and saying, yeah, we're going to smear your name and we're going to say that you're not secure, even though we had evidence that That doesn't lead anywhere is, is a non, is a non, um.
Unproven injection or none. It doesn't go anywhere, but regardless, there are good folks that actually do this, uh, for the sake of, [00:29:00] of the world to be a bit better secure place. And that's why I want to raise the awareness as well here that maybe we should look beyond just pure. Software security and looking at the threat modeling and threat exercise overall, um, and letting the good tool, um, manage fundamentally software security so that we can focus more on just triaging vulnerability
Sean Martin: day in and day out.
I don't know if it's been coined, I haven't looked it up, but I'm gonna, I'm gonna, I'm gonna call it, uh, the WBOM, the Workflow Bill of Materials. And, uh, so I want, I want to leave this here. I don't want to belabor this point, but I think there for folks listening or watching to this, um, clearly there's, there's a need or justification to say we need to look at the tools that our teams are using to understand how they.
How they fit in and then what, what risk they bring to the organization, right? [00:30:00] So this is, yeah, it's third party risk management. Effectively what we're talking about here, but, but from a pure workflow perspective. I want to go inside now. So companies building. Products. Um, clearly they can look at the OWASP top 10 that gets them a good start.
There are plenty of other frameworks and tools and services to help them build better software as well. I, there's a point in here though, that I want to make, and I'm not trying to throw any, anybody under the bus, but it was an interesting comment. That, uh, we've, we've had other users ask about this, um, but we've only seen fake tests.
We've not seen any malicious script make it through unless somebody's tried and it's unknown. [00:31:00] I don't know what that's saying. We look, but we don't see, but it doesn't mean we find it. We might not find it. And I'm not trying to be funny here. I'm trying to be serious. People building apps. What's the right answer to this?
How, how, how do you, let's say you missed that validation. If things happen, so we'll talk about how you put the validation in place at build time. But let's say you don't do that. What can you do?
Francesco Cipollone: What can you do? That it's not a bug, it's a feature.
Sean Martin: It's a feature that marketing people can engineer their way into a different feature set. What That's build time. What's the, what's the right monitoring and response answer here? What can app dev teams and sec teams do to
Francesco Cipollone: not [00:32:00] have that position? Let's start maybe, um, a little bit broader than that, that's how do you handle a security report?
Because those are getting like right now flooded, um, across, uh, everybody's running is raising security reports. So I have, um, I feel for the security team because, um, there are. People that throw pieces of code from open source perspective through CHAT GPT. Uh, we saw this with LeapCar with tons of vulnerability being raised through their HackerOne, uh, report and 80 percent of them were bogus and just one actually made through and there was a lot of noise being done, so I feel for security team, uh, that received tons of these reports.
Um, but there is a way to acknowledge, uh, this and especially. 2023 Input Validation is like really the baseline for everything. And we saw a good response of like acknowledging. Yes, we see it. [00:33:00] Absolutely. There is no place where an HTML tag or a script index or a SQL injection should be in the name of a field that says name.
Um, that is the answer that I was kind of expecting, not, we haven't seen anybody weaponizing this, uh, despite the evidence in, um, weaponization and the fact that those triggered an interpretation of the HTML tag that we just weaponized. So we haven't seen it with the evidence of, this is the proof, was a little bit.
Sean Martin: We haven't seen it except for seeing it.
Francesco Cipollone: That was a little bit concerning, but regardless, even if there is a remote case, acknowledge it, um, say, you're going to look into it, not saying this, this is never going to happen because it's the classic, our company is unhackable until it is, um. I think there is a [00:34:00] decent response on this, um, and maybe it's because we, I think Contra Security as well raised this, uh, previously saying there wasn't an official security channel.
So there was just a community to raise these issues. And a lot of people that, uh, run these communities are other marketers. So they want to contain the information. They might not want to raise awareness too much. Um, I don't know what the right response is, but this should have been a threat looked by a security person.
And me as a security person, I would have jumped on saying this is probably something we should look at. And it isn't, even if it's, even if there isn't an injection of the case, it could be used by smearing campaign or phishing campaign across the board. So two or three scenarios that really can Compromise the name of an organization, even if it's not a SQL injection script.
There are three or four campaigns. Now as a security professional, I deal with that on a daily basis. I'm aware of it. If i'm a marketing person, [00:35:00] I wouldn't be. So if I put my marketing hat on, I would have just passed that report to a security person. And saying, can we run a threat modeling exercise on this?
Can we see if this is actually weaponizable? And if, even if there are other ways where those fields could be weaponized and maybe putting a CQ default in there. So communication, I think that's where I want to take this discussion to is. absolutely critical on making or breaking a company when you get reported of a breach of an incident, um, of the like.
And I think we start seeing as well ransomware attacker. pushing organizations to pay ransom or reporting them, so blackmailing them on reporting them to the ICO or to the various, the SEC commission and, uh, kind of forcing their hands. So I think acknowledging a security problem, first of all, is a [00:36:00] good way from a PR perspective to save your company trying to hide stuff.
Uh, it's the perfect way to end is the ending of companies. Um, and we've seen this plenty of approach, like 23andMe, uh, very public breaches where they said, well, this is, this wasn't it, but then it was it, um, and, you know, I feel for security team because under a breach. You're under a massive amount of pressure, but that's why PR people should be trained on actually answering those kind of message in a proper way.
Because a security professional, first of all, we're under pressure during an incident, nobody want to answer something like that. And it should be in our good playbook to give a proper politically correct answer, because this is branding, damaging, and share damaging. If you look at two or three well known names that did a very bad answer.
They kind of lost 23 to 40 percent market share. [00:37:00] Yeah, that's money. That's a lot of money. It
Sean Martin: is money. And when everything is driven by money, you got to pay attention to that. Clearly. Um, well, Francesco, I think, uh, yeah, clearly we could talk about AppSec for hours. We can go a gazillion different directions with this.
Um, I think we've highlighted a few things, which is we're making progress. Um, as you noted in the beginning, I think we, the act of building stuff, I think we're getting better at that. Um, having a real time readiness to. Deal with the things where we make mistakes because we are human. Thankfully, still, um, I think we need to continue to do to do better there.
That includes visibility and transparency internally. And then externally, if something warrants, um, but I think the other point [00:38:00] that that really struck me is this. We're using tools throughout the business that have vulnerabilities. There's no way of getting around that. And so as a business, and I'm pulling together a whole series on security architecture, and I don't know how that whole thing is probably a little too high and left for this particular thing.
I don't know that that would solve this problem necessarily, but just the whole look at. What are we using? How are we using? What's the tech stack? What's the flow? Where's the data? Who has access? What are the auths? I mean, that whole view, I think we need to do a much better job at. And I think we've an application
Francesco Cipollone: is more than a storm and a piece of stuff around somewhere.
Sean Martin: Yeah. So I think we're, we're doing a good job from the bottom up. I think, I think we all need to take a closer look at our top down. This is my takeaway on this, but, uh, it's always, always a pleasure, [00:39:00] my friend. Any, any final thoughts as we wrap up
Francesco Cipollone: here? I think you've wrapped up perfectly with. That would have been my recommendation.
Looking at a broader spectrum, what it is, what is an application, start defining what is an application just because it doesn't have code. It doesn't mean that the one process credit card data, one process PII or your customer data, or it wouldn't have an impact on your business overall. Maybe looking at your PR response, so getting a PR ready response for security incident and doing a triage on those incident, I think, looking broader and trying to 2023 trying to delegate to machines, the.
job of triaging so we can focus on the really important work of security professional to actually run threat modeling, to run this intelligence work that machines will never be able to replace us to do because it requires inference and intelligence view that [00:40:00] hopefully, maybe in the future, we can automate some of this stuff with the threat modeling and automated threat modeling and some of my good friends of writing.
But, uh, human are good in that, while machines are much better at prioritizing vulnerabilities. So let machines do that so that we can focus on really looking at the business overall and securing the business, not focusing on securing the individual vulnerability.
Sean Martin: We, we mustn't be afraid of technology to help us where, where it's.
Appropriate. And, uh, continue to continue to tap in the most powerful machine. Yes, it'll look at all human brain, at least for the moment. Uh, Francesco, pleasure to have you on. Good to see you, my friend. And, uh, We'll certainly continue to chat about these things. And for everybody listening, please, uh, please subscribe, share with your friends and your peers and your enemies, whomever, uh, [00:41:00] needs to hear this message.
And of course we'll link to marketing people. That's right. Absolutely. The marketing people. Good point, Francesco, and I'll include links to your profile so they can connect with you and links to, uh. The LinkedIn post that prompted this conversation and uh, you'll have a chance Francesco to share anything else you think is important to uh, help people understand this a little bit better and uh, take, take some steps, even if it's just thinking a bit more about what they have going on.
So thanks everybody for listening and watching. Thanks Francesco. We'll uh, see everybody on the next one.
Francesco Cipollone: Thank you Sean. See ya and stay safe out there. You too.