Episode #98 - Network Penetration Testing 101

welcome to the cyber rants podcast
where we're all about sharing the forbidden secrets
and slightly embellished truths
about corporate cyber security programs
we're ranting
we're raving
and we're telling you the stuff that nobody talks about
on their fancy website and trade show giveaways
all to protect you from cybercriminals
and now here's your hosts
mike ratando
zach fuller
and laura chavez
hello and welcome to the cyber ants podcast
this is your co host
zack fuller
joined by mike ratando and laro chavez
today we are talking about network penetration testing
testing your environment to find the
ways that cybercriminals get in before they find them
so that's pretty critical
we'll talk about why
who should do it
cost consideration scoping
all the good stuff
but first we're going to kick it off with the news mike
hey good morning and welcome to the news
genesis market seizure
a warning that cybercrime no longer anonymous
the takedown of genesis market
early this month signaled a changing tie
to prosecuting cybercriminal operations
cybercriminals will continue to evolve
and work to revive the darkwood form
on another platform
however it's likely law enforcement was able to obtain
some of the actor's identities with the genesis seizure
which imposes a meaningful consequence for the actors
who may believe it's a cost free
anonymous activity
with each of these disruptions
authorities learn more about who the actors are
and these actors have to recognize that engaging
these activities increases their risk of
when they travel outside
their current country
this ties back to
there was actually a story a while ago
about a guy that was a big credit card ripper
from russia
wound up in the canary islands
the us fbi or whomever was there
picked him up
so lesson to be learned
don't keep your head
keep your head down
global cloud migration
security lessons not being learned
attackers on average
have been enjoying slightly more than six days
to exploit an unmitigated
vulnerability before security teams resolve it
despite research continuing to demonstrate
how cybercriminals begin exploiting flaws within hours
or even minutes
of a new security alert being disclosed
the time lag between a new vulnerability
being identified
and when the defenders lock it down
is particularly problematic in the cloud
per palo altos threat intelligence group
they have found that threat actors
are becoming more to adapt
at exploiting not just unpacked vulnerabilities
but also more common
everyday issues
such as weak credentials and lack of authentication
protections
from gartner
estimate worldwide
end user spending on cloud computing will grow
to five hundred and ninety two billion this year
that's a lot of money
even so analysis from palo alto suggest
important lessons about security aren't being learned
remembered and applied
according to its analysis of workloads
in two hundred and ten thousand cloud accounts
across thirteen hundred organizations
three quarters of organizations don't enforce mfa
for console users
researchers found sensitive data in sixty three percent
of publicly exposed buckets
and another finding from the report
just five percent of security rules trigger
eighty percent of the alerts
in other words
every organization has a small set
of risky behaviors that are repeatedly observed
in their cloud workloads
attackers using ai to enhance
conversational scams over mobile devices
this is pretty interesting
attackers are using ai to enhance conversational scams
such as the so called pig butchering
social engineering scams over mobile devices
pig butchering
for those who don't know
refers to an unsuspecting victim
the pig being tricked by scammers
into giving money for a promised hire to return
scammers fatten up the pig by getting the victim
to think that they are investing in something
investment or romance
and get them to move money into cryptocurrency
they're just using the same attack with the same image
ai lets the scammers
rapidly create thousands of attacks
that look different to each target
which makes it harder for victims to detect the scam
it really is a game of large numbers
the attackers want to send out these first messages
to as many people as possible
hoping to get a response
once they get a response
then they use ai to maintain that realism
with the target who responded
they may change clothes or change backgrounds
over the course of define campaign
and they now have the ability to run thousands
of different looking attacks
most of these conversational attacks
are targeted towards mobile devices
mainly smartphones
there has been
twelvefold increasing these attacks over the past year
pointing out that they have observed
roughly five hundred thousand a month
that's a lot
here's a scary one
ex employee password abuse
ten percent log back into
disrupt business
according to this report
nearly half of a thousand us workers surveyed the
abusing credentials tied to a former employer
after leaving the company
additionally
ten percent did so with malicious intent
according to the study by website password management
forty seven percent of workers surveyed
said they continue to access account
such as email
software and digital tools after after separation
password manager
also reported that fifty eight percent of response
indicate that companies fail to change their passwords
of past employees
password manager also reported
forty four percent of response said
even when their passwords were changed
they were able to regain access
company networks and resources
via someone still working at the organization
sharing access credentials with them
in addition to the fifteen percent or final
saying they had been caught using passwords
from their old jobs
one and three said they've been
using them for upwards of two years
let's do some cyber hygiene people
three flaws
one more dominated
cyber threat landscape in twenty
twenty two three
critical vulnerability
software exploits
fishing and stone credentials
kept exploitation at the top of the list
of initial access methods
in twenty twenty two
while the war between russia
and ukraine
and log four j
these these vulcan issues in the russia
ukraine cyber conflict changed the threat landscape
and resulted an unprecedented volume of tax
from a specific group of
threat actors
the volume of taxis in the russia ukraine conflict
for example
resulted in the government sectors
rise the top of list of targeted industries
only for twenty five percent of all attacks
investigated by mania
up from nine percent in twenty twenty one
when government ages
agencies rank sixth
on the list
meanwhile about thirty six percent of instance
investigated by many
include the use of software exploits
with four every nine of those attacks
targeting a vulnerable version
of log four j
according to the open source
the open source logging library
there's also an amazing
now this isn't the story
but there's a lot of log board log four j
that still hasn't been patched which
so if you've got that
patch it lastly
kubot expand
expands initial access malware strategy
with pdf wsf combo
recent surgeon
cuba trojan attacks has been observed
spreading via malicious emails
written in various languages
including english
german italian and french
the emails are crafted
using genuine business
letters obtained by the attackers
and urges the recipient to open it and attach pdf
which contains several layers of obfuscation
that make it malicious
maliciousness
less detectable by security tools
according to analysis
by kaspersky this week
the campaign also
used the method
of using reply
chain emails
to make it more difficult
for soon to be victims
the flag is malicious
its name suggests
reply chain
is the practice
of accessing
existing email exchanges
and replying to them
making the interloping messages look legit
less suspicious
and believable
some scary stuff
it's a couple good headlines for you
russian linked apt
twenty eight
exploiting the cisco
router flaws
there's some three
ios zero click
exploits used
by nsl group
in twenty twenty two
popular fitness apps
leak location data
even the user
set privacy zones
with that i think
we should have a
laura's corner
laura what do we got
mike thanks for the news
yeah some interesting headlines there
welcome to laros corner today
let's all sit
criss cross applesauce
cruise down the highway
with our tesla's on autopilot
as we learn
something fun
about the technology world
we live in today
which brings me to the topic
where this come from
well i had a friend ask me
lauro how come
i try to get
cyber insurance
and they're
not getting me
on my policy
because i've got tls
one dot one
and tls one dot o
still present
on some of my
web servers
and why is this coming up
and how much of a risk is this
so to answer that question
today i'm gonna talk a little about
about transport layer security
and secure sockets layer
tls and ssl
these might come up in
network scans
a lot of the
independent scans
would be done
by bit sites
and security
scorecard and
they may can
be used against you
to prevent you from
getting a good
insurance policy
for your cyber insurance
so what are these mechanisms in
and why are they impacting us
well i want to
first start
by telling you
this is not
a security risk
that a cyber
attacking criminal
as nso group
is going to use
to get into your organization
okay the attacks around
tls and ssl
involve decrypting
the encryption
private public key
that exchanged
just part of that
https tunnel
that you're doing
okay so those
those attacks
while made sense in a lab
and made sense
in the early
two thousands
really aren't prevalent anymore
and attackers
as you can hear by
mike's headlines every week
are really going
for more things
that are exposed
like remote desktop
protocol log j four
sending you a
fishing email
things that we know
are going to work
your browser
is automatically
going to protect
you against this
so why is it a big deal
why is this
coming up well
this has to do with
deprecated software
if you're familiar
with any of the
governance frameworks
whether it's pci
or nist emc
or cis version eight
they all talk about
deprecated software
and not having that
and that being
a poor practice
because it's
no longer supported
typically and has
weaknesses involved
and that is exactly
what this is
these are older
protocols that have
known weaknesses
and have been
replaced by a newer
updated protocols
that are being used
mostly everywhere
so why is this stuff
coming up well
it's residual
in your library
your server's web
can figure whether
you're using microsoft
is or apache
or engine x
they all have
the capability
to do this secure
handshake to give
the user https
but they also have
old libraries installed
just in case
somebody pops
out of a time machine
from two thousand and seven
and wants to use
windows seven
to connect to your web
application
they can do
so using tls
one dot o while
that may look
like a reverse
compatible edge
to have up for
the time traveler
compliance and
cyber insurance companies
highly frown
on you having
these older
libraries so
in order to
clear the debate
the best thing to do
is to just go
in those library files
and clean up
that old tls
and ssl stuff
that may exist there
so that the scanners
won't find it
and this cyber insurance company
won't know that
you have them there
even if they're just
rimmed out so
if you have is
you're gonna look
for this stuff
you're gonna
go into the is
services manager
you're gonna look for
the actual server
in your connection pane
then you're gonna pick
the server certificates
okay when you see the server
certificates
you're gonna go through
and make sure
that you remove
everything in there
that is not tls
once you've done that
you're gonna uncheck
your box for
require ssl
and then you're gonna
go and make
sure that all
the protocols
other than tls
one two are
not checked
pretty easy
it's all radio
buttons for your
microsoft users
if you're using apache
little more difficult
all the stuff
is in the httpd
comp file or
also in the ssl
got comp file
so you need to
go in there
and you can do attack
capital all
plus tls version
one dot two
and make that
relevant to
the preferred
connection which
it should be
there today
and then you can also
go in and do tax
to take out
some of the
other connection
protocols so
they're not
used by the
engine at all
and if you're
on engine x
you're lucky
because they
don't support
over protocol
so they don't care
about the time
traveler from
two thousand seven
so as long as
you're above
thirteen you're
not even going to
support anything
other than tls
one dot two
to begin with
so that's also an option
so again and
if this stuff
is coming up
on a pen test
you should question
the firm that is
pen testing you
if they're bringing
things like tls
to the front
of your report
so i hope you
enjoy the rest
of your day
and i believe
we're actually
gonna talk about
pen testing day
and that writes
that something
network pen tests
yeah that is
that is correct
we're gonna
dive in and
talk about that here
after a quick
commercial break
want even more
cyber rants
be sure to subscribe
to the cyber
rants podcast
get your copy
of our best
selling book
cyber rants
on amazon today
this podcast
is brought to you by
silent sector
the firm dedicated
to building
world class
cyber security programs
for bin market
and immersion companies
across the us
silent sector
also provides
industry leading
penetration tests
and cyber risk
assessments
visit silentsector com
and contact us today
and we're back
with the cyber
ants podcast
be sure to check us out
at cyber ants
podcast com
if you want
to get links
to the show notes
the articles
that mike had
walked through
and there are lots of
different resources available there for you
so please be sure to do that
if you would like to dig deeper into the articles
so with that
today i'm talking about network pen testing
we'll talk about external internal
we might save wireless for another day
who knows we'll see what kind of time we have
but that being said i want to start out just high level
i'm just going to breeze through this real quick
who should look at network penetration testing
if you're brand new to this
and you have a network environment
well do you process or store any
confidential information
excuse me do you
have any types of systems that your company relies on
probably the answer is yes
so if that is you
you should probably have a network penetration test now
it certainly gets more and more applicable
if you're in compliance regulated industries
if your organization has a very robust infrastructure
but that being said
network penetration testing
is one of those activities where
teams like ours
are using the same types of tools and techniques
methodologies that cybercriminals are known to use
to try to exploit your network
or see what is exploitable within your network
so with that being said
let's talk about some scope consideration
so if you're listening to this podcast
you probably already know
have some idea of
some basis of understanding
of network penetration testing
where we get a lot of questions
comes with the scope
and the scope is
you know what should be
what should be within scope
what should be tested
so let's talk about that a little bit externally
internally let's also touch a little bit about scoping
considerations for hybrid environments
right i mean
cloud environments
what if they're
they have on prem
networks they have
and maybe they have some infrastructure
an aws or azure
that sort of thing
so let's start there
anywhere you want to start digging in
you maybe start with external
keep it safe
yeah dive deeper
yeah that's
that's great
so external scoping is pretty simple
everything you've got touch
in the public internet of things
so if you own ip blocks
the easiest thing is to just provide a dns
typical we can
you know we'll do reverse lookups and find out all the
you know the astrid domains that you've got
and ips associated with the website you're hosting
so quite simply
it's always good to look at everything that you've got
that's touching the public internet of things
or the clarinet
whatever they want to call it these days
for internal
i think that
well let me
let me back up
for external hybrid
if you've got stuff in the cloud
that's pretty simple
amazon and microsoft both offer all of us white hat
consultants the ability to pin tested our leisure
we're just not allowed to do things like load testing
so it's a very good idea
to go ahead and run a network pin test for again
those devices that are up there
being fronted on the cloud infrastructure
doesn't matter if it's roku or amazon or microsoft
because they're not securing those
and we've had this talk before right
they're not going to secure those systems for you
you can still make a mistake that can
that can cause a breach
in a system that's sitting on aws
or azure or haruka anywhere
because you made a configuration error
so it's always good to take a look at those as well
and because those are gonna roll
we're probably
unless you've got a static ip
will probably just want to dns
that way we can
you know look at the machine that's hosting it
at the time for internal
i think this is where it gets a little more complicated
you know naturally
looking at everything internal is a good idea
sometimes that's not practical
because the organization is very large
so if you've got different components
and you're relatively sure they're all like for
like it's okay to do a small compartment
or a small sample set of your larger network
now there's
with internal
there are different considerations around
are we going to test specific ips
or are we going to test the entire range
in a subnet
for example
what advice would you have
on looking at the two different approaches
and when to choose one or over the other
yeah no good question
so a lot of organizations are going to an epp on
host solution
for not only all of your antivirus and mauer
but also vulnerability scanning
so they're getting vulnerability information
off the agent that's sitting on the host
and that's reporting back
and they're patching in things in that nature kind of
that's where it's moving to
what that doesn't do is
it doesn't tell you about unknown hosts on the network
or hosts that you don't have your agent installed on
so when you do an internal pin test
while it's nice to have the targets it does
i'll say this
if you have a large infrastructure
and there's a short amount of time
providing ips makes things go quicker
because the discovery phase is shortened
because now we know all the live hosts
when we look at the entire net block there
the scanners
and most of the technology today
has to go through several decision making steps
to understand whether a host is alive
and not responding
because of your epp
you know software that's running
or that it's just not there
so that does extend the time frame
and that's really kind of the benefit
is that if you do everything you
you understand what you might not be seeing
at the cost of time
it will take most likely longer
versus being provided a list of active hosts
you will look at what you know you have
but you might miss some pieces of the infrastructure or
pieces of technology
that may not be a part of your
internal security software
a good point
i always like to say too
you got to think about budget in these conversations
and there's a diminishing rate of return
at a certain point
on your investment in penetration testing
so it's a good advisor
will help you determine where that is
and what applicable amount of testing might be
i know in internal testing before
for larger organizations
that have vast internal networks
we've talked about maybe looking at certain segments
year over year
so maybe we rotate through
the network over a number of years
or take their best sample sets
look at those
and if they have similar configurations
across the organization
it can be determined that well
if we're finding this vulnerability is prevalent here
it's probably prevalent elsewhere in this environment
so always think about where
where you're gonna get the most for your money
and that doesn't always mean testing the entire
internal network
cause that could become cost prohibitive
and and time
i mean some of these
big internal nest network test could take you know
six months or more
would that be safe to say
with if they're
if they're looking at everything
especially yeah
and some of the larger places
yeah absolutely
i mean there's some things you can do really quickly
and you know
if they're using active directory
and they're you know
using older services
smb services
then yeah you can make
you know obtaining
domain admin or user account access relatively quickly
but that doesn't
that's one aspect of risk right
and i think a lot of the testers go
right for that
let's get domain admin
and we will capture the flag
we're good to go
you don't really do a lot of justice
to the organization
by letting them know
what are the risks
live there from the other technologies they may have
that aren't accessible via domain admins
so the longer
the longer the
you know the more thorough you are
again it's science right
from my perspective
the more thorough you are
the better risk results
you have to make a risk based decision with
yeah it's terrible for somebody to come in
to be able to use
use something like
a crack map exact
to pull your domain admin
and enumerate that
and then log into a system
and you know
now the game's over
but that could be such a limited
pinhole site
of the entire risk to the organization
right so yeah
i now turn off smb
and now see what the next layer
of security risks are to the organization
once that is removed
good point more
holistic approach
the other thing that we've run into
of course is
there are i mean it
people have a ton on their hands as it is
so you think about well
what do you actually have the ability to remediate
at this point in time
and where do we want to look
if you look at the entire environment again
you're going to get a huge
list of issues
and now it's on you to fix that
so consider that as well
where the most critical assets and such
throughout the environment
and you know
because again
everybody in the
in the mid market space
emerging companies
space their
always limited time
and money to do these things so
switching gears a little bit
we talked on our previous pen test episode
focused on web app
we talked about the different approaches
black box gray box white box
can you give a little background on
the different approaches
as they relate to network pen testing
whether it be on prem network or cloud environments
yeah absolutely
so by fox pretty simple
you know it's a
it's unauthenicated
we're we're gonna come and find you
just like you know any cyber criminal
what would come upon
you know a scan result or something like that
so the difference being
is that you're gonna give us a scope because we
we wanna stay within a line of your business
of course right
so we're gonna have a little bit extra information
um the gray box may uh
will include things like if there's a self registration
on the network or um
if you've got like an ftp server or something like that
and then a white box um
externally would include giving us access to maybe
like inside of a vpc
if you've got in uh
you know amazon or
or or microsoft's azure
or in you know
access to your
your kublet pods
or you know
something where we're already inside
and we're getting a purview
of what an authenticated attacker may or may not have
once once accessed to your
to your inside network
um when we're doing on prim stuff internally
typically you know
we want to look without on authentication
so when you do your internal pin test
you kind of want that to be black box
because the
on an active directory network
right the very
quintessential obtainment is to be domain admin
so there's a lot of ways to get that
without actually having to have a user account at all
but the next level
you could use in
you know as a white box scenario
would be to provide a user account
to make sure that the roll based axis controls
you've deployed
are working as they're designed
or if you're inheriting it
which is probably what
ninety nine percent of you are doing
and you've inherited an active directory network
and you're not sure
because it's complicated
and it looks like a hairy mess of spaghetti
that's a good idea to do a white box
because then you can
you can kind of decide what
what roles in groups
may have too much access to your network resources
versus should
and who should not
high level here
so with black box
of course the
organization being tested
doesn't have to have a lot of involvement right
it's going to be tested from anywhere
let's so that's
that's fairly straightforward and it's
it's up to them
and the testing team
of how they want to do that
whether they do
you know a true red team
blue team approach
both kind of working in their own bubbles or the
the purple team approach
where they're communicating throughout
so that's all good
with the internal side
you have an extra step right
we're going to send a box
that's going to go in that company's environment
and connectivity
will you share a little bit about that process
how it works
how that connectivity is gained
and then the security behind that
to ensure that that box is being used for
the good guys and not the bad guys
yeah absolutely
so um i i can't speak to how a lot of firms do it
i've encountered
you know similar activities but
but but the nature of of
you know our process is to send you
a pre engineered mac mini
and that's gonna go in your
in your internal network
and you're going to provide a one to one nat
from our tester ip
you'll have to create
a firewall rule from that tester ip
to translate in through your firewall to that
that engineered mac mini that we sent you
and now that we've got a one to one rule
just from the tester ip
whose ip is dhcp
so you may be contacted once or twice
during our endeavor to change that ip
um we found that a static ip
a lot of firms may use a static ip
hosted someplace
anything static is gonna get attacked
and scanned and indexed on shodan
so we wanted the nature
of our communications to be slightly more secure
so we we kind of disguise our testers in the natural
dacp environment of
of everywhere
but that's really
you know the security paradigm is that there are
there's a rule at your firewall
allowing only a limited amount of testers
and their specific ips in
to access this device
and that the firewall also
is not allowing any external ports out
that you know
services like twenty two or things like that
that we may spin up on the box
but may not necessarily need to be accessed
through the firewall
as an example
so that's i think zach was probably
you know maybe high level enough
enough or not
no that's perfect
i mean that's the
you know there are questions
certainly about
well what if
what happens if we put a box in our environment
and then you're connecting remotely
and what you know
what kind of risk is that
show but that's
i think you said it well
on a dhcp and having those rotating ip addresses
can actually add an additional level of security
not to mention
you know of course
multi factor and such
to get into that box in the first place
so various levels of protection
so it's not something you need to worry about
i mean i think the
the chances of an attack coming through
that methodology
and that approach
would be you know
an attack from a black hat hacker would be
tremendously slim and chance so
so anything else that you would say
about the testing approach
or kind of what needs to be done
from a setup perspective
or involvement perspective
from the company that's being tested
for internal testing
you know you need to have it standing by
to make sure that they're available to you know
change ips on the firewall
and also create the firewall rule
that's going to be required to for
for our team to access the box
or the pin team to access the box
then the other thing is that
you want to make sure that the internal pin test system
is in a network that has access to all the networks
that need to be tested
a lot of times
if you're testing just a solid scope that
that may be fine
but if you're testing an entire network
or multiple networks
you want to make sure that it's positioned in a place
that does have access
otherwise you'll have to power it off and move it
and they'll
maybe new firewall rules that need to be enacted
and so i think that's
that's probably the bigger challenge
initially with the internal pen testing
is just making sure the device is positioned
in the right network to have access to all things
and that it is
okay with standing by
to make changes to the firewall role
and also enacting the firewall to give access yeah
and i think with most of what we're seeing out there
most organizations are able to test
from a central location
but from time to time
the box does have to be moved
but i'd say with mid market size companies
usually it might be once or twice
you know maybe three moves max
but it's not certainly not a deal breaker
and again it just comes down to determine well
what's the best
return on your investment of what you're testing
and where and for how long and such
so well any
anything you'd say
any interesting stories
you mind sharing some of the
things that have popped up in different tests
that you found
say some of the interesting findings
whether that be external or internal
yeah sure they weren't
they're not tls or ssl
i'll tell you that
so i've i found quite
quite a bit of interesting things
i found old
pintest gear from other companies that had s that
you know like
the old way to do it was to put a box internally and
and have it ssh home something
and that ssh port stays open
and so we've ran into old cali linux
that you know very old that they've had access to
there's always something
there's always something living there
that you never expect
and one of the items that i found on an internal server
was you know
i was like everybody else
i'm trying to
you know look at
trying to get you know
hashes from the domain admin and users
but that turned into
looking at some of the web applications
that they had access to internally
and one of the web servers
on the root directory had an xml file
in this xml file
and it was just sheer curiosity where i was like
you know let's just
this interesting
let's just to see what's in the xml file
it happened to have
all of the domain admin passwords
there were two domains and there were
about four different root password
to the various erp systems and big
big kind of back backend systems that were being used
and this xml was being used by other applications
to come in and have access to you know
credentials to log into these systems to do machine
machine kind of tasks
but they had left it on there and i'd found that
and so that was
that was a fun one to find
and it doesn't happen very often
there's a lot
you know initially there was a lot with rdp where
you know the rdp protocol was weak and you could
there were exploits
that would allow you to get access to that
since those systems pretty quickly
i've seen an organization that was extremely secure
but they left the idrac
their system
that controls all the power to the server racks
with the default login
and you could just shut down
the power to the server racks and
and i might add that
that while i find all these curious things
i want to state that there's a
there's a lot of ethical concerns
i have with some of the reports
that i've seen from other organizations where
like if we like
we found like
i found these domain admin passwords
and these root passwords
i'm not then
going forward and logging in with these root passwords
right and creating further chaos
i'm simply capturing my evidence
is the proper technological scientist i am
and immediately contacting the owner
in a purple team exercise
and saying hey look
this xml is kind of sitting here
you should probably move this
instead of you know
going and creating a big spaghetti mess
that might be worse to clean up so
that's it that's this
i think of some more stories
but i think those are probably good for now
yeah yeah that could store
war stories
could probably be a whole episode or many episodes
so maybe that's
maybe that's another day
but yeah it's just
that's really interesting
i think just the volume of stuff
that often comes through internal testing
and we get a question a lot about
frequency of internal testing
so for a lot of
and again companies
limited resources and such
a lot of times what we see is them doing
external pen tests at least annually
and then oftentimes internal every other year
and that seems to be a pretty good tempo
i mean again
the answer to the right tempo is it depends
but it seems like that frequency has
become fairly standard
for a lot of organizations out there
more so than any others i've seen
is that is that what you've seen
for not only for compliance
but just best practices
yeah i think so
i'll you know
mike you know
jump in with sock ii stuff
but i mean we even
we see organizations that are doing continual
pin testing
right because the changes
that are happening in the environment are so often
so frequent
that it just warrants another pin test
to make sure there's no new risk
other than pci
there is really no compliance requirements
talk to doesn't require you to do a pen test
unless you said you're going to do pen test
and can prove their viability
so i mean for my recommendation
it needs to be a minimum annual
it should be after every major change
just you know
just out from a risk analysis perspective
so if you're running
you know software application that you've developed
or if you've
you put in input on a new hardware or something
you really need to pen test a new perimeter
and new application
but you know
from compliance perspective on pci
requires internal
require segment
network segmentation
that sort of things
for validation
but you know nist
again recommendations
hippa recommendations
sock to if you've decided that
as part of your risk um
so it all depends on the framework you're adhering to
that being said
frameworks on one side
mike over here and laura over here
get pentest any
every year at least
that that that's just common sense at this point so
and it's becoming currency
um i had a conversation with a customer yesterday
or the day before that said
i don't really need pen test
i don't think i need them yet
he's getting
every one of his security questionnaires is coming
when was your last pen test
when we last pen test
when we last pen test
so it's just becoming a requirement
and get a good one
not an automated one
not a you know
get get some
get some human logic behind it
that's that's what i would say about those
yeah thanks mike
and you know you
you nailed it
like pci is gonna tell you to pen test after
significant changes and
and that's kind of a loaded term
because they don't
they don't define what a
significant changes for you
they give you some guidelines
but if you don't have it defined
an auditor like michael
coming to eat you alive
if he you know
feels like it
because he's gonna point to the change log and be like
this was a significant change
this was a significant change
where's the pen test results
and if you can't
produce a document that defines what your organization
believes a significant change is and is not
then you're
you're gonna be
you know caught in an audit
cis version eight has a specific section on pen testing
you know my thought is
you know along with my
you know right in line with mike's
is it once a year is a minimum
but honestly
if you're making a lot of changes
and there's a lot of moving parts in the organization
the more frequent you do
it the better risk decisions you'll have to make
you know risk information on
how to make risk based decisions on
and not have these unknowns about
well did this stuff change anything
because like zach said
our tests are pointing time
these tests or point in time
they look at a set of technologies as they exist
as we look at them
if you make one software update
or one change to a permission or move another server
that invalidates the testing and it should be redone
well that's good
i mean this is
there's probably a lot of different areas
that we could go into more specifically
but i think the purpose of today was really
a high level overview of penetration testing
for those people that are new
to stepping into this type of engagement
so any final words
wisdom or thoughts ideas
recommendations for the listeners
avoid ai mobile chat issues
like we talked about in that story
some random person texts you and says i want to be
get to know you really really well
and i've got this great investment plan
probably not a good idea to follow up
probably not yeah
be on guard out there
and i thought i was really onto something here
they only wanted a hundred thousand
and they could return a million
and i thought that was good return on investment
so you're saying i should not send that money
no i wouldn't i wouldn't
and even if she promises to love you forever
i still wouldn't do it
it's my my days ruined
thanks mike
hey well i was able to pick up an old chuck e
cheese thursday
i was able to dig up an old chuck e
cheese animatronic at the dump
so i'm looking into attaching the chad gpt
three five engine to him
so there you go
that'll be well
be sure to post online
and speaking of posting online
for those of you listening
go rate us subscribe
share the episodes with your friends
family neighbors
even people you don't like
just share this stuff out there and help us
make the world a more secure place
at least when it comes to the use of our technology
and we thank you for listening
we'll see you on the next episode
pick up your copy
of the cyber ants book on amazon today
and if you're looking to take your cyber security
program to the next level
visit us online at silentsector com
join us next time
for another edition of the cyber rants podcast