Coach Mike: Startup Data & Cyber Security

Welcome everybody to another episode of the Founder Insights Podcast. My name is Dustin Betts. I'm the head of content at the Founder Institute, and I'm joined today in our studio by Mike Supravici.

Hello everyone. As Dustin mentioned, my name is Mike, and for those of you who don't know me, I lead the Alumni Success Group at the Founder Institute, and our role is to help the 4,000 Founders Institute alumni scale, and we try to do that in any way that we can, whether it's through one-on-one office hours and advice, through structured programs such as our funding lab program and so on. So we basically kind of roll up our sleeves and help everyone as much as we can. So that's, that's me.

And we're also joined today by our special guest, Neil Michie of VeraMatrix. Neil, do you want to say a little on yourself?

Hi Dustin, hi everyone. Yeah, I'm Neil Meekie. I'm one of the product managers at VeriMatrix, and I look after our products that focus on code protection. What we're doing is securing applications running in insecure environments like mobile phones, mobile devices, to make sure the software and the IP within the software is secure and safe.

Yeah, and so our topic for today is startup data and cybersecurity as it relates to startups. So, Neil, yeah, your background very well suited to be our special guest for today. And I think we kind of want to kick it off by just defining, for those who haven't thought about it much, how do you define security in the cybersecurity space?

When I define security, what I mean is how do you keep your business safe? How do you keep your customers safe and your business safe? Because the reason for implementing security, the reason for looking after security, is fundamentally about keeping what you care about safe. When we're talking startups, when we're talking businesses, what we care about is our business.

Yeah, and so, I mean, the data, I guess, that businesses hold is increasingly, you know, one of their most important assets. What is it basically that we're defending against? You know, what do hackers really want to go after, I guess?

You're right, data is something we need to care about, is something we need to— we really need to focus on. There's lots of interesting things in our businesses and our what we're doing that is kind of hackers care about, hackers go after, but kind of fundamentally what we see is increasingly hackers are looking after data. And if your business is B2C, if you're working in that space, then you're dealing with a lot of customer data, and customer data which is personal data. And that personal data increasingly is governed by things like GDPR in the European Union and equivalent legislation is appearing around the world. It looks like California is enacting some of the toughest privacy legislation in the world at the moment. And when you're in this space, you're dealing with customers, with kind of real people, kind of what you see in this legislation. As a business, you consider it your data. In reality, it's the customer's data and they're just loaning it to you. So you have a responsibility to keep it safe, and if you're feeling that responsibility, then this legislation is here to protect the consumers, to protect our customers as a state. So we need to make sure we're doing that. And yeah, the hackers, the bad guys, want this data. They see a lot of value in it. There's figures that show that credit card data sells on average for $30 on the dark web. Health records are the most valuable data at the moment. Hackers are taking hundreds if not thousands of dollars for medical records on the dark web. So The motivation is clear. It's monetary. There's a financial incentive to get hold of this sensitive data and then sell it on. So that's what hackers go after. And that's why when we're building businesses, when we're building products, we need to make sure that we're securing that data and keeping it safe.

Yeah, 100%. And let's say you're a founder and maybe you agree, or even if you disagree with the moral argument beside about data and things like that, security, you have to take a look at this and take this serious because one breach could put you out of business, more or less. If you're not taking the right precautions and you don't have a lot of resources to defend yourself against those, it's very, very critical that you stay— they try to stay safe. So definitely something worth thinking about as you build your business.

Mm-hmm.

Yeah, and I like kind of the way that you divided up at least the two sectors that you talked about for customer data, right? So one is sort of credit card information which I think is the form of fraud probably on the internet that most consumers are most familiar with. But then there's also, yeah, the emerging kind of more and more health records basically coming online and different kinds of devices that might be gathering information on your health or, you know, other vital signs that, yeah, they could be sold or compromised by hackers. And that's worthwhile for founders to be thinking about. In the early stages of developing those products if they're going to be collecting that kind of data. So I think we want to kind of ask about, you know, how can we de-risk it? You know, what are some ways focusing maybe on customer data, you know, that founders can be thinking about keeping this data safe for their users?

Yeah, de-risking, it's exactly the right word. You're never going to get 100% security because it doesn't exist. And if anyone tells you they're providing 100% security, I would recommend running a mile because it's They're either naive or they're lying. But we do need to take steps, we do need to take precautions, and I believe very strongly it's about taking practical steps, practical precautions. It's not trying to get the very best security you possibly can and kind of making sure everything is locked down, because that just doesn't make good business sense. You can spend a lot of time and a lot of money building very, very good security, but ultimately we need to make business decisions. And just as the hackers are looking for a return of investment, so are we. We need to make sure that our businesses grow and our businesses kind of make sensible suggestions and correctly de-risk the market, but kind of is about de-risking it. So I think in terms of what our startups, what our, our founders should be looking at is what are sensible practical measures they can take today, doing the right things, doing them correctly. And that really means understanding the assets that like your processing, understanding what data you have. We're talking a lot about data, but assets are often other things as well. So there's maybe IP that we're putting out into the wild. If that's valuable, then that needs to be protected. The example I use quite often is in the games industry, and if you look at revenue for games, they can make a lot of money on a daily basis, but as soon as players work out how to cheat in those games, they work out how to how to give themselves an unfair advantage, then suddenly the game stops being fun and players go elsewhere. So it's important to protect the concept of fair play within video gaming titles. And you see that similar mindset, similar idea spreading kind of across different industries, across different products, that what's an asset, what's a security-critical asset, is not always a piece of data or something firm you can put your fingers on, but it becomes a concept, something more fundamental to what you're doing that also needs to be protected. So we need to make sure when we're looking at the assets, looking at what we're protecting, that we're, we're really thinking about the whole product and where the value is within that product. It's often not just, as I say, one bit of data, but there's something about what you're doing as a product. Like a game is the concept of fair play that actually is where the value is, and We need to protect it. So that's the first thing to do when you want to look at risking is look at where the value is, look at what the assets are that you have within your products, and then think about what the sensible steps are to take. Look at where the assets are going, where they are, how someone might get hold of those assets, and then work out how to build and protect around them. But do it in a sensible, practical way. There's lots of other things to do when you're building a business. So we don't want to spend all our time on security, but we do need to take the sensible practical steps that enable us to really protect these assets within our products.

Yeah, I'd love to double-click on this point that you just made here. So essentially, we can go to infinity to try to work to get the best absolute security. And even then we may not get to 100%, we might get to 99.9999% or something like that, but it might not be Ever. So when a founder thinks about this, or even an employee at a startup that's scaling, how do they balance what can be done and the amount of work that's— what's necessary for the business? You know, from your experiences, is there kind of like a framework for how to think about this, or some sort of a mental model that you may have that we can share with our community about this?

There's lots of frameworks out there if you work with security labs or you kind of, you understand the security methodology and dive into that. There's lots of frameworks people put together to understand risk, to understand how you protect it, kind of how you build systems around them. They generally fundamentally work on the theory of identify your assets, identify the attack vectors of how someone would get to those assets, and then look at what perimeters you build on those assets, what protection you need to keep those assets safe. I think that I would almost argue that the most important thing when you're, when you're starting up is don't get in the mindset of I'm small, I'm not known, the attackers aren't interested in me, because that's fundamentally not true. You see it in lots of different mindsets of where criminals will pick on maybe the vulnerable, maybe those that aren't quite as aware, kind of more naive, or you may maybe see that kind of criminals will go after where they see the best return. That's not always looking for the billion-dollar return, but if they can very quickly get a small return but do that easily, then lots of small returns quickly multiplies up. So kind of don't think just because it's small it won't happen to me. But I think what's even, even more important is if you're starting up, you founded a company, you're getting going, you want your product to explode. You want to kind of hit the mass market, suddenly go from being kind of startup mode to being international kind of unicorn billion-dollar company. And when that, that point comes, when you hit this hockey stick and it really starts to grow, you become known. At that time, do you want to spend your, your efforts, spend your cycles on retrofitting security? Because now you're known and now kind of every attacker and his dog is interested in what you're doing, or do you want to spend your cycles focusing on capitalizing on your newly found success? I would argue you want to spend your time building your business and focusing on increasing the success you've just found. So it's much easier to have security built in as business as usual when you're starting the company, starting to build out the products, and get that mindset within your organization, because it's easier. It's not that much effort to do it at the start. And if you have to retrofit it later, it's, it's very damaging and very disruptive. It's just like any other process you build into your engineering team. If you get the processes right at the start, then you're in a good position to grow, whether that's you're getting an agile methodology through your development team, having the right tools for that, It's exactly the same with security. If you can build it into the mindset at the start, then it's just something that happens. It's something that's business as usual. And then you don't have to worry about it later because you're doing the right things from day one.

We definitely want to identify these things that founders can think early on that will pay dividends for not having to think about them later. And one kind of question, I guess related, would be consumer data again. The trend is for more and more things to be moving towards the cloud. I guess if my customer data is stored in the cloud, which I think is something that startups are thinking about early on, this is probably like a consideration if they're looking at, they get some Amazon Web Service credits or something like that and they're building kind of their backend. Are there special considerations that founders need to think about early on in cloud storage specifically?

I think cloud storage gets a— or cloud generally gets a bad rep in terms of security. There's cloud services like Amazon, like Azure, are very powerful, they're very useful, they allow you to scale your business in a way that works for the businesses rather than having to invest in vast amounts of IT equipment very early. Even big businesses are increasingly moving towards cloud because it's just a nice way of doing things, it works well. Definitely people were nervous about it to start with around security. They didn't understand where their data was going, they didn't understand how to really manage that model or what the new risks were that came out of that model. And in reality, the same as any other IT infrastructure, you've got to make sure it's configured correctly, you've got to make sure that you've built the right processes, the right monitoring, and everything else. And once you've done that, it can be as secure as any other IT infrastructure you're building. And that's why you see some of the more forward-thinking banks are now moving towards that kind of infrastructure where they're moving what would previously have been unheard of or just unthinkable systems into cloud because people now understand the security models, they understand how to put that together. And provided you configure it properly, you you think it through, you understand kind of how it's got to be set up, then it's no different from any other infrastructure. So I think the advice I would give is don't fear it, and on the contrary, embrace it, but just do the research, make sure you, you have people with permanently within the organization, or just that you can call on and use that, that understand how to configure and set up these environments.

In addition to that, to just to piggyback on on Neil's comments there. If you're even earlier stage and you're just trying to hack together an MVP, okay, another way to look at this is let's say you're going to use some sort of a no-code tool to basically bring this together, or a set of no-code tools. A good way to look at this is to understand how the, the tool manages security, right? And putting that into like the consideration for what you're doing with regards to to that security, even if all it's doing is collecting the form online and putting it into a Google Doc. Well, that's a good place for you to start to think about this. Perhaps you put two-factor authentication on the Google Doc or something like that, or you put that onto the form if it's necessary, and then you can start to think that. So this is how it becomes kind of part of your culture. These are like basic things, and as you deal with more data and you have to manage more data, you can implement further and further security to deal with that.

Yeah, and I think, I think the point about two-factor authentication is quite a nice one. It nicely illustrates the, the need for securities to be applied in layers. It's a cliché, but it's a very true cliché. And something like two-factor authentication, it's great at managing the users kind of logging on to a service, making sure that you know who the user themselves is. It's only good for that if there's a security framework around it. And if the authentication can be worked around, whether it's two-factor, one-factor, or infinite-factor, then it does still open up risks. But you need to build these things in layers. You need to kind of make sure you're not just picking up buzzwords, picking up kind of some good ideas, but leaving gaps in what you're doing. You need to look at the ecosystem. You need to look at it holistically and understand kind of how these different components fit together to make sure you are building things in a secure way. It's all very well having users log in with two-factor authentication, but if you forget to lock down the Google Doc it's sending the data to, then what's the point?

Exactly. Also, just other parts of the business, if you start to kind of make this as part of your core principle for how you do your company, then you start to think about this like this with all other important assets of your business. For example, if you're using Mailchimp to go out and email your first subscribers or first users, you probably want to put two-factor authentication on the Mailchimp, right? That's how it becomes part of the culture, part of the DNA of the company at the very early stages. Then, therefore, as Neal alluded to earlier, that can grow. With your company and everything that you do and the culture of your business.

You know, we've talked a lot, I feel like concentrated most on customer data, but there's other kind of data vulnerabilities, I think. So I just at least want to touch on kind of some of them. And I mean, so one is, you know, your employee data. Presumably once you're hiring employees, you have personal information about them being stored somewhere. I think like another thing that's sort of maybe a little cliché, but what you hear about is like people are the weakest link cybersecurity or in security defenses. And so, I mean, another kind of vulnerability point might just be like your email that you're using. Are there sort of other things or other, you know, security vulnerabilities that come to mind that founders might just not be thinking about but they should be with regards to protecting all of their data?

Yeah, I love that phrase that people are the weakest link because in the same breath people also say that their employees are their strongest asset. So there's this lovely contradiction there. And yeah, people are the weak link in terms of security. People will do things you wish they wouldn't do. But when you actually step back and analyze why they're doing these things, generally it all comes down to convenience. People take whatever course of action is the most convenient to get to the, the end system, the end goal that they want to get to. So maybe if you're using— I don't know, you've locked down your mail system so that mail can only be used in secure company-approved mail clients, but someone needs to get a piece of data out of the mail system because someone's asked for someone's phone number, for example, and they need to send them the phone number. What happens if they just scribble on a piece of paper because that's the easiest way to get out and hand it to them? Suddenly all the security we've built failed because someone's found a convenient way of circumventing the system because I happen to walk to your desk and say, do you have John's phone number? And I just scribbled on a piece of paper, and now we've leaked that piece of data out of the IT system. So people will always find ways around security measures if it gives them a more convenient way to do it. So when we're building our internal systems, when we're building our kind of employee management systems and everything else that we want to give our employees to do, We need to understand that they will work in the most convenient way, and then we need to give them the tools to work in the way that they want to work. Once you do that, they will then follow the processes, they will follow the security measures, the systems that we've built in place, and they don't become the weakest link because we're allowing them to work the way that makes sense to them. It's a tough balance to get right. Instinctively want to lock things down, instinctively want to keep things tied away in terms of security, but actually within a company. We need to allow people to work, we need to allow them to flow data in the way they need to flow it, we need to allow them to do their job. And kind of when we're building our security model, when we're building our processes that we want to follow, we need to keep that in mind. And if we do that, people will still make mistakes, they'll still do things that we wish they wouldn't, but for the most of the time they will then work the way we're enabling them to work. And if we And if that happens, things stay secure.

One of the things that you and, and VeraMatrix specialize in is mobile, and I'd love to switch subjects a little bit more on mobile now because these mobile devices have a lot of sensors and they're like listening, they're doing a lot of different things, and these are things that founders should be aware of as they're building their application. Now certain ecosystems are better than others at it, or I shouldn't say better, they're just, they give people more control versus less control, and that plays a role in how this works. And, you know, maybe from your perspective, you know, what are some of the things that you've seen with regards to security? What are some like at-risk areas in particular with regards to mobile that are the most prominent from your experience as well as from some of the companies that you've worked with?

I think when it comes to mobile, what most people kind of— when you, when you fail to recognize, that's where risk comes in. But what most people fail to recognize is when they start extending their products, extending their services onto mobile devices, then they forget that they extend their, their ecosystem and they extend their security perimeter, rather, onto these devices as well. You then need to start thinking about how do we secure our extended perimeter. How do we protect what we've put onto our customers' mobile devices? Or maybe it's our employees' mobile devices and we're just giving them, giving them access to facilities to work from home or on the move. But the mobile device, or in particular the software running on the mobile device, becomes part of our ecosystem. It becomes part of our security perimeter, and we need to make sure that we can't attack the wider company or the wider data system through this new extended perimeter. An example which we often use, and we, we've got examples of attacks being done this way, where the mobile application is there, it gathers data, it allows customers to access services, and from accessing services on the mobile device, the application then connects into our cloud infrastructure, which we were talking about a minute ago. It connects into the cloud infrastructure, but because we consider the mobile application part of the infrastructure, we give it trusted access into the, into the cloud services. And then with trusted access, it can do things that maybe kind of you wouldn't want it to do or you wouldn't expect it to do. And what the attackers will do is take control of the mobile application or use the mobile application to learn how to give themselves trusted access into the backend systems, and then they'll pretend to be a mobile application connecting in, and from there you've opened up yourself to vulnerability. So it's very important when building applications, putting services onto mobile devices, that you consider it part of your ecosystem, you consider it part of your security model, and you then look, how do you harden the application, how do you protect that application so attackers can't take control of it to use it for their, their own malicious needs. Attackers can't take all the sensitive data we've been talking about straight out of the application. If it's running, the application is running on the phone, it's processing data, just attach to the process and take out the data. Or attackers will use the application as a learning tool. They'll learn how it's talking to the backend infrastructure, talking to the cloud services, and then use that learning to spoof an attack to pretend to be a mobile application, but actually they're using it for ulterior motives. So these applications, fundamentally, they're quite soft, they're quite easy to go into to reverse engineer, to understand what they're doing. And they're soft because they're software, and software is, is generally soft in whatever form it takes. Just normally we put it behind firewalls, we put it on servers. We don't have that luxury on a mobile device. And to some extent, it doesn't matter which of the two big ecosystems we're playing in there's still this vulnerability that's there in the applications that we don't want attackers to understand how they're working because they'll use that against us.

Can you talk about some of the differences between Android and the iOS ecosystem with regards to how to handle security, with what developers have to think about as well in regards to when they potentially launch on one or the other or both?

Yeah, I think we'll see If you're launching a mobile service, a mobile application, you're more than likely to launch on both Android and iOS. It's increasingly hard to pick just one, one of the players in the ecosystem. You've got to work on both devices to reach your full potential, to reach your customer base. There's similarities and differences that an attacker needs— or sorry, a developer needs to consider when looking at them. And the big thing that you see from the outside when you look in is iOS is a lockdown ecosystem. Apple tries to keep it as a walled garden. Kind of the only source of apps is the official Apple App Store. The devices are fairly locked down. It becomes harder and harder to jailbreak the devices, but there's still kind of this lockdown device, which is much more closed, much more restricted in what you can do on it. The Android side is a more open ecosystem, so that means there's less restrictions on what you can do. You can install applications from other sources. And we tend to get kind of in our North American or European view, we see Google Play as being the source of truth when it comes to applications. But when you go wider afield and you go around the rest of the world, actually you see other app stores, third-party app stores being quite popular. So You can't assume that Google is the source of truth when it comes to apps. There is people installing apps from other app stores as well. So you see this open ecosystem with Android versus the lockdown ecosystem of Apple. And I think as a developer that the open ecosystem brings a lot of advantages because you've got more freedom to develop products, to build out your solution. But it also brings more, more fear, more scare stories, because you see stories of third-party app stores, people installing malware and things like that onto their phone. So that becomes, at least at high level, it looks more, more scary and it's more of a concern. We actually believe when you delve a bit deeper and you look at the real risks, kind of selling security, it's nice to be able to kind of find real stories, real examples of things that are happening in the wild. And when you look at what's really happening in the wild, what you see is similar risks across, across Android and iOS. And you see similar risks because of the way that attacks at scale that work against these applications. And most attacks at scale won't attack your version of an application installed or my version of an application installed because that's a point attack. That's great for attacking you, it's great for attacking me, but as a criminal, I want to return on my investment, and I'm not going to get that just going after you or just going after me. I want to go after the install base. So the way to go after the install base is to find vulnerabilities within the code, to find something that I can use remotely but attack lots and lots of installs of the application all simultaneously. So that means finding vulnerabilities. Vulnerabilities are fundamentally bugs within the software, bugs that are security risks that can then expose us. So there's kind of, on average, a mobile application has 50,000 lines of code, and that translates to, in the average mobile application, about 2,000 bugs within the software. Most are benign, Those that aren't, most are functional, but there will always be a few that are security impacting. Maybe they're a buffer that I can overflow from a remote message I send or something like that that becomes security impacting within the application. And when an attacker identifies these security impacting bugs, they can then launch a mass attack against install base. And that's what you see happening with some of the We've heard the stories around WhatsApp recently, and there's many other examples against other applications. So if we go back to practical steps, practical measures that our developers or our founders can look at, they could try and squash every bug within their application. That's not gonna happen. The reality is that's just an awful lot of effort, and we're again trying to stretch to infinity. The more practical measure is to make the code itself difficult to understand, difficult to analyze so the attackers can't find the few security-impacting bugs that are hidden within your code. So technologies like obfuscation can really give a strong advantage there to our, to our companies to make sure that the apps are secure because we're obscuring the bugs, we're making it hard for the attackers to find the vulnerabilities. If they can't find the vulnerabilities, they can't exploit them.

Interesting. Now There's also a trend where developers are using tools like, say, React Native and things like that to kind of try to go cross-platform right off the bat versus just building natively, which means that you essentially have two code bases that you have to maintain. I would assume that that's a bigger security risk, maybe not, but I'd love to hear your thoughts on that. Is there something that they should— that a founder that's basically wanted to— wants to put together like a React Native app or something like that that they have to think about versus say a native, and I'm saying this lightly because all the React Native people are gonna be getting after me for saying this, but just versus building directly in the ecosystem, for example, using Apple's products or something like that. Is there something that they should be thinking about or is there any extra security risk or less security risk? What are your thoughts about that?

Yeah, there's a definite trend to using technologies like React Native. You see it emerging over the last year or so. And these frameworks have existed for a while. There's been, if we go back far enough, there's things like PhoneGap that people were using. I think when we get to some of the more modern technologies like React Native, we actually start to create good applications, good user experiences, which is why they're starting to become popular. A trend I particularly like, partly because I saw some of the earlier cross-platform development tools and wasn't overly impressed by them. So I don't like it from my development hat on, but I also don't particularly like it with my security hat on. And the, the reason I don't like it with the security hat on is, take React Native for example, the executable code is JavaScript and that JavaScript gets bundled within the Android application or the iOS application. And then when your application starts up, the JavaScript gets loaded into a WebView and is then interpreted and run on the application. It's just fine for building an application. It gives you benefits across platform and all the rest of it. The trouble is with an interpreted language like JavaScript, it's much, much harder to get security. When you're thinking about security, thinking about how to keep your code as safe as possible, then you want to get as close to the hardware it's executing on as possible. And the reason for that is we want to make sure people aren't changing, they aren't tampering your code, so your code is running as you intend it to run. It's good building security measures into code, but if someone can remove them, then that's a weakness, that's a vulnerability that we don't want. So if we can build in good anti-tamper, good integrity checking technology into the code, then we start to build trust into that code. We start to believe it's going to execute the way it's intended to execute. As you move away from the hardware and into interpreted languages or languages that are running on virtual machines, then this code goes through a translation stage and interpretive stage before it executes. And that interpretive stage is changing your code. It's changing the code from how it's delivered to how it executes. As such, it's a tamper. It's changing the code. So if we want to guarantee the code is running as delivered, anything which changes it, whether maliciously or deliberately, is a problem. So interpreted language like JavaScript or kind of even Java itself, which are running on a virtual machine, they do pose security issues and security questions because they go through this tamper, and you can't tell if the code's been deliberately tampered or accidentally tampered. Are maliciously tampered.

Super interesting. Never thought about it that way. Can we talk a little bit, since we have such an expert on this, can we talk a little bit about encryption versus unencryption and, you know, your data? How should people think about encryption with regards to their data on a high level?

At a high level, encryption is important. Kind of fundamentally, the internet wouldn't work, e-commerce wouldn't work if we didn't have encryption. It's a very smart technology, which I don't claim to understand all the details of how it goes together. The maths is incredible. Some of the stuff that cryptographers can do is truly impressive. But, uh, at a fundamental, more architecture level, there's really 3 things you need to consider when looking at encryption, and that's kind of always looking at how you're keeping the data safe. So how do you keep the data safe in transit? So when you're moving it from one place to another, as in over the internet. You need to look at how you keep the data safe at rest, so that's when you're storing it, so kind of whether it's on the file system of a mobile phone, whether it's in your database in the cloud, how do you keep that data safe at rest? And the one that often gets forgotten is how do you also keep it safe at use, when you're processing that data, when you're using that data, How do you keep it safe? It's fine when you're behind a perimeter in your servers, you're on your cloud and you've got your firewalls there and you build a protection around how you run the security so someone can't get in and see the algorithms running, see the cryptographic keys. You don't have that luxury when you're out in the wild, you're on a mobile phone. The encryption you're running, the algorithms you're running, can be observed, and generally the algorithms aren't too secret. We, we use well-known algorithms all the time, like AES. But what is secret, what is important, is to keep your cryptographic keys safe. These are the secret to unlocking any cryptography, and when you're building your architecture, you need to think, where are those keys? Where are they stored? Are they safe? And if they're just sitting within your mobile application or they're sitting on a file system somewhere with no protection on them, then an attacker can take those keys and use them. So kind of, we talk about black box and white box cryptography. In a black box environment, your cryptography happens behind a secure boundary, so it could be on a server or it could be on the chip in your credit card, but there's a that boundary that's built keeps the cryptographic keys safe and makes sure the processing at use is done in a secure environment. If you're doing the processing on a mobile phone or a small IoT device with no hardware security in it, then that's what we call a white box environment because it's open, it's easy for someone to see what's happening. If someone can see what's happening, then they can find the cryptographic keys that you're using, so then you need to use special forms of cryptography that we call white box cryptography, those keys safe to keep them from being exposed to an attacker. Fundamentally, the keys are what locks down the whole crypto architecture that you're building.

Amazing. Before we wrap up here, and we're reaching here the top of the hour, can you talk a little bit about VeraMatrix, about Protect My App, and how you work with startups, and a little bit about what you do so that our community can potentially engage with you down the line?

Yeah, of course. So VeriMatrix is quite a large company. We work in many different areas. The focus for me and what I do is security, and security really underpins everything we do as a company. So whether it's the different vertical markets that we feed into, such as the media space or the payments finance space, then— but we always underpin it with good practical security. And when we're providing that security onto other companies, onto startups, onto people that want to use it, we believe very strongly that the security should be friendly. And when we, when we say friendly, what we really mean is easy to use, easy to deploy. It goes back to the, the practical security that we could build the best security in the world But if our customers can't deploy it, there's no point. So we're always looking at how we make our security friendly, easy to deploy, easy to use, and empower our customers to use the security that, that's there, but also enable them to get on and do what they really want to do, which is build exciting products, compelling user experiences, and grow their businesses. So when it comes to Protect My App, That was the driver behind what we were doing. We were looking at how do we take a mobile application, and we've got proven security that we've been providing customers for 10 years. How do we take that proven security but bundle it in a way which is super easy to apply, super easy to deploy? And that was really the birth of the Protect My App idea, where we provide a cloud service. You sign up online, You upload your application to the service, so an Android APK, an XE archive in the iOS world, and 5 minutes later you get back a protected application, one that's secured from reverse engineering, secured from an attacker understanding what that app's doing and using it against the companies. The whole business model and everything else is equally designed to be friendly.

It's—

you can try it for free, so protectmyapp.com, log on, sign up, have a go. So you can try it for free, you can use the service, and then once you want to continue using it and you see the benefits of the security, there's really no commitment. It works on a monthly subscription. So for a startup that's just beginning, they can start to access security, they can use that in a very simple, very easy way, it doesn't impact on what they're doing, and also kind of there's no real commitment to using it going forward, so they have flexibility and everything else you need when you're building a business and you're not quite sure what tomorrow's going to bring. Awesome.

Yeah, so that website one more time for our founders so they can check it if you're listening live is protectmyapp.com.

That's correct. Okay.

And definitely have a go at it, take a look at it. It's really important that you start thinking about security early. Even if you're not building a mobile app and you're not gonna do that for a while, it's not gonna be on your roadmap, it's really important to think about, take some of these principles that you've learned from this podcast and start to apply them to your business early on so that it becomes part of the fabric of your culture for your company. Because moving forward, even if for whatever reason you morally disagree with some of this stuff that we're talking about, you're gonna have to deal with a lot of the consequences, whether it's from the federal government of the United States, California, or whether it's you know, GDPR in Europe and other places. So this is gonna become more and more of a challenge, and the last thing that you wanna have to deal with when you are running on a shoestring budget or when you have raised a small amount of money in your pre-seed round is to have to basically have to deal with managing through this in order to be able to save your company. So it's good to start taking some precautions, and then that could save you a lot of money moving forward as well. So just something to think about, and more importantly, your own mindset and the amount of stress and pain that something like this could deal with is just not worth kind of dealing with, right? So just think about that as you build your company. Neal, I really want to thank you so much for taking the time out of your busy schedule to come on this podcast. This was terrific. You've dropped a lot of knowledge on our community, and we're very, very, very thankful that you were able to do this. So thank you so much for doing this.

No, thank you for letting me talk, and hopefully it's been insightful, and hopefully it's been useful to your founders.

Amazing.

Awesome. All right, thanks so much. Take care, Neil.

Thank you.