Justin Rende of Rhymetec

Alright. Welcome back to another episode of Modern Cyber. To our regular listeners, I hope you've been enjoying our recent breach series and people sharing their experiences from the worst breaches that they've ever experienced that they're willing to talk about. We're gonna take a break from the breach series this week to bring you an episode where we talk about something that is super relevant to the modern Internet. That is being proactive in cybersecurity as opposed to reactive, but also a second topic that I think is super relevant for any organization that is kind of a modern company.

Meaning that you're building your IT stack really in line with the cloud and where things are moving today. We're gonna talk about SaaS security and by that there's a lot so we're gonna unpack that as we get into it. My guest today is somebody who's been in the cybersecurity space for quite a while. I'm joined today by Justin Rende, founder and CEO of Rhymetec, a cybersecurity firm providing cybersecurity compliance and data privacy needs to SaaS companies. With more than twenty years of experience in cybersecurity, Justin has focused exclusively on developing the most innovative and customizable solutions for modern SaaS based companies.

Since founding the company in 2015, Justin has led Remedix growth to more than 35 full time employees without outsourcing any of its services. We wanna talk about outsourcing some in today's episode as well and has served more than a thousand clients ranging from startups to large enterprises. Rhymetec is now celebrating ten years of innovation. The company has managed more than 1,200 audits, completed 900 pen tests, and I'm sure there's a lot more that goes into it. But a lot of the things that I think are really important to understand is the company's been recognized as a finalist in the cybersecurity awards, one hot company in SaaS and cloud security at the eleventh annual global InfoSec Awards at RSA c, RSA conference coming up soon, and earned the title of disruptor company in cybersecurity services.

Justin, that is a lot. I don't know where you find the time, but I guess over ten years, a lot of stuff can get done. Thank you so much for finding the time to join us on Modern Cyber. Thank you, Jeremy. I'm happy to be here.

Awesome. Well, let's dive in. Let's talk about a couple of the things that we kind of mentioned in the intro. And and I know there's a topic that's kind of near and dear to your heart, and that is kind of the topic of being proactive as opposed to reactive. And I think this is a really serious consideration, and it's kind of funny.

You know, CISA for a long time has talked about secure by design. I I wonder if you see being proactive as being kind of a a building block of being secured by design, or what what in your mind goes into being proactive about cybersecurity? I think building security into your product or your solutions from the ground up is something that would is how I would really define being proactive in security. We find that there's it's pretty clear with our customers. There's customers that come to us early on, and they want us to build it into their infrastructure, build it into their application, build it into their security so they know that they don't have to go back and retroactively do that, which will end up costing them them more money.

And then there's other customers who really just focus on getting their product built and out out to market, and then sometimes they'll come back later on and put security into that, which ends up being quite a bit more costly to do it that way. Yeah. And it's really ironic because just as you say, it ends up being a lot more expensive to bolt it on after the fact as opposed to building it in at the beginning. So I'm curious, like, aside from the, let's say, the mantra break things and launch quickly, blah blah blah, why do you find that so many organizations end up going the route of bolting security on afterwards as opposed to building it into the design? I think there's a couple of things.

I think right off the bat, they don't see a clear return on the investment. So it's not always cheap to build security into your program from the start up. So if they don't see that there's going to be a direct return on the investment, that they're spending on that or a clear return ROI on that, a lot of times, they'll put that off so they can focus on just the development of their application or program, later on, and then they can go to market with that. And then they can once they have a little bit more money or a little bit bigger of a customer base or a little bit more funding, then they would think, okay. At this point in time, I'm gonna go back and then build security into my, into my application or into my organization at that point in time because I have more funding to be able to do that.

So a lot of times, I think it's it's really just the direct return on the investment is why Yeah. People don't do it right off the bat. Do you think there's also an awareness or a mindset gap around it? Yeah. I think, yeah, there's a for sure a mindset gap around it.

I think a lot of CEOs, specifically of startups, they don't really have a full understanding of the security industry, and so they don't really know where to start. So they don't really know how to anticipate for threats or really what they should be doing to really start off to even build a cybersecurity program. So I think it's really those two things. It's it's really a financial thing where they're not seeing the direct return of investment. And the other piece is just like, we don't know really how to start this.

Yeah. Yeah. And and, like, a lot of the companies that you work with, are they when you engage with them, what stage are they typically at? Are they typically at a, you know, launching the the SaaS platform or our SaaS is already generating revenue or or let's say SaaS is already generating millions and they're looking for security as a thing that can help them, you know, not get blocked from going from millions to tens of millions? Or what what kind of phase typically?

It's really honestly, we work with a lot of different startups, and it's it's it's there's not one bright answer, I would say. There's it's across the board. We see customers that are at every different stage of of this. And and in terms of their funding and everything, we see customers that wanna do this early on and customers that wait until they have more money. So it's it's across the board, it's just different.

And do you see a different in those different phases in terms of how, let's say, security aware the software developers are, like, in terms of understanding some of the controls. Because one of the things that I've I've talked a lot about recently in some of the talks that I've done at, let's say, like Black Hat and so on, is around, first party risk versus third party risk. And if you think of first party risk as being kind of everything that's within your control, you know, you own the piece of software that you're providing. Right? So if it's a software as a service, you own the platform.

You own the infrastructure security of that platform. You also own the security of the piece of software that you're building yourselves. And one of the big questions that I see and I have a an open question in my mind about is, do most software developers understand the importance of some of the, let's call them, non sexy security basics, like making sure that every input is validated and sanitized and every, response payload is also validated if you're making API calls and a lot of the things that are kind of like necessary and they're good security hygiene in the software sense but I don't know if software developers really understand the importance of these things. I find that they really don't understand the importance of them until there's some sort of security resource within the organization that kinda pushes this on them. And so, really, they're looking to the developers are just looking to build and go to market.

That's their their job. And once they have once, again, a a range of it across when they actually bring in the security resource to do that. But once there's a security resource and within the organization, be it a a full time resource or someone like a medic, which will come in and build and manage the program for you. At that point in time, we'll start to help them identify, why they need to do that. And I think that that happens as as companies mature and they get higher more more talent, I think, and and and they have more employees, there's there's more resources behind that to kind of push security.

Yeah. And when they start down that process, how do you see that process typically working? Does it start with kind of a security audit and a, you know, here's all the things that you guys are messing up on right now, or does it start with kind of a more general, like, hey. This is why secure by design is important and what you should start thinking about? We typically find that it starts because of sales, and and it is the unlocker to a lot of security, unfortunately.

Customers we work with a lot of customers that have built application and ingest, the ingest end user data. And in order for them to be able to do that, they have to hit in certain compliance metrics or security metrics in order to do that. And so a lot of times early on, we find that in order for them to go to market or for them to get their series b funding or whatever it is that they need to do, they have to become SOC two compliant or ISO twenty seven zero zero one compliant. And so those are typically kind of the sort of reasons for for pushing it early on. And it's interesting because, you know, there's there's a thing that I I you know, I'm sure, like you, I've spent a long time in security.

And one of the things that always comes up is that, like, we those of us who are in security, we often talk about security as being an enabling function. Right? We help the organization move forward. And what you just said is is the classic example. Right?

We can get more sales because we are tackling the security problem that we have. Right? It there's no clearer kind of path towards, quote, unquote, enabling the business than that. And yet I still find that most of the time or very often there's kind of a friction between security and development in terms of, like, who's responsible for what and, you know, we we're responsible for code, not secure code. We're responsible for code.

You guys are responsible for security. How do you talk to organizations about that friction or about that, you know, let's say, like, the positive ROI and understanding the the enablement aspect? Really, I think it's about getting getting ahead of it. Right? So, like I just said, a lot of times, sales is kind of what's security is enabling sales, but a lot of times, the request to become more secure doesn't come internally.

It's coming from the customer saying, hey. You need to do this in order for me to purchase your purchase your product. And so a lot of times, it's it's not the organization being proactive about it and trying to get ahead of it. It's them waiting until their customers are forcing this on them. And then when their customers are kind of forcing this on them is when they move forward with it.

Okay. And but when you're at that point, when the customers are forcing them on them and you were engaging with the organization, what are talk us through some of the, like, initial steps of engagement. What does that look like? Does it look like a a security awareness seminar? Does it look like a, you know, software development security best practices kind of education?

Does it look like a here's the road map to getting you to SOC two? What does that typically look like? Compliance to our our our programs typically start with compliance. Right? So everything is starting with, some level of compliance, and then we're building the program off of that.

And so, typically, it's some sort of gap assessment to say, okay. If you you wanna become SOC two compliant or we recommend you become SOC two compliant or your customers want you to be SOC two compliant, here's what that's gonna look like in order for us to get you there. And so it's really building that road map out to show them what it's gonna take and and talk about investment and and resources that you need to put into it. On top of that, I always find that doing a risk assessment right off the bat is one of the best things for any organization to do because they can identify once you've been able to identify risk, then you can also push it's it's an it it's easier to sell security on people when they understand the risk involved, and and a lot of our customers in the early stages have never done that, and so they don't understand the actual risk involved, to be able to want to make that investment to security. Gotcha.

Gotcha. Okay. So we've got a kind of a gap assessment, and then we've got a risk assessment. Those two things might be part of the same exercise or they're very closely coupled in many ways, etcetera. You go back to the business afterwards.

You kinda present the results on that. Where does that typically tend to lead to? And then it comes into conversations about budgets and resources and what we can put towards towards actually building this program for them. And then it's about implementing that program. And then once we've gotten them certified with whatever framework they're looking to do or we're looking to do with them, then it's real about understanding that that's just the baseline of your program.

And now we're we're we're able to really build off of this based upon the actual risk assessment that we created where the actual risks are within your organization. We can put more time, effort, controls into making your business more secure after we've made you compliant. Gotcha. And and kind of, like, during that process, are there particular types of, let's say, like, employee education or educational, let's say, presentations that go on there? Because I can think of a lot.

Right? You know, if it's built off of compliance, you know, a big part of that is, well, what is SOC two and what what are the things that SOC two is looking to check? Or when it comes back to, like, oh, okay. We've got we've done a a gap assessment. And as part of that, we've done a pen test and we've uncovered, like, these 10 software vulnerabilities.

Well, now we need to do some education to the developers about, like, how do these things get introduced, or how do we actually, like, redo the code to get them out. Talk to us through, like, kind of the educational component that goes into this. Yeah. So I think as it relates to, like, vulnerabilities, we typically don't actually go back and educate engineers on how to rebuild something Okay. From the ground up because that's just a lot of time, and it it's more about just remediating that.

So we're gonna work with these engineers on remediating any vulnerabilities that they have so that they're not gonna be a problem moving forward rather than kind of going back and retroactively saying, okay. We need to rebuild this from the ground up, and and do it in a more secure way. That would, again, be the smart thing to do if we were being proactive about security. But a lot of times, if we're not, it's it's about trying to just mitigate that risk where it's at and make sure that it's no longer a problem moving forward for for the organization. So it's it's it's it's about, yes, a high level education about how these risks kind of came to be, but it's it's it's yeah.

It it's that's what we're talking to the customers about is, like, this is how you got this and this is how we're gonna fix this moving forward rather than kind of thinking, okay. We need to start from ground zero all over again. Gotcha. Gotcha. And on the compliance side, do you find that, like, you know, we're SOC two certified.

We've gone through, I think, two years of renewal already. We decided as a company to do it in our very first year of existence to kind of build a lot of our operational practices off of that. And one of the things that was even for me as somebody who's been in the space for a while was kind of an, eye opening lesson was, a lot of it is about process and just process documentation and let's say consistency of process. You know, you might have a process that's not super optimized, but if you've got a documented process and you follow it and you're consistent with it, like, that can be good enough for many things. Do you find that organizations, as they engage with you, they don't understand the operational side of things?

You know, there's the security controls, obviously, that you're gonna help them with. But let's say, like, the the how do we operate as a business piece of it, I find to be, let's say, often overlooked. 100%. So you can the controls are easy. Right?

We can turn two factor authentication on, and it's turned on, and everyone's forced to use it, and it's it's taken care of. But it's about changing people's habits and behaviors, moving forward, which is the hard piece of it. And that kind of goes back to a a piece of education where it's it's less about, like, retroactively, how do we do this again from the ground up? But, like, how do we train everyone to be secure moving forward? So thinking about, where the risks are and then customizing training for certain groups of employees where these risks are associated with their roles within the organization, customized training for them specifically so that they understand how to not how to become more secure as they as they continue to grow and they continue to build their product or service.

Yeah. And, I mean, it's interesting because you what you mentioned there, it's like thinking about how to maintain those guidelines as you grow is often one of the most challenging things. And it's it's one of those things that as, like, as you grow to your point, like, we had, an issue a little while ago where we were like, oh, well, we need to solve something. Maybe, actually, the quickest way is to just bring in somebody else who's gonna go come help us. And there was a particular environment that we were looking at, and we that environment was quite restricted.

It was part of a production environment, and we had a question that we had to ask ourselves. How are we gonna solve this? The easy way is to let this other person into the environment, but then that actually falls outside the guidelines of our current procedures. Do we, a, modify our procedures to allow the quick and easy response, or do we figure out, you know, okay. Well, actually, the other way to do it is to do a a quick data export and to take that data elsewhere, and we've got a documented process for that.

And I think that, like, that temptation and that balancing act can be pretty hard for organizations to straddle as they grow. I think that a big piece of that and understanding how to how to resolve that would be understanding the risk that's involved. Right? So if to remediate the the issue that you're having, if the if if to bring in a third party to be able to do that and to change your process in order to do that quick and effectively because it's a large risk and you need to get it remediated fast, and the fastest way to do that is to bring in someone else to do that, and you have to change your procedure to do that, then I would say, yes. That's the right direction to go.

I think it's all about analyzing that risk that's involved with that actual vulnerability that was uncovered. If it if it's something that's low risk, and you can you could potentially change that in house, but it may take longer time to do that or there's no downtime or there's more downtime, then, yeah, you can you can essentially keep that in house. It's it's really about what is that risk, how critical is that risk to your organization still moving forward, and do we need to take the kind of slow and internal approach, or do we just wanna bring someone in quickly to fix this and and then keep moving forward? Gotcha. Gotcha.

And for companies that I know you mentioned that your typical kind of customer profile, while the stage of development might vary widely, but these are mostly companies that are offering software as a service. Right? Yeah. So I would say most of our customers are SaaS companies that are offering some sort of solution where they're ingesting either other companies or end user, data. Gotcha.

Gotcha. And do you find that SOC two is really the most widely accepted framework that these organizations are going after? In The US, yes. It is. I would say it's it's primarily the kind of baseline standard for any sort of company in The US to establish Okay.

If you're a SaaS based company. When you're in Europe, that's ISO twenty seven zero zero one. There's less SOC two there. And so, really, it it there's a lot of different depending on the region that you're based on. And, again, I think that comes mainly from customers.

Customers in The US are requesting that you're SOC two compliant. Customers in The US are requesting that you're ISO compliant in order to move forward. So that's kind of the reason for the different frameworks within the regions. Gotcha. Gotcha.

And, I mean, these are mostly overlapping frameworks, though. Right? I think if I remember right, and we do SOC two, but we've looked at ISO. And I think when we looked at it, from a controls perspective, we didn't see a whole lot of variance. But, you know, there's probably more on the procedure side that I'm not thinking about.

For sure. So there's a lot of overlap between most all the specifically to controls, right, like, there's only so many controls you can implement within your environment to make sure that you're secure. So, at a very high level, how I always describe ASO versus SOC is SOC two, again, baseline. Think your two factor, your encryption, all of these these things are gonna be turned on. You these controls are gonna be turned on.

There are some procedural controls, policies, things like that need to be put in place. ISO twenty seven zero zero one has all of those controls as well, but it's largely based around risk and remediation and then and then tracking the progress of remediation over time. So I think about it as, like, SOC two is really control based, and and then ISO is really gonna be much more of a of a way of you thinking about building an actual InfoSec program within your organization. Okay. Okay.

And the other thing that I wonder about it is, like, do you see that there is going to be any kind of, like, additional frameworks popping up in other parts of the world, or do you think that, like, these two standards are pretty much the ones that are gonna be dominant? No. It's constantly evolving and changing. I mean, there's especially depending on whether CMMC, there's all kinds of Dora. There's all kinds of new frameworks that are popping up that are starting to, frankly, they're actually better because they have more have more sophisticated controls and more sophisticated procedures around them.

But I don't see SOC two and ISO as kind of being the end all, be all for everything. It's it's really, as I mentioned before, kind of the baseline for everything. So, most customers, we recommend depending on their environment, we recommend SOC two as the first thing you do. And then we recommend that one SOC two is done, if you wanna really go through then ISO twenty seven zero zero one, because, again, you're building more of a program then. And then depending on what kind of a data you're ingesting, there could be other frameworks that we need to implement, based upon the type of data that you're you collect.

Gotcha. Gotcha. And and I guess one question that comes to mind is, like, I know a lot of organizations, and I saw a recent thread on LinkedIn where people were kind of debating this with regards to a lot of the modern, quote, unquote, let's call them, like, compliance automation platforms. One of the things that kind of was discussed on there is that a way that some organizations have approached this is it's a check the box exercise. And if you just need to get through the process in order to enable sales, one of the things you do is you just mark a bunch of stuff out of scope for whatever reason, and you get through it, and you move on with life.

How do you kind of react to that? And then also, how do you kind of talk to your customers about making sure that this isn't just a check the box exercise that doesn't actually improve their security? So we do see a lot of customers or I would say prospects come into organiz into Rhymetec, that are looking for that, a check the box solution so that they can just get through this and they can go to their customers. We don't really wanna engage with those customers, to be honest with you. I said, we wanna build scalable, secure programs for our customers that are gonna grow with the company.

And if you're just looking to just get a box checked, then and and do that as cheap and and as as ineffective as possible just to see if we can get it done, That's not the right customer base for us. We care about our customers, and we care about this what we build, and so we're not a box checking company. There are companies out there that do enable you to do that just to check the box so that you can grow. But then it kinda goes back to what we were talking about when we first started the the it's like, okay. You're gonna have to go back and retroactively do this right.

And so you might as well just think about it from the start and do it make the time time and investment from the ground up so that it's cheaper and you build the scalable product from the ground up, rather than going back and retroactively doing it. Even though you have your SOC two, if you just marked everything out of scope to get the certificate, you still don't have a secure product. Yeah. And do you have any particular sense of messaging on how you would talk to the organization about that to say, like, you know, look, a, we're not gonna work with you because we don't think that you're a good fit for what we're trying to accomplish here and the kind of success that we're trying to bring to our customers. But let's say more importantly for like a security leader within an organization where they're getting internal pressure to just go the check the box route, but they know that they actually wanna do it right.

Like, how do you talk to them about, let's say, trying to convince the rest of the organization to to do it the right way? I think you just point out the risks. Right? I think whenever we conduct a risk assessment for a customer, and and then we can quantify the money that they could lose, potentially, if if there were to be breached or if there were to be a security incident or or after we've identified where this could potentially happen, then it's easier for that individual specifically if they come from a security background within the organization to kind of filter that up the chain and try to do things right. But if you just come at them and say, hey.

We're not gonna check the box for you. That's not the right solution for us. Then they will probably just move on to someone else that will do that for them. But, really, it's about educating the customer on why why you need to do this and why you need to make that investment from the from the ground up. And sometimes it doesn't work out.

Right? Some companies just don't care. Sometimes companies are like, you know what? We just we'll worry about this when we have our series b or our series c. This is something we'll worry about down the line.

And and, again, I'm not here to lecture them or tell them you should do things that you can do whatever you want with your organization, but I'm not going to typically wanna work with those customers because that also exposes us to a risk as their security vendor as being the people that build and manage their program for them if they have a breach, then that's a reflection of the work that we did. And so if our work is being hampered by companies not wanting to invest in security, which, again, I'm not asking for, like, a huge investment, but just like a normal investment in security, then it's not the right fit for us. Got it. Got it. And, when you think about kind of talking to, SaaS companies, which I know is the majority of your customer base, You know, there there I was at a recent event where, it was with a very large financial services institution.

One of the things that they pointed out is that one of the biggest attack surfaces that they now see is all of the SaaS vendors that the organization uses and all of their data that's shared across, you know, fifteen, twenty, or in their case, it's probably north of a hundred SaaS companies that they work with. And they said, actually, like, for from an attacker's perspective, what that means is that, you know, an attacker really needs to go after the top hundred SaaS organizations in the world, and then they get access to thousands of organizations' data. How do you talk to SaaS organizations about, like, taking very, very seriously the responsibility of their customer trust in their data? And then how do you tell them to think about, like, you know, kind of some some of what you just said, the risk exposure that they have? I mean, because a lot of these could be, you know, company ending type of incidents if they if they were to happen.

Yeah. I mean, I think you could just think about some of the recent security incidents we have. Think about the CrowdStrike one with Microsoft that took down so many different vendors at so many different companies. So, you think about when when companies or SaaS companies are bringing on other SaaS vendors to build and and manage their product, we we can we at Rhymetec do continual sort of vendor reviews to make sure that the security, the these vendors that you're bringing on to either transmit or store your end your customer's end user data are gonna be security worthy. And we'll do that before we allow you to bring on the vendor, and then we continually go back every three months and that vendor to make sure nothing has changed.

But it's it's all about not just thinking about, okay, my own product is secure. It's thinking about all the vendors that you bring in to build and and to host your product, making sure that they're also secure because that's a bigger attack vector than actually just attacking some of these small SaaS companies. Yeah. Makes sense. And and when you think about for these smaller SaaS companies, you think about kind of, let's say, like, data privacy and data privacy standards.

This is an area that I've also struggled with a little bit myself because, you know, we, we've got a lot of our r and d over in Europe. We tend to operate according to GDPR principles, and and we just kinda made the decision early on that we would just operate the whole company worldwide on the back of some of those principles. But what that means is is, you know, if I want to first of all, it's I think people don't realize that there's no real GDPR audit or certification that you can get. And so that's kind of hard to navigate. I guess a few questions.

One is, what's your take on GDPR and then kind of, let's say, the looser framework of standard slash guidelines that it does and sort of doesn't exist elsewhere in the world? And two is, like, how do you talk to customers about that? So I think if you're looking to expand, internationally or if you're looking to host any data, frankly, in Europe, right, GDPR is gonna be a thing for you to think about. But outside of just GDPR, there's things within The United like CCPA, if you have customers in in California. Each and and we're starting to see that more and more states have different sort of data privacy regulations that they're enacting.

So as as a way to kind of manage all of that and keep safe across the board, we kind of recommend which which is something that you just said you you guys did, which is kind of hold that GDPR standard across the board for for your organization. There is not gonna be an audit for it. But as data privacy regulations change and evolve and as there's no sort of, like, streamlined governance, at least here in The US, for for all data privacy and it's kind of state by state, If if you adhere to those sort of GDPR standards, at least you're you're you're you're putting forth best efforts for data privacy, and you're trying to standardize what, on something that will hopefully kind of overreach above what all the states' regulations are. So it's kind of like a you can think of it as a as a baseline standard, but it's a baseline standard that is higher than anything that's required in The US right now. And so if you kinda hold to that, you're gonna be pretty well prepared.

And I think it's also fair to say that, you know, the history of GDPR shows that it will advance faster than any requirements here in The US will. Correct. Yes. So it it's just it's a it's a smart business practice to implement GDPR. Again, even if you're not looking to hold or store or transmit data through Europe, it's smart to do it because there's different regulations per state here, and they're all starting to evolve.

And so it's kind of just like that gold standard to kind of or, I guess, the minimum standard to kind of adhere to when it comes to data privacy. Yeah. Well, we're coming close to time on the end of the episode, but I've got just a couple final questions I wanted to get through with you. One is if you think about this from the budgetary perspective. Right?

And you think about okay. We talked about enabling revenue growth, but how should organizations think about how much money to allocate towards processes like this? If they're, you know, if they are going through this process where they've grown to whatever point, they need to now grow the sales further. They need the security and maybe the SOC two and some of the stuff that goes along with it. How do you talk to them about, like, how to budget for this?

Really, again, it kinda goes back to, risks and anticipating risks. So I think there's there's a cost associated with compliance. So as I mentioned before, like, SOC two is kind of the foundational sort of security approach to to most businesses, and there's a cost associated with implementing that. The cost for SOC two has gone way down over the years with the implementation of a lot of different, of these automation platforms, and there's a lot of different ways. And there's just more of it out there, so it's it's it's the industry's lowered the cost.

So there's kind of a standard cost for SOC two. And then, again, understanding the risks within the organization so that you can put remediated controls, policies, procedures, all of those things to remediate that after you've identified where the actual risks are and then putting a cost associated with that. So, if you need to implement intrusion detection, what are some of the systems that we can we can do we can use to do that? What are the costs associated with that? Because that was a huge risk that we identified in your risk assessment.

So, really, it's about understanding where the risks are and then putting a cost associated with remediating them. Gotcha. Gotcha. And across your own experience in the, you know, roughly thousand customers that you've worked with over the last ten plus years, what are some of the common threads that you've seen or some of the common mistakes that if anybody's who who's hearing this right now is an up and coming SaaS vendor and and they're like, yeah. I know this is gonna be on my radar soon.

What would be some of the most common things that you would say, like, check yourself for the following things that we end up seeing time and again? Vendor management, kind of going back to what we said before, which is like, even though you've made your platform secure, do you know that all your vendors are secure? That's something where there's a large attack vent vector for a lot of these vendors, and people don't think about that. And that's often overlooked, so pay attention to that. Employee education.

So not necessarily educating them on how to develop things from from the ground up, up, but, how to identify a phishing email. It's a lot easier for attackers to, I always say, hack a human than it is to hack a hack a machine. And so people often forget that, like, one of their biggest risks in any organization is is is their employees. And so not only just teaching them on data privacy practices and how to keep HIPAA data within HIPAA related applications and not post that in Slack or something like that. That's a security instance, so teaching employees about stuff like that as well as teaching them how to, understand, what's coming at them.

So how to identify a phishing email, how to identify, if if something's weird on their computer, how to identify stuff like that is something that people often overlook because they're so focused on really just implementing controls and less about employee education. Gotcha. Gotcha. Well, Justin, Randy, it's been a real pleasure having you on Modern Cyber. For anybody who wants to learn more about you or your company or your work, what's the best place for them to go?

I would say just go to, Rhymetec.com, or you could, you could connect with me on LinkedIn. Okay. And we'll have the links to both Justin's LinkedIn as well as to the company, Rhymetec, spelled r h y m e t e c, in today's show notes. Justin, thank you so much for taking the time to join us on modern cyber. Thank you, Jeremy.

It was great to be here. Awesome. And for those who are listening, please remember, keep in touch. We release every Thursday. Our brief series is ongoing.

It'll be kinda interspersed with the mainline, episodes as we go over the next couple of months here. And if you know somebody who should come on the show, please tell them to reach out. Rate, review, subscribe, all that good stuff. We'll talk to you next time on Modern Cyber. Bye bye.