Building Secure SaaS Products | Protecting B2B Business from AI Threats

I define myself first as a software engineer and an accidental entrepreneur.  

I started 30 years ago as an employee of some organizations doing different aspects of running the organization. My role was mainly as a software engineer for several companies.  

And sometime in 2008, I became an accidental entrepreneur. It was the time when the first Android phone was released here in the US. At that time, the most significant opportunity that jumped out to me was that, by default, the Android phone did not have a corporate email client.  

Most people living in Redmond and many employees of Microsoft were used to using corporate email on their phones and having a new phone is no use if they have to carry another phone or a BlackBerry to get their email.  

I started building an email client for Android specifically for the Exchange Server, which got some traction. It helped sell more Android phones, and it also helped us sell the software.  

Fast forward a couple of years, Android started having native email clients. But when that happens, typically when your product becomes redundant, and it feels like the world is crashing around you because the phone already comes with an email client, your instinct would be, “Oh my God, I’m finished.”  

But we pivoted a little bit to the site and discovered that there’s all the software for getting your email on the phone, but there are issues of 

• What happens if your phone falls into the wrong hands?  
• What happens if your phone is unlocked and someone else gets hold of it?  
• What happens if someone plugs your phone into a USB port and a computer? 

In those days, the operating system was not mature enough to recognize the importance of a secure container for your data and application.  

So, there was no way to secure your email and sensitive information. So, instead of just focusing on the usability of the application, we also started focusing on how secure it is and how enterprises can rely on this piece of software to get your email on the phone but take enough measures to make sure that your email is not compromised if the phone is lost or in several other scenarios.  

We trust an email coming from someone to be indeed from that person, and you might even act on an email because it came from you. It might not be the right thing to do.  

How do you know that the email from Venky is indeed from Venky and not someone else who pretends to be Venky?  

So, these are the basics of security. I had to brush up on many basics to come back to implementing some of the measures we had to take on that application.  

Anyways, six years from then, of course, we partnered with a bunch of mobile device management vendors and had the name of the product Touchdown, had it been the official email client for MDM vendors who did not necessarily want to go through the whole process of implementing an email client.  

So, we had over 25 vendors who used our email client as the official one. Eventually, it was acquired by Symantec, which wanted to integrate that into its mobility portfolio. So that was the story of becoming an entrepreneur.  

But once the exit happens, I work with one of the startup incubators here in Seattle, and I have the privilege of picking and choosing the projects for which I try to build a prototype, a first version, or a V1.  

Building a V1 is one of the most satisfying parts of building anything because, after V1, you have customers, investors, and whatnot—so many restrictions and constraints. So, I’ve been doing that for the past few years, working on something new.  

It still has to do with tech, and anything that requires a server or a client or networking or security is something that I’m always interested in. 

Yeah, that is the unique part of that story. The company started with zero, and the process of building value was entirely through the software. No marketing, no additional budget.  

So, there was no venture capital involved at all. And it might not work in all situations, especially these days, when there are so many different products bought for your attention.  

When you think of yourself as having had success in a particular effort, there are two types of hits: 

The first is technical success. That means what you set out to build does work the way you insisted it will work. So, you’re technically successful, your product works well, and nobody uses it, but it gets the job done, which is a technical success.  

And it’s just as important as business success, in which case your product works well; maybe it doesn’t even work well, but many people use it business-wise.  

So, that is a success from a business perspective. And that’s where you say that the company successfully creates revenue. If you open my computer, you’ll find ten or 15 or 20 different projects in various stages of completion, some of which have been abandoned, some of which are still there.  

And that’s the case with many people’s GitHub accounts as well. I’m sure your GitHub account is a crematorium or a field of dead projects.  

Some of them are just dead and gone and forgotten and no use. But some of them have little daisies coming out of them.  

And I tend to look back on those projects occasionally to think about which ones have these daisies coming out of them, run to some of them, and pick them up so you can use them in your next or future endeavors. 

 So, anything you do, even if you think it’s failed, has taught you something; it has had some benefits that you’ll never know when you’ll come to use in the future.

Yeah, there’s a lot. There was a time when your brush with security was a user ID and a password to enter a computer. There was a time when security was all about ensuring that the password you typed did not appear on the screen.  

And then came the time when, “Oh, my God, I started installing software from random floppy disks onto my computer. I hope I don’t have a virus”. And suddenly, welcome to the dungeon. That was when we started seeing things happen with bad effects. 

And that was again about 25 years ago. At that time, a security company would typically build something that prevents viruses from taking over your computer.  

And suddenly, you started plugging in your computer to the network and realized, “Oh, God, now you have viruses and things that can steal your data.” And then again, the web, the HTTPS protocols. And every time you take one step towards improving technology and lives, you’re taking one step back in protecting your users.  

And so, any new thing that you figure out, so be it social media or any of the latest technologies, AI, you are opening the world, the user, you’re making them vulnerable to new threats and new types and creative ways of stealing data or money or both from your end users.  

So, the only thing that stands between you and total disaster is whatever measures you take, be it different levels of actions you take at every step of the way, from the network level to the application, to protect your users.  

So, things have been changing, and they will keep changing. So, if this has happened in the last 25 years, imagine what the next 25 years will look like. There’s no limit to it. 

If you’re not 100% sure it can be safely deployed, don’t do whatever is in there. And sometimes problems will lay beneath the covers, unseen for years and years before they manifest into some bad things that happen. So that’s the reason why you must be 100% careful.  

It will look like it works today but might bomb in a few weeks or months. So, there are dangers there. But when it comes to using these models to put checks on models, what you’re essentially saying is creating Uber AI is to control AI what one AI has generated. This will be an exciting track moving forward for the next few years. 

Is a paradigm shift needed for data validation in the face of data manipulation challenges? What defines good and bad prompts, and how can we prevent smart attackers from exploiting them? 

The key here is to ensure the two models are not the same. The two models, the one that generates it and the one that validates it, are not the same, and they come from two completely different knowledge bases.  

So, for instance, if you cloned me and asked one version of me to write a particular piece of code and asked the other version of me how it would break. 

The second clone will not know that I made a mistake here. The key here is that your model that validates what another model generates cannot be a clone, so you can’t. You’ll have to rebuild from different knowledge.  

That way, the knowledge being used to apply there is diverse and not a clone of an existing model. So, there’s scope for multiple models to live in this world. Just don’t ask the same guy, that’s all.  

But again, when you’re writing and deploying code, AI models have not started generating pre-built libraries. The good thing is that they will give you a lib file or some pre-built binary for, hey, this is the code I generated with the prompts you requested. Deploy this.  

That would be wrong, but if it gives you source code, you won’t tell anyone other than a programmer to use that code. So, if they can read and understand the code, it becomes a valuable tool.

One of the analogies I draw from that discipline is how many layers of protection are between you and a disaster.  

If you look up the Swiss cheese model, which might also be expected in the security space, you’re talking about several layers of Swiss cheese. Each of those layers covers part of the whole rectangle, but there are holes in there, things that that layer does not protect from.  

So you put another layer of Swiss cheese, another one, another. Each one of these things that we do from a safety perspective is stacked together. And the goal is to make sure that when you put them all together, no holes are showing.  

And when you have them all together, and there is one hole that happens to be in every layer of that layer of cheese, when there’s that one open hole, that is your real vulnerability.  

You become vulnerable to anything that comes through that hole. So, the goal here is to stack them all together. So, from a security perspective, what we are talking about here is obvious.  

We have security in every one of those layers. And what one layer does not catch, the other should see, and so on. At the end of the day, if there’s a hole, then only prayer can save you from someone just shooting something through that hole. Hopefully, that won’t happen.