TABLE OF CONTENTS
Talks & Speaking Engagements
Upcoming TalkTalks and PresentationsFederating AWS IAM Authentication using STS and ShibbolethTranscript: BSidesSF 2015 - Federating AWS CLI (Ayman Elsawah, Paul Moreno)InterviewsNo BS Cybersecurity Interview by James FarrowTranscript: No BS Cybersecurity Interview James Farrow & Ayman ElsawahHow Internet Safety Experts Protect Their Kids Online by CyberFareedahRSA: How Do You Protect Data on Endpoints | Cybersecurity on the Street | InterviewsRSA: How do you protect your remote employees? | Cybersecurity on the Street | InterviewsWebinarsHow to Ace SOC 2 for SaaS Scale UpsWizer: What You Need To Know About Restoring From A BackupWizer: What is Phishing Simulation and should you phish your own employees?TalksBSides Knoxville Keynote: Why We Break Things… The Neuroscience Of Hackers!Sam Bowne: Cloud Security Overview and Infosec CareersPacific Hackers: Applying Pareto’s Principle To Securing AWS Organizations
Upcoming Talk
Cybersecurity For Startups
December 2nd, 2023
Talks and Presentations
Federating AWS IAM Authentication using STS and Shibboleth
- At Pinterest I created an SSO helper tool (in Python) using STS, Shibboleth (yeah I know), that would provide temporary access to engineers.
- No one had anything like this available out there it was beyond it’s time.
- I discovered a bug in their metadata system that made calling STS a problem

Transcript: BSidesSF 2015 - Federating AWS CLI (Ayman Elsawah, Paul Moreno)
(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
Interviews
No BS Cybersecurity Interview by James Farrow
Transcript: No BS Cybersecurity Interview James Farrow & Ayman Elsawah
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.
How Internet Safety Experts Protect Their Kids Online by CyberFareedah

RSA: How Do You Protect Data on Endpoints | Cybersecurity on the Street | Interviews

RSA: How do you protect your remote employees? | Cybersecurity on the Street | Interviews

Webinars
How to Ace SOC 2 for SaaS Scale Ups
Hosted by Sprinto, I was asked to give a talk regarding my experience helping companies with their SOC 2.

Wizer: What You Need To Know About Restoring From A Backup
MC’s by Brian Haugli, I was invited to talk about the importance of restoring your backups.

Wizer: What is Phishing Simulation and should you phish your own employees?
A great discussion where I share my thoughts on conducting phishing tests or not on your employees.

Talks
BSides Knoxville Keynote: Why We Break Things… The Neuroscience Of Hackers!
A highlight of my career, I was invited to BSides Knoxville to give the Keynote. I was able to share my research in Neuroscience and combine it with my experience interviewing and learning about people’s journeys into the field of Information Security (aka Cybersecurity).
A highlight of my career, I was able to combine the my research in Neuroscience with my experience on the Getting Into Infosec Podcast and present my findings and reflections.

Sam Bowne: Cloud Security Overview and Infosec Careers

Pacific Hackers: Applying Pareto’s Principle To Securing AWS Organizations
