Talks & Speaking Engagements

(Auto Generated from YouTube)

I'm going to go ahead and just get a quick show of hands how many people are actually an Amazon customer or have been in the past all right so you guys have probably had a little bit of experience with I am roles or I am in general as well as CLI um and I know everybody's really thirsty I heard the liquor liquor cabinet was locked up with some crypto ransomware so hopefully we're going to decrypt it after this we can all have some beers all right introductions uh my name is Paul Marino and I the security engineering lead for Pinterest um I'm focused on Federation of all the things and I like unicorns and cats hi I'm aan elwa I am a veteran consultant and architect and I do a little bit of everything so I'm not focused on being focused and I like long walks on the beach thanks all right so here's the agenda we're going to go over why we're doing this um how we can fix this uh how ays Works which ays is a solution that you guys will all see um a live demo of or sorry a recorded demo of uh problems encountered when we were building it uh some potential future problems we imagine we'll see down the line uh some pre-release improvements uh some future improvements as well as uh some time for Q&A so why are we doing this so here's the problem many organizations have IM IM accounts with poorly controlled credentials um that have potentially destructive access to production so that means you have a developer that's got some slot practice and hygiene with the way they handle key data and that ends up on the Internet or or out of their control out of your control and then it has damaging impact on your environment uh so despite tofa enabled accounts uh accessing the Amazon CLI still only requires an access ID and a secret key to utilize it so a little bit more on why we're doing this uh this this product will reduce the plain text stored keys in repos and on Hardware uh I consider everybody body's laptop and every developer that we've got at Pinterest kind of uh a risk especially considering it has Sensi of key data such as this um this will allow Federation and directory Services uh this automates the onboarding and termination which is very important uh some it departments have Sloppy practices about terminating all the access uh and this also enables the use of IM roles for users and service accounts uh I don't know if youve got a lot of familiarity with it but uh roles are the way to go because you've got a larger policy size you can you can app so you add cool things like uh the ability to restrict what source IPS uh the Amazon command line can be accessed from uh and this product will also allow the centralized use of existing tofa uh such as through your VPN uh so that you don't have yet another OTP on your phone uh I think I have 12 just for my current role so here's some examples of the problem that we've seen uh you can see there's a security week article here about attackers that were scraping GitHub uh as as well as other locations for plane Tex access IDs and secret keys out in the wild U and they basically use them to stand up Bitcoin mining operations uh and sadly I found there's a lot more open source solutions to actually scraping credentials than there are to solve this problem so another example uh I'd say this was uh also pretty lucky uh these people got popped with a $2,300 $2400 bill um because some hackers decided to use their account to launch a bit coin mining operation as well uh it's lucky because it was only $2,400 approximately the larger example would be these guys so this is an actual quote by Anonymous somewhere uh so code spaces if you guys don't know uh was dosed uh with some Ransom uh and they before they realized they actually had somebody that had unauthorized access to their Amazon account uh what they did is they ultimately for their infrastructure all the way down wiped out all of their backups to the point where they were no longer to do B no longer able to do business uh that's really sad for a company that's actually touted uh their ability to protect their customer data from catastrophic events such as such as this so how hard is it to find credentials out on the Internet it's actually really easy uh it took me about 60 seconds on paast Ben uh and I found just a whole set uh actually did have the full link here but I felt it would be embarrassing to actually leave it up so I decided to blur everything out um another quick example uh also found on pin uh someone that was also uh gratuitous enough to actually tell us what region they're running their Amazon instance in to let's see here so let's say I had the credentials what could you do um well the easy thing I would probably do is just go ahead and get a quick list of the Route 53 uh and see what hosted zones they have uh as you can see uh it'd be pretty easy to get a quick list and then all I had to do is run that one liner there to delete their their entire hostage zone so that probably wouldn't completely eradicate them off the net but cause a lot of complications for them for a set amount of time so or we could try to do something like this where I actually just want to go and create my own user uh we're just going to go and create a pony and then add that user to the admins group um so after that I can pretty much do whatever I want from the web console to um beyond the CLI so how can we fix this so we had a couple goals in mind when we decided to start uh development of arys uh we wanted to get the IM keys out of the hands of the developers um and out of the users and even some service accounts in some cases um and allow them to still do business as usual some pretty basic goals um from here I'm going to hand it over to amen so if only there was a credential service that would give us temporary credentials oh wait that's Amazon STS but so we need a middleman that can also talk saml and elap that will do some like you know some glue in between there we found shth which is an identity provider out there that does SSO and such sorry we're supposed to have two mics no no no second mic so shth um it's an SSO as I said um it allows for a tribute based uh exchange framework it also does Ro based but I'm not going to get into detail um it can as sle metalware uh it can also act as an auth authentication and authorization metalware and has a soap and HTTP binder there's tons of documentation out there on this and we chose this because of that um also there's actually Amazon specific documentation on how to Federate it on the web console um but not actually anything about getting tokens that was what became a pain in the ass so I'm going to go ah and for this over to aan and he's going to tell you a little bit more okay so now we have um shith STS and out of that AIS was born so putting it all together so coming into the project first of all uh we wanted to establish what are our knowns unknowns and what are some success factors so some of our knowns we knew that um shth can talk both ldap and saml okay great STS also talked saml okay another good thing um also however we did find out unfortunately that STS only supports 1 hour credential temporary credential tokens okay uh that's fine but at least we know that ahead of time we also know that developers don't like change and are very very whiny okay so I think everybody here most people here have experienced if you're a developer I'm sorry um anyway so some of the unknowns um what are we going to do with these 1hour credentials how are we going to make these work and we didn't know that STS was not really ready for prime time so um there was buggy there a lot of bugs a lot of documentation issues um I got to know a lot of AWS support guys by name so that was interesting um things that were success factors coming in was that um we wanted to make sure that business as usual happen for the devs so they wanted to no change for them as much as possible and AWS support was really good uh they were really helpful on this so what's STS well STS is a uh credential service you give it auth ication it gives you credentials that's it um there's three items up there out of the I think five total uh one takes saml the other one takes oath um it's um but some of the limitations is that you can only have one role so if you have users that have multiple roles when they go sign in they'll be asked to do multiple roles and for our purposes where we wanted to automate it that wasn't useful for us so we had to limit users to only having one role um also the 1hour credential thing was really a big limitation so what do we do well um first uh Paul was thinking let's get a PC together so we we brainstormed and said okay let's get a PC for the flow and actually figure out how to if it's even possible not necessarily automating it not necessarily making it clean for the developers but uh just making it work so was a lot of development a lot of pre-work some of the irns had to be added as attributes for an ldap uh we have to make sure that shth can consume those so making shth work with ldap and uh making sure that ads liked our stal assertions so a lot of trust policy a lot of um finicky details that STS was very particular about rightly so um in making sure that it's accepting our assertions so and then at the end get temporary credentials then once a PC is established okay how do we make this nice and pretty and and clean for the Developers thus Aris was born so what is arys aris is essentially a broker that works between shith STS and um and the user themselves it broker credentials the user would come in um enter their credentials and it goes out does all the leg work and at the end writes credentials for them to use for their normal day-to-day aw CLI what you get at the end is the Federation of aw CLI um you get reauthorization every hour talk more about that later and um this the same work can be performed the same way they did it before um just a little pre-work ahead of time um but it is is a slight change to how they do business so you do still end up with um a little bit less whiny devs but skeptical nonetheless in fact actually um when we went to deploy a PC to try it out with some of some of our developers and admins um I got crickets um I had I had to get Paul to chase him and say Hey listen can somebody try this out so um they didn't want to change to status quo so how does it work well um you have an interactive shell login uh the user enters their username password uh actually they only have to enter the password because it'll take it from the shell and um Aris will go to shi's web login enter the credentials come back from shith with a SLE response it will then take that s response and send it over to stf's service H send an assertion over there SCS checks it makees sure everything's fine that it came from a trusted source which is the shth which is I talked about earlier and then um you get credentials and you profit everybody wins the idea here is that AIS does all the L work so shth doesn't talk directly to STS it's you have this man in this this agent doing the work um but wait a minute what about these 1our credentials what happened to that how did you you fix that well luckily we have Python's request Library uh which is really awesome so in request you um when you make a request it will maintain the session cookie and all the session State information for you so perfect so before the temporary credentials would expire we actually make another web login request to shith shib is like oh I know you already I authenticated you already like an hour ago so okay fine it gives you back the sound response we do the whole thing all over again and uh we just update the ials wherever either in an environment variable or locally for the developer and um they don't have to do anything so it'll do this all throughout the day now we set a 12h hour time limit because we do want to make sure we reauthenticate them at least once a day so I think 12 hours is enough maybe in Silicon Valley maybe you should be 15 or 18 hours but I don't yeah so I I'll send this over to PO so I'm basically going to reiterate what he just said but I've got a beautiful Brad Pit as a white Andy developer so uh mechanics of this again are uh you've got shith and Amazon web services have to have a trust established uh so there was a lot of leg work uh setting that up uh there was some documentation it just wasn't super clear uh I gave some feedback on it uh again I this was also done on a a Linux system they have a lot of documentation on how to do it in a Windows environment which has proved to be a lot easier um but we went the hard route um shet is configured to go and fetch some attributes based on the user and then do some magic to map it to a role so uh shith ends up uh taking input from the user on behalf of Aris uh shth um has that trust established with Amazon already it generates a SLE assertion um based on the attributes of the user and then it passes it back to Aris Aris writes it to your operating system environments environment variables um and then it allows you to uh use the Amazon STS to perform CLI actions now time for a demo I did tell you I like cats and unicorns so as you can see I'm uh going to say hello bides um and then I'm going to launch into errors sors fetches my uh my shell username and and then I enter my password in which is just password by the way and then as you see magic happens and as you see there we've got an access key secret key and session token and we're now able to run commands if we like um and I'm actually comfortable with having that up on the screen because those are invalid after an hour so you can take a snapshot of that if you want they won't work all right back to Aon so some of the issues that we ran into uh with with AWS or at least the STS Service uh documentation was one thing um documentation was lacking uh it was you could hardly find anything in the other assume um calls that you can make there was a lot of documentation for errors uh examples what you would get but when you get an error with assume R samle nobody had any clue um until like you reach a level three engineer at Amazon so um documentation was really sparse um there was also undocumented like so um items in Botto that were just not documented at all and and also when you do a temporary credential you get three things instead of two uh you get a session token as well and there there was no documentation where what am I supposed to do with this session token so I got these temporary credentials and I'm trying to use them um but I couldn't use them and they're like oh you actually need that I'm like well can you just update your documentation to say so so you know that would have been nice um but more importantly and this was just this was me for literally like a week or two um bodo's library was hardcoded with something called Anon equals false so Anan is a parameter that basically DCT it's an anonymous connection so um if Anon is false that means you're coming in from inside the AWS infrastructure if Anon is true that means you're coming in from externally and so um assum roll with SEL was not allowed to make calls externally but I didn't know that um and so sometimes I would be at the office making a call and it would work but then I get home and it doesn't work I'm like okay what's going on so I hop on the VPN and it works Magic and so it was really intermittent and it was hard to figure out and and I was trying to think okay maybe there something wrong with my code I I spend ages trying to change it and I realized no my code is fine uh it's them and so um we uh finally got to a level three engineer level four the guy actually who wrote the stuff and he's like oh yeah that you're right uh we shouldn't be doing that and so he fixed it in like half a day so that was awesome um kudos to Amazon for fixing it quickly um but the idea is that as STS was not really ready for prime time um there were also issues with um encoding issues with saml where it was supposed to be a64 encoded but it wasn't and so I had to make changes to my code to just redo it which is fine um and just some general other bug so um you're welcome everybody um I did the leg work for making it available to all of you so um you're welcome and uh that's it and we'll send it over the PA all right all right so I'm going to talk a little bit about what we plan to do next with this um there are uh some potential future problems that we've seen down the pipe and one that we've actually experienced um I'm worried that maybe the shth Earls or if we use a different IDP that maybe that those might change and that would totally screw up this this uh uh Aris um and that would just stem from package updates or just general code updates Etc um there could be some other STS related changes um as you heard and uh reiterate how much pain he had to go through with Amazon I also experienced a lot of that on a day-to-day basis and I can tell you that they do do a lot of things without telling anybody U so that could be something that would happen that would impact the function of this of erys uh changes in the XML response provided by Amazon it's not very likely um but could also happen U then something that did happen um but I decided to leave it in a potential future problems because it could happen again uh certificate trust configuration between IDP and Amazon not a problem right uh actually part of the configuration process um insists that your IDP go and fetch a publicly available XML file to do some validation on their end so back last month U my it Department that has been using this product calls me up and it's like your shit's busted I'm like okay so go look at my logs start digging around and then I see my all signs point to this XML file as you can see as I've highlighted that actually expired that day uh Amazon was down for SLE integrated products for six hours because of this there a big up on their end is kind of Basics if you ask me so what we want to do before we decide to uh open source eras uh we're going to go ahead and do some mac and a bonto support it does work on both right now uh it needs a little bit more polish uh we want to demonize it so that it doesn't have to be a user interactive all the time um improved logging and of course exception howling some other feature improvements I've got a an awesome guy in my it Department that's been willing to step up to the plate and help us build a Mac app which would be very useful uh if we decide to open source it as a user you would input your Amazon account username password and then the IDP Earl and that should be it um and then that would actually let this right to your your o OS environments um as well as maybe a potential local file if you absolutely need it for something like a browser extension um oath maybe I've actually talked to one of my co-workers about this I haven't really explored it too much uh it may or may not happen uh and then something other than usernames and passwords because those are bad uh I think everything's moving towards aert world or if we can we can get move it to aert or key world where we don't have to deal with passwords anymore open source date ETA is July this year uh hold tight I hope to get it done we're going to make sure that we drill this drill drill out all the bugs so that you guys don't see any of them and now I'd like to open up for Q if anybody's got any questions for those of us that aren really familiar with sh sh correct but it can be done for other sorry so the question was shth is using is like the crucial element to this working uh that's correct it's the IDP we chose to use for this um I would imagine that you can do this for other things like an OCTA or One login uh the other or Ping Identity the caveat there is all of those uh present an MFA or a two-factor login so we would have to modify the erors product actually ingest that and then pass it over to them as an IDP so this product is using shth in a non tofa mode behind a VPN and firewall so that would be something that we would have to add on on top of that again I would rather rely on having um other tof uh than adding another one to the mix but for now yes to answer your question this is tied to shth anybody you know what I've heard about this it's a good question oh sorry he asked if I played with hologram so hologram is actually something I was I heard at a devops Meetup at my my office actually um if you want to put me in touch I'd actually love to talk to them I actually did mean to follow up with them yeah anybody all right oh one more so the question was um if we had to serve as account that we needed an access ID and secret key um would we try to move it over to this the answer is yes I would like to but of course this needs a lot of Polish and we need to make sure that it's not going to become an availability impacting you know Cog in the the wheel there um but I would like to see it used for all of our service accounts cral uh it's a good question uh there's a little backstory there too uh the question was um why we decided to go with samel to do this instead of any of the other options uh to be honest I didn't really see there was a whole lot of other options maybe aan can answer this one yeah it's more so because um because we're using our Lop our Lup is a source of Truth so that was the issue there um so s was the most compatible at the time um you can use ooth um if you want to um but to get that to work with shth I think would take a lot more like work shth kind of did s out of the box some that was part of the decision something's Chang any more questions okay well thanks everybody

Pre Intro - 00:00:01: Hey, really quick, before we get into the podcast, we aim to bring you the most practical, impartial advice in cybersecurity. So if you like what we do and you want to help us out, please follow us on whatever platform you're listening to us on right now. Okay, let's get into the episode.

Intro - 00:00:18: If you're the smartest person in the room, you're in the wrong room. This podcast is my attempt to document lessons from cybersecurity experts who can go deeper than most on critical topics. My hope is that you use these insights to fortify your business and grow your career and maybe one day partner with Cyft to select your next cybersecurity vendor. I hope you share and enjoy.

James Farrow - 00:00:47: Welcome to No BS Cybersecurity podcast. I'm so excited to have you on here. And for the people who don't know who you are and what you do, give us a little introduction.

Ayman Elsawah - 00:00:56: Yeah, thanks for having me. So I am a fractional CISO, so I help startups with their security. And I do a few other things too. I have a podcast called Getting Into Infosec Podcast where I catalog people's journey into security so that other people can be inspired and learn. I wrote a book because I don't like repeating myself. So if we sat down for coffee, this is exactly what I would say on how to get into the field. And then I have also a newsletter. I guess it all came together because I like to distill complex topics in security and make it easy for other people to understand. So I found myself repeating myself with my clients and so I started last week as a vCISO. I distill hard security topics in an easy to understand format, hopefully. So that people don't have security in their title can understand security. So I guess it's been a common theme. So I don't know. It's fun. And that's what I do.

James Farrow - 00:01:56: It's so needed to, right? Like cybersecurity has gotten so complex. It was already complicated and complex from a technical standpoint. And then you add in Richard Stiennon coined the term, at least it coined it for me, of marketecture. These marketing teams get involved. They start creating acronyms for things, MDR+, IDR, DRP, Gartner, and all these analyst firms. They've added to the complexity. And so you are a hero in my world for simplifying it, man. Like what are some of the things that are common that you've been able to distill down and make them easy to understand? Yeah.

Ayman Elsawah - 00:02:37: I find myself, it's hard for me to even stay up with the terms, you know, like CNAP and this and that, SIM. Before it was simple. It was like, how do you pronounce SIM? Is it SEAM or is it SIM, right? But now it's just so much more complex. What are some examples? Well, I took a whale watching trip and correlated it to fingerprinting. So when whale watching, I realized they said that every whale fin is unique as a unique fingerprint. So I took that and correlated it to like, okay, here's how we fingerprint in security. Like here's some heuristics to look for when someone's trying to attack your website or you're trying to investigate something, you know, using a user agent and a few other kind of things to figure out like device fingerprint, web fingerprint, things like that. So just trying to make it different.

James Farrow - 00:03:28: Yeah, absolutely. And like I said, it is much needed, man. I talked to SMBs and startup founders and they're like, I don't even know where to start. They've never even heard the acronym MSSP or VC. And so as they're raising funds in the startup world saying, hey, we just closed a $7 million big seed round and we need to start thinking about cybersecurity. They hop on Google and it's overwhelming. It's information overload. And they need people like you who can come in and say, hey, slow it down. It's not that complicated. Here's what you need. And if that startup founder comes to you and says, hey, we just raised $7 million. Our VCs are telling us that we need to think about cybersecurity. Where do you start? What do you tell them?

Ayman Elsawah - 00:04:14: Yeah, that's a really good question. So my job is to calm them down and to give them the warm and fuzzy and kind of like a security. And I think that's a really good question. I think that's a really good question. I'm a security therapist in a way. So there's a couple of types of security people out there, those that want to boil the ocean. And so you have to do this and do that. But with startup security, it's a little nuanced. It's very different. And so the first thing I tell them is like, hey, listen, security is not black and white. It's 50 shades of gray. And that was an actual article I wrote to help kind of distill it down. Because for every company, it's different, right? If you're a B2C company, your security footprint is a lot different than, say, a healthcare company or a company doing credit card transactions or fintech, right? Or crypto. So each one different type of client that I've had to work with has had a different, let's say, threat model. But there are some baselines that are common for everyone. And the number one question that I get from founders is like, how am I doing? They want to grade. They want to know, how am I doing compared to someone else? Did I get an A, a B, a C? Like, it's kind of interesting. And, you know, I guess from the VC perspective, they want to make sure that their investment is protected. And so, as we all know, security is a bunch of layers. And so that's what I try to do. I try to say, hey, listen, security is a bunch of layers. My approach personally is to live off the land. So let's see what we can do without buying any extra tools or anything like that. There's a lot of things that can be done internally. You know, one of the main things to look at is offboarding and onboarding. So as you're a startup, you're growing. You're growing. A lot of times your offboarding process is not that great. And so you'll find contract and engineers or various people still with access to your systems. Oops. So that's something to be cognizant of. And I'm happy to talk more.

James Farrow - 00:05:59: So what do you say to the security practitioner? And this is probably of the old order. Someone that's been in the industry for 20 years who says, you know what? It is black and white. It is that simple. You need to look at your vulnerabilities, have visibility into your organization, your assets, look at the vulnerabilities, patch those, have a way to detect if someone is attacking your environment, and then have some IR and some cyber insurance and some backups. It's that simple. What do you say to that person who says these are the building blocks? If you have these in place, you're pretty much good to go.

Ayman Elsawah - 00:06:35: Well, good to go is a very tricky term. I think the other issue in security overall is complacency. So thinking that you've checked all the boxes and you've done everything you need to do, and then you're done. That is like my number one enemy, basically, is like telling people, hey, it's never done. You know, a founder just the other day or a VP of engineering I was working with, one of the clients is like, I'm like, what's your goal for this session? And he's like, well, I want to know that we've done what we needed to do from a security perspective. So I had to like be careful and not to be too pedantic and say, well, just to let you know, security is a journey. It's not a point in time thing. So let's just keep that in mind. And as long as you keep that in mind, then you're good.

James Farrow - 00:07:20: I was going to ask, is there a way to correlate the stage of the company and the maturity of the business to the level of maturity they should have from a cybersecurity perspective? And is that enough to say, hey, for your stage, you are where you should be. And as these things change and as you grow, here are the things that we're going to likely have to think about six months or a year down the road.

Ayman Elsawah - 00:07:43: 100%. Actually, I have a couple of different playbooks. So like I said, I have the baseline playbook. But for a company that's like, say, under 50 employees or 25 employees. A lot of times they don't have an IT person, a full-time IT person or whatnot. And so I say, okay, as you're going to grow, like around 100, I've seen companies with 200 employees and didn't have a full time IT person. So like from my experience, like around 100 people, you're gonna have an IT person, you're gonna have to deal with like device management, things like that. A lot of times companies are just, the contractors use their own devices and laptops. I'm like, well, how are you handling device encryption and things like that? Are you allowing people to download So yeah. Every stage of company has different needs and requirements. So my formula is basically stage of the company. The type of data that you're handling and have to protect, is it like PHI, which is like on this side of the spectrum, or is it like just consumer logins? I mean, a lot of companies, they don't have much sensitive data at all, just consumer email and name. So, you know, what's the spectrum? What are we trying to protect? So size of the company, data that we're trying to protect, whether it's IdP or client information, and then risks to the business in general, right? So that takes care of the whole threat model. So to answer your question, are there different things for different size companies? Yes. A 25 person startup is gonna have different needs than I say a 100 person startup. Also, are they B2B or B2C? So when they're B2B, a lot of times they're facing enterprise clients and the enterprise companies are the ones pushing down the requirements to them to have like SOC 2 or answer these questionnaires and nobody likes to answer questionnaires with a no. They come to me like, Ayman Elsawah, how can we answer these questionnaires better? Okay, let's take a look. Let's see what could actually turn into a yes, like internally in your environment, because we don't want to lie. And so what can we do here? And then what's the story that you can tell the company that's factual, that how you can achieve the gap for that questionnaire? Because these questionnaires are like 400 questions sometimes.

James Farrow - 00:09:53: Yeah. And it's impossible for a startup founder, if they don't have you in their corner, to tackle that on their own. It's just too complicated. The tools are expensive. There's no easy way to evaluate them. I mean, it's so complicated that they need expertise from people like you to just help them conduct business, especially trying to work with the enterprise. And now when we think about those smaller companies, it sounds like you have a pretty good understanding of here's the base layer, right? And I think you mentioned that basic level. Let's dive into that. What goes into that basic level of security? Break it down.

Ayman Elsawah - 00:10:29: All right, cool. So first of all, your devices. So do you have device encryption enabled or not? Whether it's FileVault or BitLocker.

James Farrow - 00:10:38: Why is that important?

Ayman Elsawah - 00:10:39: Why is that? A good question. So if you're handling sensitive files, if you're downloading files with sensitive information, if your device gets lost, are stolen, then, and it's not encrypted, then you're at risk. Basically, you have to assume that information is stolen or lost, right? So if you download a spreadsheet with a whole bunch of social security numbers of like all the employees who onboarded, right? Say the people person in your company or whoever is functioning as your HR. Has a list of employee information, or worse, patient information from patients, because we all know that we like to download those CSVs and Excel files and like upload them and massage them and do different things. So that's a really big concern.

James Farrow - 00:11:24: Can I push back on that for a second?

Ayman Elsawah - 00:11:25: Yeah, sure.

James Farrow - 00:11:27: I'm curious because this is the No BS Cybersecurity podcast Podcast. So I want to make sure we get to brass tacks here. Isn't it true that a small business, let's take a 50-person business, manufacturing plant in Iowa City, Iowa, right? And if they lose a laptop, It likely has a password on it, right? Let's call it a MacBook. It's got a password on it. The person who finds that laptop, are they really trying to crack the password and get into the files and all of that sort of thing? And even though that's possible, isn't that an acceptable level of risk? Like likely that person finds a laptop, they're going to try to reset it and sell it on Craigslist, right? Right. And so is that overkill to be thinking about encrypting every device? Tell me your perspective on that. Is it overkill?

Ayman Elsawah - 00:12:14: I love it. Along those lines, what information would be on that device?

James Farrow - 00:12:18: Let's say it's a bunch of customer information, accounting information. Let's even say it's the accountant, the person who handles accounting's laptop. So they have the ability to send invoices and get payments and things like that.

Ayman Elsawah - 00:12:34: Okay. So let's say, for example, so I think there's a couple of different angles to this. One, the likelihood of someone going into that device and removing that data is going to be less likely. Basically, they're actually going to just wipe it or actually they're probably not even going to wipe it. They're just going to sell it on Craigslist as is. So depending on who receives it, if they have any technical know-how or curiosity, I mean, you know, a lot of teenagers have curiosity and just see what's going on. So here's how you have to approach it, right? So from a realistic perspective, if I have spreadsheets or the person that lost the device said, hey, I have a spreadsheet with all my, every employee's social security number on there or worse. Patient information with everybody's social security. So that information got lost. You have to assume that it got lost. As a cybersecurity person, that would result as an incident and you have to take the measures necessary to absolve that incident somehow, right? So yes, is someone going to, or for example, let's just keep it simple. If API keys, say an engineer, it's happened before, an engineer had their device stolen and they had API keys. They had API keys to AWS on their device. And last we checked, that device was not encrypted. So is someone going to go in there and figure out what to do with the API keys and hop into AWS? Probably not, however, we should rotate those AWS keys as soon as possible because we should have to assume that they've been lost. They're out there in the ether. So that's the idea. We take the likelihood. Does that answer your question? Or does that make sense? I love the pushback.

James Farrow - 00:14:16: Yeah, it does. But it still makes me think that the data encryption is overkill for most small businesses. Like if the device is lost and it has the API keys, like, hey, we're going to rotate the API keys. The likelihood that the person who found that laptop sitting at the mall took it home, put it on Craigslist, and then someone hacked the password to get into the MacBook and then even understands what they're looking for or what they have, understands the API keys and then executes some action to. Attack the company. I mean, it seems so far fetched. And even though it's possible to me, it feels like it's in the bucket of acceptable risk. And instead of. The encryption of every device, It's, hey, let's rotate the API keys and we're probably good to go.

Ayman Elsawah - 00:15:01: Well, it really depends on what data is in there. So as a business owner, it's up to the business at the end of the day to decide if it's an acceptable risk or not. So to just go through every device and say, hey, can you just check to make sure you have Encryption enabled, that exercise Is that, go through the concern of the device got stolen, figuring out or wondering what was on that device and if it would come back and haunt you later, right? So I think just balancing the two is, and you have the right to, you can pick either one, right? You can choose to accept the risk, that's totally fine. My job as a security person is just to inform you what you should try to do to try to balance the risk. But you're totally welcome to. Of course. Yeah, you can totally do that.

James Farrow - 00:15:47: It seems like in the security realm, we're doing so many different things to solve for one risk. Let's say you have the ability to do remote containment. And you can power down a device and wipe it remotely. And you use that as if there's a stolen device, we're just going to isolate it from our network and wipe the machine. Doesn't that take care of the problem? Wouldn't all of the additional layers of security be overkill? Because in this scenario, we're just going to wipe the device anyways. I have the encryption layer and all of those other features and tooling and defense strategies. When we know the device was stolen, let's just isolate it and wipe it.

Ayman Elsawah - 00:16:32: If you can actually reach it and wipe it, then yeah. But a lot of times it's not online enough. But if you can reach it and wipe it, sure. Yeah, that's great. I wouldn't necessarily use that as we can wipe it. So let's not encrypt it. Right? I would say, you know, hey, if we are worried that all our devices are not encrypted and we don't have the bandwidth or whatever to go through and. Make sure everything's encrypted? Do we have the capability to wipe everything in case it's lost or stolen? But today's technology, they're almost the same switch. They're actually like next to each other. So if you can wipe a device, oh, you could turn on encryption as well remotely. So the level of effort isn't that much, but it's not as much as it used to be.

James Farrow - 00:17:16: And if the level of effort isn't that much, why is it that a startup founder has to hire a cybersecurity expert to have just proper cyber hygiene? Like if it's as easy as a click of a button, I mean, they do, though, right? Like, they do have to have some expertise. And a lot of times they buy a tool that's so complicated that they have to hire an entire other organization to manage the tool for them. Why is that? If it's as simple as a click of a button, why is it so difficult for a startup founder or a small business owner to manage their own cybersecurity posture?

Ayman Elsawah - 00:17:53: Well, why is it hard for them to manage this cybersecurity posture? I guess because... What I've experienced, the hard part about for a startup founder specifically, is prioritization. So a lot of times they know what needs to be done, but they're not sure what needs to be done like right now. So what needs to be done right now versus tomorrow? Because in startup land, prioritization is king, right? So, or it's key. So in prioritization, you know, there's always features that you have to do and requests and bugs and whatever. So like figuring out what has to be done now, today versus tomorrow. Same thing goes with security. What do we need to do today to give us our base level comfort of security that we're protecting our company or data or client stuff, reputation? You know, it depends on the industry you're in. So I think that's really at the crux of it. And then of course the tooling from a technical perspective is a pain in the butt. Like when you buy a bunch of Macs from Apple, there's no easy out of the box way to manage them. You have to utilize a store, you find and figure out some sort of MDM solution. It's not like out of the box. With Windows, you could use Office 365 or like Google Workspace. There's different things, but then there's extra cost. So a lot of times the barrier to entry to use the fancy security tools that makes your life a little easier is like double the cost per user. And so a lot of times it comes down to the cost.

James Farrow - 00:19:25: And then it becomes quadruple the cost because you go, I can't manage this shit on my own. And let's just pay for the fully managed solution. And so then I don't have to think about it as much.

Ayman Elsawah - 00:19:38: Yeah, I hate the fact that like, not only do you have to pay for the tools, but now you have to pay for a person to manage the tools. So that's why sometimes my job is tough because depending on the company, I mean, for some folks, they'll be like, yeah, put in SSO. But I'm like, do you know the cost of SSO? Like SSO is a big cost for a smaller company because not only do you have to pay the additional cost for SSO, but, all the other applications to support SSO have an additional license fee, right? There's a great website called SSO.tax that goes through and lists all the companies and the different price tiers they have to pay for SSO functionality. Now, don't get me wrong. I love SSO. SSO is awesome. If you can afford it, do it. Once you reach like 100 to 250 employees, you probably really do need it. It'll make your job a lot easier, your life easier, access reviews, onboarding, offboarding. However, there's a cost, time, money, and not everything else.

James Farrow - 00:20:37: For someone listening, and this might be their first time hearing the acronym SSO, what does it mean? What does it do? And if it resonates, how much would something like that cost for a 50-person startup ballpark?

Ayman Elsawah - 00:20:51: Oh, boy. Okay. So, single sign-on is where you log into one place. And from there, you get access to all your different apps. So you log into a portal and that portal manages, that's the only one password that you need to know. So SSO is single sign-on. And so you log into a portal, and you log in, you see a dashboard of apps, whether it's Google or Asana or Office 365, whatever, you just click them, and then you'll get access to those apps. You don't need to log in again. And then, from an administrator perspective, When you're done with the company, I disable that one login, that one particular login, and I keep using acronyms of companies that are out there. It's so funny. And then you won't get access to apps anymore, and it'll trickle down to all the other apps. Anyway, so that's it. From a cost perspective, It could range from, there's different levels of SSO because there's like single sign-on plus MFA and they keep like adding a million different things. And there's a really good feature of SSO where it'll check the context of where you're logging in from. So if you log in from SSO New Jersey, but then somehow there's a login that comes in from France like a few minutes later. Well, I don't know if James Farrow was able to go from New Jersey  to France in about like 10 minutes. If you're able to do that, let me know. And it will prevent that login from coming in. That's called context where logins and security, or it could be known as zero trust. So the cost, $5, $10 a person a month to like 50. The average is like $50 a person per year. It's a cost. And then all the other apps, you have to upgrade the different apps that you have. GitHub is a really good example. For GitHub to support SSO, it's about like four to 10 times the cost, about like $30 or $40 a person. Website has all the latest numbers.

James Farrow - 00:22:46: Yeah. Now, if you're listening, go do your own research. So how is SSO different from MFA? And is one better than the other?

Ayman Elsawah - 00:22:55: Yeah, one is different. So MFA is just a fundamental, so MFA multi-factor authentication, which requires you to not only know your password, but to have some other thing in addition to your password to log in. So MFA is where I log in, I log in, there's 2FA, there's MFA. So where I log into my website using my password and it's going to ask me for a token or number that could be sent to me via SMS, which is not recommended anymore. Or an app that's generating a new number every minute. And so you enter that number because it's something you know, which is a password and something you have, which is that token. And so that's what MFA. So MFA is fundamental. Like that's like, super required. SSO is like a nice to have in an environment that makes administrative access and management way easier to handle.

James Farrow - 00:23:48: What about YubiKeys? I mean, are those better than MFA and single sign-on or are they just in a different bucket?

Ayman Elsawah - 00:23:56: YubiKeys are a form of MFA. So they act as a factor. When you log in, you could log into your password and either you enter that token number or if you have a YubiKey, you enter and use your YubiKey to log in.

James Farrow - 00:24:08: And how much more secure, and I sound like a founder asking you for a letter grade here. But how much more secure is a business if they have nothing else besides MFA with YubiKeys?

Ayman Elsawah - 00:24:19: I mean, that's a great step. If they have MFA with YubiKeys on all their critical logins, especially admin logins, or even all their apps, there are so much more ahead than many other companies out there.

James Farrow - 00:24:33: Why is that?

Ayman Elsawah - 00:24:34: Why is that? Because most companies, they just username, password, login, that's it. So there's a couple of different classes of logins, right? So there's a regular login where you just log in and do your thing. But if you have administrative privilege, right, then that's coveted type of login and access. Right. So if you are also the administrator for Gmail and your session, if you go to a malicious website or whatnot and your session gets hijacked or stolen, then that person now has administrative access to your Gmail workspace and create users and steal drives, data and all that kind of stuff. So and then bank account logins. Right. So I think a lot of banks now enforce to it. But before it wasn't. But like your Stripe login. Right. Do you have MFA on your Stripe login? Stripe is your the place where most of the revenue for companies lives or maybe PayPal or whatnot. So. Or your AWS login, right? So if you're logging into AWS and you have MFA and you're using YubiKeys, that's great, especially for admin logins. What YubiKey is, is you actually have to physically have the key. So it's less susceptible to being stolen because you actually have to have the key. There's a cryptographic signature on the key there and you press the button to indicate that you are there. And it's different than, there's something called MFA fatigue attack, where basically people or attackers will prompt an MFA and you're just so tired, you're hitting yes and stuff and you just hit yes by accident. Not realizing you just let an attacker in. So YubiKey helps slow that down. And I think that's a fundamental thing to understand is all these things are not like One all be alls. They're just a step in helping slow down an attack or help you think before. I mean, even a pop up saying, hey, or even something in your email say, hey, this person is external. Do you trust that person before you send this email? Right. These are all little tools to help you make a better decision for the security of your day. That's all it is.

Mid-roll CTA - 00:26:42: Hey, it's James Farrow here. Really quick. Well done for making it to the midpoint of the episode. If you're enjoying what you're hearing, remember to give us a follow. And if you're really enjoying it, please drop us a review. We'd really appreciate it. Thank you. Now let's get back to the episode.

James Farrow - 00:26:59: Yeah, absolutely. And I think it's important to bring up the idea types of attacks and what's actually happening for small businesses, for startups, right? And in my perspective, it feels like a lot of the market from the vendor side is selling on FUD, right? Fear, uncertainty, and doubt. And they're saying, hey, you have your car parked in your driveway and you need a SWAT team watching that car 24-7, 365, when in reality, you likely just need to lock your doors, roll your windows up and have a car alarm. And then if something happens and there's a break-in, the alarm goes off, you call the police, that's your incident response retainer, right? And if they steal something, you hopefully have backups, which you should have, and then cyber insurance, right? Just like your car insurance. And so it feels like 90% of the market is overkill for these startups and these small businesses. How does that resonate with you? Like if YubiKeys is one of the blocks, is it as simple as you have vulnerabilities, which is making sure your doors and windows are locked and then have a way to detect and respond to things? Or do we need all of these other complicated ways to detect alerts and things like that?

Ayman Elsawah - 00:28:17: No, I'm with you 100%. You remember LoJack? Yeah. Like, you know, tracking your car and knowing where your car is. I don't know if you've ever seen this video. Maybe we could find it, but like, I don't know if you've ever seen the video of someone trying to steal a car and then flames come out of the sides of the car. Have you seen that? That was in, I think, South Africa where carjacking was a really big thing. And so they showed this defense where like flames would come out of the sides of the car and. So it really depends on the security that you're trying to do. I don't believe in FUD. And again, it comes down to threat modeling. What are we trying to protect against, right? And so there's definitely overkill. I mean, like asking a small company to buy a SIM, for example, oh, you need to track all your logs and everything like that. Asking a company to buy a SIM and having them track all their logs when they're only like a 10 person or 25 person startup, no, but you could tell them, hey, listen, just turn on your logs, right? So before in AWS, Cloud Shell was not enabled by default. So a simple thing is just enable Cloud Shell logs, right? Now, thankfully, finally, AWS many years later, it's on by default, right? So, and I think the car, actually I've been using the car analogy lately. So, for example, WAF. Oh, should I have a WAF or not? Like, well, it depends on your application, how good your code is, how much traffic you're getting, right? You're a really small company and you don't have much traffic, then WAF might not be an issue for you. But make sure you have good code. There's a lot of built-in protections, like in Ruby and React, that protect against CSRF and some of these basic things. But for example, if your code is several versions out of date, I'm going to recommend you update your code versus getting some other external product to help protect you because you have bad code or you have bad code hygiene. Right so let's take care of the basics so back to the car analogy My thing is, listen, we all wear seatbelts, right? So you wear your seatbelt, you take a look at your tires, you make sure the tread is good, you make sure all the different things in your car are taken care of, right? But you still might get into an accident. It's possible. So, but the thing is you did what you can, right? And even if you look at the SEC, you know, did companies do what everything that they should have done, right? And that's the hard part in security. It's hard to really determine what should have been done, especially when there's a lot of pushback from executive management to like, hey, we don't have time to do this. So you're like Chicken Little trying to scream. And sometimes you have to resort to FUD, which is unfortunate. So however, if you don't put your seatbelt on and if the tread on your tires is really like bare skin and then you get into an accident, then what went wrong there? Right. So I think that's the way to approach it. Let's do all the things. Again, I try to live off the land. So let's turn on all the knobs and switches we can from all the tools that we have already that we're paying for. Right. Because a lot of times there's checkboxes just not turned on by default. And I kind of, I don't want to say blame, but I mean, right now, like FileVault is encrypted by default, right? So if you get a Mac, it's on by default, right? Sometimes people turn it off though. So that's good. There's a lot of things that are done by default. And I think the industry should do things in their software to turn on by default. And that's where I advise startup founders in their product security. Like, hey, you should bake in some basic security things like passwordless login and MFA and all that kind of stuff, bake it into your product. Like, It's 2023 already, almost 2024.

James Farrow - 00:31:56: So yeah, just it doesn't correlate to revenue. Right. And like, that's the tough part is like, that is something that is a nice to have. That is, it's almost altruistic. And if every company was defense by default, right, and they secure by default, then the onus of cybersecurity and all of those things would be a lot easier for the everyday consumer and the people in these businesses who are buying these tools if they are secure by default. But I don't think people are buying tools because they're secure by default. And so it becomes this chicken and the egg problem where like, why build it if people aren't willing to buy more of what we have to sell because we're doing that?

Ayman Elsawah - 00:32:40: So I've heard this so many times. Where, oh, it's going to increase friction for our users and things like that. Well, there are some security tools in your product. If we're talking about product security, there are some things you can do help reduce friction, like passwordless login. Like that's amazing, right? Just like not having to remember a password, right? But there are other instances where businesses have decided to take the risk of poor user security. So for example, where a user will create a login and reuse their password that's already been stolen So like one suggestion I usually have is in your product, when a user signs on, when they create a password, check that password with, have I been pwned to see if that password has been stolen or not? They're like, oh, that's going to increase user friction or whatever. So when they decide not to do that, what they're doing is they're willing to take the chance that in a credential stuffing attack, which is an attack where bots use recycled stolen passwords to try to get into an application. So they're willing to take the downtime and the risk of a credential stuffing attack versus taking care of ahead of time. I've seen that happen and that's a business decision. However, a lot of times not everyone is involved in that decision, but that kind of then falls on engineering. When they get hit with a credential stuffing attack, they have to like, tuned or bought things and it takes away from engineering time. So it's really like about deciding. And also there's an expectation of security in companies these days. So what's the expectation of security that you're taking? Because a lot of people, I tell people, you know, there's a lot of public companies that don't have a CISO or main security person. They're like, really? I'm like, yeah, there's a lot of companies that don't have someone in charge for security. So I guess, you know, what's the expectation of security from your users and from the community? To go back to your question, I guess, can you re-ask that question, or does that make sense?

James Farrow - 00:34:40: Yeah, it does. And it was the trade-off safety and speed. That's what I see in startups is they're choosing speed over safety and they're choosing to build things that are going to translate to revenue and security and secure by default doesn't seem to be that yet. And the market's not demanding that in a way that is forcing startups to build secure by default. I don't know if that's going to change in the future. I mean, what are you seeing? Are more consumers demanding secure applications or is cybersecurity still this wizard of Oz behind the veil sort of field?

Ayman Elsawah - 00:35:17: Yeah, so I guess if you're saying, what are the expectations for secure by default? I guess, how would you rephrase that company with that question? Would you say, what's the expectation from investors, from customers, from other businesses or consumers?

James Farrow - 00:35:34: From let's take B2B, B2B Solutions and B2B companies, Do you see a demand for secure by default? Or is this wishful thinking from people that care about the space and wanna see a brighter future? But not actually tangible in reality where people maybe they aren't asking for it. So people aren't building it.

Ayman Elsawah - 00:35:57: No. So my philosophy is that if we all take security seriously, we're all better off. Right. Because think about it. When I go log into a health portal, I have an expectation that my records are going to be taken care of. And there's some sort of security protection for my records to be stolen. You know, for example, there was a health care psychology clinic. Like a similar, like a better health, but in Europe. That had patient psychology records, transcripts of these records stolen and just out there. And the thief conducted was threatening the people to the actual users themselves, that they were going to release the data or the transcripts of their personal conversations with therapists. Like that's scary, man. So those kinds of things. So what's the expectations? So my personal belief is that if we all take security a little seriously, you know, we don't have to boil the ocean, just like, let's take it a little seriously. Then we're all better off as a society. Now that's like a utopian kind of view. But all the different roles, right? So if you're B2B, you can be guaranteed that your enterprise customer is going to have an expectation for you to do security, right? Why? So there's a few things. They want to CIA themselves. Right. Because in their policies, according to their cyber insurance thing, every contractor they deal with has to have this on the security things. So it's all trickle down effect from a CIA perspective. So that's one view. The other view is like, hey, if I'm actually going to use your product in my enterprise for my customers. I want to make sure you're doing the right thing because if you get breached, then I look bad because customers are not going to care where this really happened. They're going to care that my big Acme Corp enterprise had lost their data somehow. So from a business perspective, I guess the security person at the enterprise, they want to know you've done the due diligence. Right. So there's a lot of different hats in play when you say security expectations. To be honest, a lot of like from the investor and board perspective, they probably have the sometimes not to say, I've heard different stories, but like you might have board members that just, they wanna know they've done the checkbox security. They don't really understand like the security complexity. And at the end of the day, they're going to decide to do business versus do security. I've seen them like, hey, we really need to do this. I recommend we do this. They're like, we don't care. We need to make money. Yeah. So, you know, when the business is in survival mode and they need to like survive, Everything else falls down on the way, including security.

James Farrow - 00:38:44: Yeah. And so I see that from in terms of, you know, shifting our conversation from kind of the demand for secure by default to the influence of VC in the space. You work with startups every day and you're helping them with security. How much of the VC dollars influences the cybersecurity market, the vendor side, the startups themselves? What role does VC play in cybersecurity? And can you lift the veil for people who maybe don't think VC has any role in cybersecurity?

Ayman Elsawah - 00:39:23: I would love to. I have to say I'm not an expert yet on VC. I'm still kind of like learning about the field. It's interesting, the whole VC, VCs are interesting. It's kind of like a small club in a way. So generally, if a VC is invested in a security company, they're gonna recommend that company to be used at the other portfolio companies, right? So that's the first tier, right? So a lot of times, And then the second tier is recommendations. So if a VC has had a good experience with a security company, then they're gonna recommend them. But VCs are cost-conscious, right? Even though it may seem like there's a lot of money rolling around, But at the end of the day, they're going to do a cost evaluation. You know, like, are we getting what we're looking for the cost? And they're going to compare different ones. So as far as protecting their portfolio, I think a lot of times the conversation is not necessarily driven by VCs. To get cybersecurity, it's 50-50. I think sometimes the board might bring it up, the founder may be concerned about it, because there's a couple of different types of security. There's one, are we, can we just get the compliance checkbox done? And then the other one is after a while, after you've done the compliance, now do we actually care about security? And I love those, I love the latter ones. I've actually had the privilege to work with some of those folks where they've already done the compliance work, And then now they're like, hey, we're actually worried about getting a breach. Because we all know that compliance is not necessarily great security. And so I love that. That's been told to me several times. Hey, we're compliant. We have SOC 2, we're HIPAA, whatever, whatever. But I just want to make sure we don't get hit with a breach.

James Farrow - 00:41:17: Yeah. And it's like once they go down that rabbit hole, then they start to see the bigger picture, right?

Ayman Elsawah - 00:41:24: Yeah, because security is multi-layer. You're building a multi-tenant software, right? You want to make sure that one tenant doesn't get access to the other tenant. How do you protect that? Do you have bug bounty, right? Do you have a bug bounty program? This is now for like a more mature startup. Now we're talking like you're a little more mature. You had businesses, now you're expanding and whatnot. And so, you know, do you have a bug bounty? Have you been doing, I mean, pen tests, hit or miss, but I like bug bounties, right? Because bug bounties are continuous and they're in your product and things like that. Are you updating your code? You might want to go another step level, another level up and have encryption enabled within, you know, column level encryption in your database that's tied to your customers so that only customer A can access customer A data and customer B can't see the data. Say your S3 bucket gets leaked, right? If you have another layer of data encryption set up on there, then that's going to protect you in case that data gets leaked because, well, it's just going to be a bunch of gibberish, right? Because they still need access to he. So we've been talking about like base level security before, but then a lot of times we want to like level up our security. You've done the foundations, you're still not done. Remember, security is a journey. It's a marathon. It's, you know, pick whatever metaphor you want, but it's a continuous process.

James Farrow - 00:42:46: Yeah, and so I know we want to get some shorts. For LinkedIn and YouTube shorts and whatnot. And I think this could be a really good one. And so I'm going to ask you this question in mind that I think this would be a good clip. Can you explain to the startup founder who's thinking about cybersecurity, why checking the boxes for compliance isn't the same thing as securing their organization and their data?

Ayman Elsawah - 00:43:13: Yeah, so checking the box is only going to get you so far. But it doesn't go deep. Especially depending on the compliance framework that you're going through. Believe it or not, like compliance frameworks like SOC 2 are not a prescriptive framework. You can decide what the scope is and what you need to secure. So believe it or not, you can get away with a lot. You can be compliant, but not secure.

James Farrow - 00:43:39: How does that work? Why? I mean, what is just checking the box look like versus being secure?

Ayman Elsawah - 00:43:45: Yeah, so it comes down to scope. I mean, we could get deep into it, but basically checking the box means that you have a policy. Yes, I have a policy. Okay, what's in that policy? We go into details about what's in your policy. Have people understood the policy? Is the policy enforced? I mean, like, give me a break. In the policy, it says, if you don't follow this policy, then you could be fired and or your contract terminated. How many people actually do that? How many people actually enforce their policies? Like, let alone read the policies, right? So we want to have policies that one are actually in motion and they're actually doing being done, right? And however, We don't want to follow policy just blindly, right? So policy's there. As a foundation, right? And to help, you know, CIA in case something goes wrong, but there can always be exceptions, right? So you also don't want to be that person that's like, it's policy, we have to do that, but you're getting in the way of business, right? So you have to find that balance too.

James Farrow - 00:44:52: It's really interesting because I don't think a lot of people understand that checking a box for compliance isn't the same thing as being secure. And to your point, it says, do you have a policy in place? It's like, yes. But being secure means enforcing that policy and having systems and procedures and tools in place to detect people who are breaking the policy and having a playbook to take action on that. And that's what being truly secure looks like. It's something that I think needs to be talked about more often, especially for startups who, to your point, are just trying to check the box so they can do business with larger organizations. Right. And so they don't get hit with fines. But being secure is really where the focus needs to be. How difficult is it for you and your conversations with founders if they come to you and say, we just need to be compliant? Do you push back on that and say, hey, you need to be thinking about being secure as well? Or do you say, great, here's how I can help?

Ayman Elsawah - 00:45:54: Yeah. True security is about culture. So I tell them, And I have a whole section of my course just about culture. Because culture is really where true security is going to come into play. And we'll talk about that in a second. So a lot of times someone comes to me and say, hey, I think I love the most is like, I want to know my unknown unknowns. Great, we can do a deep dive and go through all the things and I'll give you a list of things to do to take care of your security. Now, if I come back six months or a year later and find that you haven't done anything in that list, what's the benefit of, that hurts me inside, right? Like us security people wanna see people like following our advice. And some of my best clients have graduated because they actually followed my advice and I helped them hire full-time CISOs. So it was like, it was awesome. So, but let's go back to security culture. Let's go back to checkbox. So, okay, let's go back to encryption, for example, right? So let's say we have the checkbox say device encryption is enabled. Great. Okay, cool. Now, but what if your users are downloading CSVs of patient data and putting it on their USB disks? Right. Now you have also a policy too. We're not even, we don't have to go that far, but say they're just downloading the data or, you know, emailing it and things like that. Again, you can have that covered in your policy, right? Don't email this information, things like that. But if we have a security culture, this is what I'm trying to get to. If we have a security culture, people are going to think twice about handling sensitive data and throwing it all around, right? If they see something being done incorrectly in a different part of the org, they're going to tell that person or tell the security or engineering or whoever it is that's in charge of security, hey, I think we're not doing this well. We should probably do it this way because the people that know the most about a system are going to be the employees, right? And the builders. A lot of people want to do the right thing from security. Sometimes they're not informed or enabled, right? And so if there's not a path, right? Take a look at the SolarWinds. I didn't want to go down that path, but like a lot of people inside knew that security wasn't being done correctly. Right. And so you have engineers, I've worked with engineers. They're like, we really need to do this. Can you help me, Ayman Elsawah? Ayman Elsawah, can you help convince manager this that we can do this? I'm like, okay, I'll give it a go because these engineers know what good security looks like. But a lot of times the pushback comes from the business or there isn't a culture or whatever it may be. Or some engineers just plain don't know. I'm like, do not put API keys in code. Like. Things like that. So my long answer, my antidote to checkbox security is security culture. I guess that would be it. Having good security culture, it's culture is part of the company. Just like in any startup, you have startup culture and the culture of the company. Every company has a different culture, right? Based on leadership. Same thing with security. It's the same thing.

James Farrow - 00:48:57: Absolutely. And where can people read more about security culture? It sounds like you put some things together.

Ayman Elsawah - 00:49:04: Yeah, I have a newsletter. I have a bunch of things. My newsletter is called Last Week as a vCISO, but everything Ayman Elsawah, I'm trying to consolidate it to coffeewitAyman Elsawah.com or coffeewitAyman Elsawah on Twitter. So from there, you could find my newsletter, you could find my company Cloud Security Labs. So you can find me on Twitter or LinkedIn. So coffeewitAyman Elsawah.com or coffeewitAyman Elsawah on Twitter.

James Farrow - 00:49:26: Yeah, and for the LinkedIn Power users who are listening, Ayman Elsawah, If they follow you, what sort of things are you going to talk about? What will they see in their feed?

Ayman Elsawah - 00:49:34: Oh, they're going to see a bunch of videos. So I have a bunch of videos just like this, where I just break down security into plain English terms. So yeah, definitely follow me on LinkedIn. And my feed is going to be littered with just security advice. I just like... Keep putting it out there. Sometimes I get a little, you know, snarky, but not all the time. But more like just chill security. Like, here's how it is. Not too complicated, not too curmudgeon. Actually, not curmudgeon at all. Actually, there's a lot of curmudgeon security out there. I'm trying to be the anti-curmudgeon.

James Farrow - 00:50:08: I love it. Chill security. I mean, that's so cool. Ayman Elsawah, thank you so much. This was awesome catching up. I can't wait to go back and watch this episode. And you just gave so many insights to startup founders and small business owners and made it really easy for folks to understand where they are today and some of the common pitfalls and some of the things that they can do to have a more robust security posture. And for the folks who are thinking about being CISOs or vCISOs, I mean, Ayman Elsawah's the guy that is really setting the bar. So thanks for joining.

Ayman Elsawah - 00:50:42: I appreciate it. Welcome to the Security Cafe. Join the community. Join, you know, I got some courses in community coming up. So love to have you. It's called the Security Cafe because I love coffee, as you can see. So. Coffee and security are the two things I like the most. Beautiful.

James Farrow - 00:50:58: Ayman Elsawah, thank you so much, man. I will talk to you soon. All right.

Ayman Elsawah - 00:51:01: Thanks a lot. Take care. All right.

James Farrow - 00:51:03: See ya.

Outro - 00:51:05: No BS Cybersecurity podcast is brought to you by cyft.ai. Remember to subscribe wherever you listen to your podcasts. On behalf of the team here at shift, thank you for learning with me.