For those of you that prefer the audio version, feel free to check out the actual podcast recording here:
Say hello to Aren, Founder and CEO of Foxpass!
Aren is a former travel-loving, country-hopping jetsetter-turned-family man with an extensive background in high-level engineering roles such as Vice President of Operations at Bebo, CTO at Third Ave Labs, and also Director of Engineering at Oodle.
Do you want to just give a little bit of background about yourself?
Yeah, absolutely.
I'm Aren, the founder of Foxpass. Been doing this about 4 years now.
Prior to this, I was Head of Technical Operations and IT at Pinterest, and prior to that was at Beebo, Oodle, Danger (they made the T-Mobile Sidekick, if you remember that phone).
And prior to that, I was at Stanford for a Masters and Bachelors in Computer Science.
So how did you get started in programming?
My mom brought home one of her office's Apple IICs, one of the early portable computers, and I just found myself just trying to use it every weekend, learning as much as I could about it.
Ended up learning a little bit of Applesoft BASIC, and just from there was able to make pretty simple programs.
From there, when we got our next computer, I picked up a book on C, and just learned how that worked, and went from there.
Wow. So you self-taught and went to school as well?
Yeah. That's right.
Most of the programming that I learned before school was all self-taught, and then at Stanford I picked up a computer science degree and did all the CS coursework there.
In terms of the applications that you build, what's the least favorite one that you made? Have you ever made a side project that you don't remember why you made it?
I think my memories, at least of programming, was all for school.
The ones I make for fun are all great, even if they don't work out, 'cause I at least learned something or got to experiment.
The ones for school were just tough because you're under this time pressure, and it's all new material. You're not exactly sure exactly what they're supposed to do or how they're supposed to look, so some of my least favorite programming moments are definitely from school.
Like late at night in the computer lab pounding your head against the keyboard.
Tell me about maybe an event at any of the companies that you worked for where you just saw complete disaster. Have you ever had a moment like that?
I can't think of one that [lasted] 10 hours, but there have certainly been-
There's certainly been moments of terror when something pretty bad is about to unfold.
I think I've been pretty lucky in that the extended incidents are in two or three or four hours of impairment or downtime.
But there's always, there's things that you thought you'd planned for everything, and there's something else that pops up.
Murphy's Law, I guess. I've had them at every company.
How did you get into server and network security?
Yeah, really, I mean, it's something I've had to pick up pretty much every role from Oodle on forward.
Either there wasn't anyone in that role, or that person had left to company and it needed some attention.
Especially at Pinterest, which is common of most, many new companies, it really was all application developers, and security wasn't as important until you get into the on-boarding a lot of new people.
That's when access control and identity becomes really important 'cause you're on-boarding all these new people.
First you want to get them into the servers right away, so they can be productive as soon as possible. It's great for morale when on-boarding. But at the same time, you have to be careful of who can do what.
You want to be able to respond quickly, both on the on-boarding case and the off-boarding case.
What's a big mistake that you commonly see with engineering teams? They're scaling, they're adding engineers, what's a really common security mistake that you see?
I think the biggest security mistake is sharing credentials. It's really easy.
Hey, you've got some new engineer on the team.
Hey, here's how to login to the servers, whether that's the username and password that everyone uses, or you share them the private key that was set up on the server when it was created.
Those are the biggest mistakes and the worst mistakes that I see.
From there, it's maybe everyone has their separate SSH key, but they all share the same user. That's not terrible, but it's still not best practices.
What would be, let's say everyone was doing all those things... describe something like the outcomes. What could go wrong?
I think the worst case scenario is you're just not protecting the company.
If someone off boards or is let go, and they have an axe to grind, if you don't immediately go and rotate all those shared credentials, that person can go home, or sit in your parking lot to be on your wireless, or whatever, log into your servers, and delete everything and cause you a lot of problems.
That's the worst case, but a company's job is to protect [itself].
Which is why the company just needs to think about these situations and how to protect itself. That's, obviously, worst case. It rarely happens, but if it does, it's catastrophic.
How would you explain Foxpass to the world? What's maybe your favorite piece of functionality that you build out of Foxpass?
Yeah, so the first part, how to explain Foxpass to the world.
Basically, we want to give everyone their own name and their own password, or their own credentials, to everything in your infrastructure. No more shared wireless passwords on the whiteboard.
Everyone has their own name and their own password. No more shared usernames or SSH keys to your Linux servers. Everyone has their own credentials.
Now that everyone has their own credentials, you get to transition into access control...
This person can only access these servers, which is a separate list than Bob over there. He can only access a different set of servers, and on those servers, he's limited in his functionality.
It's not all or nothing to the whole infrastructure. It's not even all or nothing to a certain server or set of servers. Everyone has very granular access that's for them.
Then, on top of that, you can do temporary access.
You're going to give a permission to somebody on a set of machines with either an end date, like a date and time, or an end event.
For example, the example I like to give is, when you're on call, when you have an on-call week, then you'll have pseudo-permissions everywhere you need it. But when your on call shift is over, you lose those permissions.
You can get them again pretty easily, if you ask whoever is on call, potentially, but you just don't have them anymore until you're either on call again or you request them. That way if your laptop gets stolen, the company doesn't have to worry that your keys were on that laptop.
They have full permissions to everything, and there's a lot more service area we have to cover to make sure that there is no breaches.
You started Foxpass out of a problem you saw at Pinterest. If you had to go back in time and do anything different, is there anything you would change about Foxpass? Or maybe mistakes you made early on as a founder?
Sure, tons of mistakes. I mean, I think my background is engineering… my background is not in building businesses, so when I look back, all the things I wish I would have done differently are around growing the business faster.
I think we've done a great job of giving all of our early customers a really good experience, but there are things we could have done probably to find more customers like those earlier on.
What's your favorite random thing maybe a customer said to you?
For example, I remember at my previous company, Bizness Apps, it was spelled incorrectly. B-I-Z-N-E-S-S, and I had a customer email in concerned, telling us that it was spelled incorrectly.
And he was serious, and we thought it was a joke, but he was like 'did you know your company is spelled incorrectly?'
That's funny. I can't think of any corollary.
I think the best quotes that I get are something like, ‘wow, I've been looking for this for forever’.
Those are the ones where I know that I've found the people that I'm trying to sell to, and that the product that we've built is exactly what they're looking for, just like it was exactly what I had been looking for at previous jobs.
What do you like to do for fun?
I used to enjoy travel. It's hard to do that now with two kids and a startup.
Now you'll find me at the park with said kids, or when they're napping, I'll be working on my house, which is a passion of mine.
What's the coolest place you've traveled to, but do you want to cover that since you don't travel that often anymore?
Favorite place I've traveled to...
Well, in 2009, I took a trip around the world. It was a little quick.
It was only three months, but I got to see parts of the world that were just incredible to me.
Most of Asia, it was amazing. Southeast Asia, India, just beautiful, beautiful countries and beautiful people. That was probably my favorite part of that trip.
Just it's so hard to get to those places that I'm glad I got an extended amount of time to see them.
There's a ton of people starting companies. There's a lot of people just like you that are building really great products. Some maybe not building them as security in mind from the beginning. If you had any advice to give those founders to those startups, what do you think it would be?
Yeah, I think start security earlier than you think you might need to.
I think, first important is to make sure you have a product people want to buy.
If you don't have any customers, you have nothing to secure, but as soon as you start getting traction, start thinking about your security stance.
I think customers are more and more savvy these days and are going to ask these questions earlier than they used to.
What is your access control strategy? Do you have principle of least privilege?
Think about these things earlier, so you're not scrambling when they start asking these questions.
.png)
