so thanks for coming along everyone um
so just to kick off a bit about me i'm
jamie mcdonald and i'm the head of
security at rasa
um rasa build a conversational ai
platform which basically means we build
kind of an infrastructure layer that
people build chat bots and virtual ai
assistants things like that on top of
um
so my team works on both the security of
the organization itself and also
application security since some of our
enterprise customers have quite
stringent requirements for light
security and compliance as well
previously i worked at fortinet and zone
fox doing security engineering
so my talk today is about building a
security function at a company and it's
from the point of view of a kind of
hybrid startup with a big engineering
function
that builds a product because that's
what my background is and it's kind of
one of the most challenging places to
insert a security culture
um
this is a shameless attempt to warm up
the crowd with a picture of cats and my
cats before i get into the body of the
talk hopefully that works
so
to start with uh we'll take a quick run
through the kind of business aspect you
need to consider if you're in a role
either as the only um
security person in the business or if
you're in a role where you're kind of
the head of security you're starting off
a team
um
the business stuff is just as if not
more important than than all the
technical stuff because that's what
keeps you on the right track and keeps
you aligned with what the business
actually wants you to be doing
and then the second part i'll move on to
the practical bit so these are actual
concrete things that you can implement
and kind of the key themes that you're
looking
to achieve um i'll give some examples of
tools that you might want to use as well
they're not endorsements of these tools
it's just kind of examples of things
that you might be wanting to use
and all of this is aimed at the kind of
context of quite a small company quite a
lean team um where you're kind of in a
high growth environment and a lot is
changing you need to get a lot of stuff
done so bear that in mind that this is
not also uh
gonna necessarily be correct if you're
in like a big business or an enterprise
kind of scale because different contexts
need different approaches too
so to kick off the business stuff i'm
going to introduce some hard truths to
bear in mind that will help kind of
ground you and help kind of align you to
what the business is wanting you to do
as you kick off might seem a little bit
harsh um but hopefully it'll make sense
as we go through the rest of the content
nobody cares about security
so this is the hardest one to accept for
most people here because people here are
going to be genuinely passionate about
it and you probably all wish that people
would take it more seriously
in reality if people do take it
seriously people know it's important and
but if it gets in the way of them doing
their job and it inconveniences them
they will try and strip it out or work
around it to make their lives easier
so
your job as a security person in a
business
is to me is to facilitate people being
able to go about their jobs in a secure
way um ideally in a way where they don't
even notice because you've made it so
serious
the point of the business is not
security now the only place this doesn't
apply is if you actually work for a
security company or a vendor but for the
vast majority of organizations security
is not the point of the business
so day to day it's not really anybody's
number one concern apart from yours
and this one's really important to
remember because kind of projecting a
sense that security is the most
important team um in the business it's
just gonna make nobody want to work with
you
you're not there to say no this is a
really important one um
so unless the company you join is made
up of people who are fresh graduates and
they've never worked anywhere else
before um people are going to have
preconceptions about what a security
team in a business is
um and almost certainly that
preconception is going to be that you're
the team that tells them that they can't
do stuff
so remember my last point you're there
to enable the business to work securely
um
in the vast majority of cases you'll be
able to work out a way that people can
do the tasks that they want to be doing
securely
if you just say no to everything to try
and eliminate as much risk as possible
um
people are just going to go behind your
back and do it anyway they're not going
to stop doing it they're just going to
stop telling you that they're doing
these things
and in almost every case your job isn't
to prevent people doing things it's to
work out a way that they can do the
things they want to be doing and
securely in a safe way so work with
people not against them
the final one is crucially important as
well
end users aren't stupid and you
shouldn't treat them like they are
because they'll really resent that um
they might not know as much about
security as you and they might do things
that give you anxiety but protecting
them and enabling them to work in a
secure way
it's why you're there in the first place
and so much of the groundwork for
building a security program um is about
establishing the relationships to people
and if you just crash in and tell them
that you know better it's not going to
make you any friends stolen it's going
to make your job a lot harder
so
once you've accepted all that the first
thing you need to do is work out where
you fit within the business that you're
part of
so
if you're lucky enough to be in an
organization that really does care about
security and other than one that just
sees it's a tick box or a formality this
is going to be a lot easier
now the goal here is basically to work
out what the business or the exact team
or whoever's in charge actually think
that you're here to do
because once you understand what their
priorities are um you can then work out
what security measures or controls help
support those aims and that's the best
way to start because if you kick off by
solving existing problems that people in
the business have it's really obvious
that you're providing value not doing a
good job
and this is arguably the most important
part of starting off your program as
well
um because this is where you engage with
people to find out what the problems are
and you make friends that will help you
further down the line and you really
important to start off by being the team
that solves problems for people rather
than the team that enforces controls and
makes people's jobs harder
so part of this is working out your
business's threat model and your risk
profile
so if you go into a small org where the
main concerns phishing or password
security don't start off with reverse
engineering malware you found in
assuming that they need to defend
themselves against like nation state
epts
this could be fun sure but you're not
going to last very long because you
haven't understood the problems the
concerns of the business and that they
are paying you to mitigate and solve
so
make sure that you start off at the
level the business is already at um
for a lot of organizations that does
mean that you're going to be kind of
hand holding them through rudimentary
basics as first steps but the first
steps are what you need to begin with to
be able to build towards a mature
security posture
so
this brings us to the foundations of
actually starting your program of which
there's kind of four key areas
communication tools processes
so the idea of communication is to be
approachable make sure other teams know
what you can help with what you're there
for and i can't stress enough that other
teams need to see you as a helpful team
rather than one who hinders your
progress and if you can achieve that
early on it makes everything else that
you're going to do a lot easier
you're going to need some standard
processes and playbooks that define how
security works for you it might sound
like a very kind of enterprise way um to
start off but it doesn't have to be your
company's infosec policy could literally
just be a single side of it for um if
you wanted
you're obviously gonna need tools to
help you out and but it doesn't
necessarily mean you need to spend
hundreds of thousands on like um big
vendors um a lot of what you need can be
found into open source or done on a
budget i'll talk a bit later about what
kind of tools you might wanna you might
wanna look at deploy
and last but not least as a team
you're not necessarily in fact you're
probably not going to end up with a huge
team you might not end up with any team
it might just be you
um but kind of knowing what skill sets
are available and how they could help
with the things that you're going to
work on is really important
and there are more kind of roles and
specializations within security that
most people realize especially as you're
kind of starting out your career
so i'm not sure how well this has shown
up for the people at the back um
but this is a really good illustration
of just kind of how varied and extensive
the areas of responsibility within
security are
if you're going to be leading a security
function you need to be aware of all
these you don't need to know them all
you don't need to be an expert them all
but you need to know that these things
exist
so that when it comes time that you need
something from from one of these other
areas or or you can recognize the kind
of the points where these things start
to become important or relevant
i'm not going to go over this whole
diagram in depth because that's going to
take up the whole hour um but once you
understand the environment that your
business is operating in and what the
security needs are
um
look back at this and kind of it will be
more obvious as to what areas you can
pick out as the key priorities and the
places that you need to focus on first
in general i'd suggest that a lot of the
kind of enterprise risk management and
governance stuff down at the bottom
right is not a great way to start off
and it quickly becomes kind of really
bureaucratic time sync and you deliver
more value more quickly by focusing on
things like access control and 2fa
but overall in in a situation where
you're kind of just starting off your
program if you're if you're going to um
grow your team you want to try and find
a really good security generalist
to help you who can focus on any of
these tasks based on kind of the
priorities of the business um security
engineering security ops those sorts of
areas um
and that will help you focus on the
first task which is securing the
organization because if you're an
that builds product an insecure
organization cannot ship a secure
product so you need to focus on the
organization first
[Music]
so
we've got some idea of the kind of
business environment that you'll be
operating in now um and it's always
worth clearing this in mind because
thinking about what you're doing in the
context of the business it's going to
make you a more valuable employee and
it's going to find it you're going to
find that it makes it easier for you to
make progress
through your career so i'm going to move
on to the practical side so actually
implementing the program there as well
so your security roadmap is again a
long-term vision of where you see the
security posture of your company going
and long-term how you expect to get
there
so for the kind of company i'm talking
about which is a kind of large
engineering team you ship a product to
customers and i split it into three
broad themes and you can categorize most
kind of initiatives and controls under
these
and they are the organization product
and the infrastructure
so the org pillar covers things that
affect all the staff and act across all
the business
so this is things like policies
processes password managers and actually
kind of establishing the security
culture for the business as well the
product pillar covers all aspects of
security that relate directly to the
product that you build
so this is things like application
security
tooling for developers and code scan
and then the infrastructure pillar
covers any kind of on-prem equipment
that you might have cloud services
making sure that you're aware of your
overall attack surface and that you're
monitoring it as well
and breaking the initiatives down like
this and can help you plan and
prioritize what's required
to build your security program
so for the rest of talk i'm going to
discuss the kind of things you might
want to put in your roadmap and then
we'll wrap up with what you should do
with your finished roadmap and how to
proceed on from there
i'm going to start with policies and
processes because
it's the most boring one
and i know for certain a lot of people
here are going to think that it's kind
of a thing you only need to care about
if you work for big banks but it's
unfortunately not the case
so you need to be aware of this for
companies of all sizes it's not just an
enterprise thing
and if your company sells to other
businesses you really quickly find out
that these things are just
non-negotiable and that you have to
answer security questions about your
products and your processes and if you
have docs and policies that you can pull
out to answer these questions it makes
things much smoother and much more
seamless
so
what kind of policies you actually need
to start with
um at a minimum you want to have a kind
of general infosight policy that
basically defines
what you expect and require for your
employees this could be things like
using 2fa enforcing
disk encryption on devices password
managers things like that
and this should be a readable document
it shouldn't be long it shouldn't be in
legalese it should be straightforward
and simple for people to understand
you're also probably going to want some
kind of data protection policy that
outlines like the kind of controls that
you have to protect data the fact that
you use these privilege
controls
to manage data access and things like
that uh requiring encryption for
personal data and who to go to if
there's a problem or a data breach
and when you're working out which of
these policies you need and which ones
to work on first
one of the first things you should
consider is if your business has to
comply with any kind of compliance
regimes like gdpr and things like that
this depends on what you do and what
kind of data that you process
but it's a really good way to direct
your attention to kind of the most
important and impactful things to work
on first um
if you don't need to comply with
anything specific think about maybe your
customers that you're selling things on
to do um
if you're selling to any other business
you're they're going to want to know how
you comply with gdpr even if you don't
think it's relevant even if you think
it's interesting not that interesting
and
you have to have documentation that
explains how you deal with this because
they need that to be able to pass on to
their customers
it's really difficult to sell products
to other businesses now without having
shown that you've thought about privacy
you've thought about data protection
data security
and if you're able to answer sales
questions with things like yeah we've
got a policy for that here it is it's
much easier and it just makes things go
a lot quicker
but also don't go nuts with it you don't
need policies to cover every possible
scenario
or every possible compliance regime
the aim of the policies are to make
things easier and to be useful and help
with answering people's questions not to
kind of drown you in pointless paperwork
and bureaucracy
so
now that you know what policies do you
need how do you actually start writing
because that seems like quite an
overwhelming thing to have to do to
begin with how much detail you put in
luckily there's a bunch of frameworks
and industry bodies that can help with
that
so there's nist who are an american
government body they publish a huge
amount of documentation and standards on
building security programs and even kind
of down to technical controls like
encryption specifications and the kind
of thing you should use
there is sans who most people here will
probably have heard of um a training
body and they provide a lot of sample
templates and that are kind of just like
basic boilerplate and that you can slap
your company name on and you can make
little tweaks here and there and to
match the context that you're in
there's cyber essentials um now this is
a uk government effort who's out of
cyber
essentials most people
um
so it's not
policies in itself but the kind of the
controls that they recommend and and
require are a really good way for you to
kind of direct
what you want to focus on first
because these are kind of the main
things that other companies will be
looking for
and cis benchmarks again they're not
policies as such but they're kind of
like the authoritative standards on
controls and configurations for
basically any kind of system you can
imagine operating systems cloud
providers um
that define kind of the controls you
should have the configuration you should
have for best practices um and again use
these benchmarks to inform the technical
content of the policies that you write
and also gitlab um so they can their
stuff can be really useful when you're
working out what they need um
because gitlab publish online publicly
all of their internal policies their
employee handbook everything and they
have a really mature security posture
and so it's really easy to kind of see
where you want to end up by using some
of their content and to help inform kind
of things that you're writing as well
and you can write them from scratch if
you want but it's difficult to know
where to begin um so i kind of recommend
just starting off with a sample one that
someone else has written like the sans
ones and just making little tweaks to
suit your business and the controls that
you want to introduce
um i'm gonna mention a lot of tools in
the rest of my slides but first a little
bit about how you could go about picking
any of these tools um
that you might have on your radar so
this is a controversial one
and it's specifically aimed at the kind
of startup or up environment and
where you don't have a lot of time you
don't have a lot of people to help
maintain things um
so wherever possible if you're buying
security tooling prefer options that are
sas or managed by a vendor
and the main reason for this is if
you're self-hosting an important tool
there's now loads of other costs
associated with that that weren't
immediately obvious um necessarily which
i'll go over in a second
but at high level the main reason that
you're employed
is to provide value to the business
right
your value with the two comes with your
ability to operate and interpret the
results and the alerts and act on on
things from that tool it doesn't come
from adding another system that you have
to patch and maintain and backup and
things like that because that's not what
you're there for
um
one tip for the process here
is when you're speaking to vendors ask
if they have other security
documentation or compliance certs or pen
test reports and things that they'll
only disclose to you
with a non-disclosure agreement so most
companies will have kind of the security
and privacy page on their website
there's nothing exciting there usually
the juicy stuff is the one that you have
to sign the nda for to be able to see
they won't announce that to you probably
but if you ask for it they're usually
more than happy to give you this kind of
stuff and that gives you a really good
idea as to what their internal security
posture is like and it gives you an idea
how they look for vulnerabilities and
issues and how they resolve them as well
a vendor who can't give you information
like that is a bit of a red flag um so
when i say use sas meaning like use it
safely don't just buy anything you can
find because someone else is running it
for you
i also want to quickly go into
some of the things that are kind of
often overlooked when you're working out
whether to go with sas or whether you're
going to self-host a tool
and explain a little bit more about why
i lean towards the idea of sas being the
way to go for your growing business with
quite kind of lean team for operating
things so when you've done your initial
comparison you've probably looked at the
slightly cheaper license fee and the
cost of running a vm on a cloud provider
and you're like that's how much it would
cost us to self-host it
but it's not really as simple as that
and there's a whole bunch of other
things you need to factor in that the
vendor is probably our competent vendor
is probably running for you um
transparently to you as part of the sas
service
so there's a few things you need to
think about
uh your time which is as a security
person expensive and
patching the west patching the product
itself ensuring that everything's up to
date and
backing up any data that it has
scheduling it the extra storage costs
that come from that checking whether
they're working or not
and
reliability and uptime
if the sas version runs across like
multiple aws regions and there's
failover and things like that and you're
running it on an old pc in a cupboard
you're not comparing like for like there
that's not the same thing
um
if that collects lots of data do you
need to manage load balancing or things
like ssl termination um are they doing
things for you like a web application
firewall or ddos prevention
and then finally think about how the
environment you would deploy into
actually compares to the sas vendors so
if you're deploying a security tool
um
where integrity of the data is important
if you're going to deploy that into a
cloud account that's shared with a bunch
of developers where they would have
access to that tool that's not really
that great so there's just a few
examples but my point is main point your
time's valuable and you should consider
whether self-hosting something is really
the right choice for you and whether you
can do it well enough for for the
purpose of the two
so one of the first things that you
should consider introducing is password
manager
i don't think i need to sell the
benefits of a password manager to
anybody here but you might have to sell
it to the people with the money
in your company especially if the
concept's new to them
so
one way to approach this is to focus on
how it helps the business because that's
what they really want to know about um
an executive with budget
they don't care about the intricacies of
credential stuff right they just don't
um but they do understand the concept of
reducing risk for the business
so if you can find kind of recent or
relevant examples
um around like data breaches or attacks
where the entry point was pure quality
or reuse credentials and that's really
helpful to support your case um same
with stats around phishing since
password managers reduce the chances of
a successful fish by only kind of
autofilling credentials on sites with
the right to me
you've also got pick one
um so there's a few criteria that you
should look for here it needs to be easy
for all of the staff to use not just
techies um some weird self-hosted key
pass installed that syncs with dropbox
that isn't used it isn't usable for
non-technical staff and it's a really
bad way to start
it should make it easy to share secrets
between uh employees which might seem
counter-intuitive but people are people
are going to do this anyway
and if you don't provide a secure way
for them to do it they're going to use
things like email or slack or text
messages instead
and finally the company that you go with
should publish a lot of documentation
that goes into significant detail about
how their security works how they secure
their infrastructure how they implement
things and how they review it
so one password for example they have a
white paper that's a hundred pages long
it details their infrastructure security
how they manage keys and cryptography
and it's a fascinating read um it's an
insane amount of detail um and it helps
you kind of
appreciate the security posture that
goes into these things and verifying
whether that's enough for the kind of
data that you're putting into
um
it's also worth considering if there's
any secondary benefits to password
manager um so
the largest vendors people like one
password or lastpass if you buy business
accounts from them they come with free
personal accounts that you can then give
your staff and the benefit of that is
that you are then showing your staff
that you're not just caring about
security for the business you're giving
them the capability to help secure
themselves and help improve the online
safety for their family as well
which can be a really good start to help
kind of build out that security culture
among your employees
[Music]
sure so the question is um
how much do kind of vendor policies and
information from them inform the
security controls at rasa and the answer
is hugely yeah
um
this kind of thing is
really beneficial because you're seeing
how security works at other companies
and you can steal all their good ideas
and incorporate them into what you're
doing business yeah
it's a it's a really good source of kind
of knowledge and information about how
how
successful and large security
enterprises run stuff and if you can
cherry pick ideas for them absolutely
um
so hot and heals password managers
single sign-on um
the idea here is that you only have one
system where you manage all your users
and then your tools can integrate with
this um to authenticate users to it
it's really useful because it makes
onboarding and off-boarding users much
easier and because you only have a
single source of trade for who's
employed and you only have one place to
remove users from when they leave
you might already have access to an
identity provider without realizing it
uh if you pay for google workspace or g
suite or whatever it's called this week
um
that can function as one if you have
azure or aws accounts there's stuff
built in there as well and it's not
always something that you have to pay
another vendor for you might already
have this without realizing it
another kind of more niche benefit is
that you can use single sign-on to
strengthen the security posture of other
third-party tools that you integrate
with and there's quite a few tools out
there that support single center
integration but they don't natively
support their own 2fa and
so if you can restrict sign into those
apps to your single sign-on tool you've
kind of brought with you the 2fa
benefits from your identity provider
over to this other tool that didn't
support it and
so
this all sounds great it is you should
use it wherever you can um but kind of
accept that not all tools or third-party
services are going to offer it so you're
probably going to need a password
manager as well
but there's one major flow of a single
sign-on and that's usually whether or
not you can actually afford it
um the provider isn't usually expensive
and we just discussed you might already
have one without realizing it
but paying for single sign-on support
within your tools themselves is often
very expensive
um so this is a screenshot from a
website called sso.tax
which collects examples of vendors that
are charging particularly ludicrous
amounts for single sign-on support as
part of their kind of enterprise package
and
they do this because they can and they
get away with it you know um
vendors know that companies where big
companies where sso is kind of mandated
will pay whatever they ask um
to be able to meet those requirements
so while you should use single sign on
wherever you can there will be some
places especially if you're a small
company or a startup where it just
doesn't make the financial sense to
upgrade to a plan um that will allow you
to the most egregious example is hubspot
who have a six thousand three hundred
percent markup between their normal user
tier and the first tier that allows you
to integrate and single sign-on which is
just crazy
and another thing i don't need to
convince anyone up here is the value of
tfa
um but you should um as a kind of admin
for from apps across your business and
force it wherever you can
um as i mentioned earlier even if a
service doesn't natively enforce it see
if there's other ways that you can
enable it like integrating the single
sign off
and at risk of starting another classic
infosec twitter flamewar um
any 2fa is better than no 2f8 right
so you can get upset about sms-2a as
much as you like and because it's not
perfect but it's better than not having
any 2f8 at all
you shouldn't pick it over other methods
but it's better than not having anything
at all and you should always use the
strongest method that's available to you
um
so here's the kind of spectrum of how
secure an authentication mechanism is
from kind of least secure at the bottom
up to more secure at the top i'm pretty
sure that's not going to be legible past
like the first three rows um you're
gonna have to take my word for it so
this is a really valuable graphic um not
only does it give you a kind of
unambiguous ordering of um
what methods are strongest it also lays
out what each of those methods are
vulnerable to in terms of kind of
attacks that can work against them
i've added the triangle on the right
that kind of illustrates the volume of
attacks as well so the higher you
progress on this maturity model the
fewer automated attacks you're going to
have that can be successful against you
and the fewer adversaries that are going
to be out there that actually have the
capability and
to take on and controls like that
and as i mentioned earlier this helps
you work out what's suitable for your
threat model in the context that you're
in so the best option will be right at
the top um hardware back passwordless
authentication but if your company's
right down here at the bottom you're
still on kind of stage two or maybe even
stage three it's a big leap to get
everybody right up to the top um
in one go and improving the maturity of
security across your organization is a
journey and you have to make sure that
you bring everybody with you as well you
can't just kind of one-up other teams
and leave folk behind
so based on that it's okay to make
incremental improvements and if you can
do that quicker than waiting to make a
big change it's worth doing so if you
can enable sms to pay for stuff that's
an incremental improvement you shouldn't
wait until everybody's got ub keys to be
able to to do stuff like this make
incremental improvements wherever you
can and because they're still beneficial
um
so carrying on from the theme of 2fa i
want to specifically touch on hardware
security keys
most of the keys that you'll see are
made by ubico um but other manufacturers
are available
and there's a lot you can do with them
but there's kind of a few main themes as
to why you might want to roll them out
and they're basically the gold standard
for authentication at this point and
some of you might have used them before
when you're prompted for 2fa you tap the
local dot in the key and that's your
authenticated and the process that's
going on under the hood there is
actually really sophisticated and more
so that people might realize
you can't fish or man in the middle
credentials for a site that's using
these keys with a modern algorithm like
weapon
or something like that and for these
sites the authentication
is is pretty pretty substantial under
the hood but it's done in a way and that
it's kind of transparent to the user and
you make things easier for the user
whilst also making things more secure
and so for sites like this the site
authenticates you with the key
um but the key authenticates the site at
the same time as well um with a special
handshake which which eliminates whole
classes of attack so not only is there a
second factor but it can be fished and
it can't be stolen like a kind of six
digit code for an app from an app or a
text and used kind of out of band
without your knowledge the key
physically has to be involved in that
transaction to be able to authenticate
you can use some different functionality
on these keys as well you can use them
for ssh authentication or you can use
them for signing git commits by your
developers to show that once a commit
has been made to your product repo um
that that developer physically had
possession of that key which proves that
it was them who made it who made that
commit and that's a way to kind of help
reduce the the impact of the likelihood
of like supply chain attacks or stolen
get credentials being being used to put
things into your product
and you should consider starting this by
rolling them out to your highest risk
users which is people like admins and
it's also your exec team and once you've
got them kind of rolled out to everyone
you can start to slowly enforce their
usage across systems until everything
gets covered by strong hardware backed
authentication and enforcing them on
your single sign-on provider alone is a
big win because that should then impact
multiple products and accounts as well
uh
lastly the org level i want to talk
about device management and kind of for
all like the laptops that you hand out
to employees as well
so some small companies don't roll out
device management right at the start
thinking there's only a few devices so
it's not that important
um but in reality this is the easiest
time to roll it out um and kind of
secure the devices that you have and
establish like a baseline configuration
that you know works across them all
um
you can't secure the assets and devices
that you don't know about so making sure
you have kind of a single console you
can view the status and the
configuration of all your devices is
really valuable
so there's a few benefits to that
um like i said you easily enforce
baseline security controls across all
your devices so things like disk
encryption
you can see if devices have deviated
from that and and
map the policies that you wrote right at
the start onto the controls that you
then apply across all your devices
you can enable automated software
patching across all your devices which
is such a basic security wind that's
often kind of overlooked and but
combining this with mdm software the in
kind of inventories everything that's on
your devices gives you a really powerful
tool because then if some new software
vulnerability comes out you can check
very very quickly which of your users
are affected and if any of them need to
be patched
also it lets you lock or raise devices
that get lost which is especially useful
if you have staff for execs that are
travelling
um it also sounds like a thing that
would be expensive but it's actually not
weirdly um a basic kind of cloud-based
ndm platform that you update things and
apply controls to devices is usually
like a few pounds per device per month
it's really not an expensive thing um to
roll out
so
um i'm going to move on to securing the
product that you're building there
so the obvious place to start for this
would presumably be a pen test and seems
sensible lets you inventory all the
issues that you might be having
yeah with the product and crack on with
solving them but if the pen test is the
first interaction you have with the
engineering team it's not really a great
idea it's not the best idea
unless you have an urgent business need
for one like a customer who isn't going
to buy your product until they get a
report on this stuff
now that might seem counterintuitive but
the reason for that
is that if you're new and you come into
a dev team and you slap down a report of
vulnerabilities some of them are going
to take that personally and
some of them are going to see you as the
person who doesn't know the background
or doesn't know what what they've been
up to and how hard they've working and
coming in and telling them they've done
a bad job they've introduced all these
vulnerabilities and and if you do that
you're then going to find it really hard
and it's going to take a lot longer to
kind of rebuild that trust and get the
engineering team on your site
so
instead it's a much better strategy to
kind of delay that for a couple of weeks
or a few months to focus on building
relationships with the engineers and
showing them that you are there to help
find out what their security problems
are
so maybe there's vulnerabilities that
they think are issues and but they
aren't getting the time to fix that you
could lend your voice to to kind of help
increase the priority of that
and
maybe they're having security relevant
problems and that you can help to
automate like updating dependencies
across code and things like that and
maybe they just don't have much
background security knowledge
providing kind of training and
background knowledge for devs around
secure coding and application
vulnerabilities helps them connect what
they are doing day-to-day with the
impact of vulnerabilities that they
could introduce um and making that link
is really key for a lot of devs and it
will kind of
help them click that what they are doing
day to day has security impacts and
and ideally you make at least a few of
them kind of more enthusiastic about
security as well
and then once you've achieved that a pen
test changes from being perceived as a
report about their feelings to a report
containing new challenges that they can
work on because they understand the
context behind it they understand the
importance of fixing things um
and the kind of motivation behind
resolving them
uh as i mentioned earlier you're gonna
need to provide some training to your
devs and specifically focus around
secure coding
the worst way you can do this is to give
them just screens and screens of
documentation and for them to read
they like to code so get them into
practical activities and kind of
gamified
platforms as quickly as possible so
there's one called secure code warrior
um where you learn about application
security by finding vulnerabilities in
code snippets and fixing them and seeing
how they can be exploited
and understanding the kind of end-to-end
chain from them writing vulnerable codes
to it being exploited and they're being
like a data leak or something like that
and that kind of thing really helps
people build that mental model where
they see the effects and the kind of
impacts of their implementation choices
um most coding training focuses around
the obos top 10 which is a list of kind
of the most commonly seen types
of software vulnerabilities and this is
a really good place to start and you'll
probably cover like
ninety five percent of the volumes in
your application um
by teaching your divs
[Music]
cool
does anybody have an issue
cool all right
um
so obos produces um cheat sheets that
helps dev to kind of securely implement
like common functionality like password
storage or api security um
and these are really valuable resources
for devs to know about because they're
written to kind of um to be aimed at
devs they're written in language they
understand they have code snippets and
things through them um and one steps
know about them and know that they exist
and know that there's this kind of
trusted location where they can have
their security questions answered
they'll start to use them naturally
finally if you're not in a position
where you can hire actual application
security engineers for whatever reason
um you can try starting a security
champions program where basically each
team
or engineering squad has like a person
with a particular interest in security
and they get a little bit more training
and become like the subject matter
expert to kind of disseminate security
knowledge among the team and also act as
a point of contact who can escalate
things if they spot security um issues
that could end up having an impact to
you
uh you also want to have code security
scanning done as part of your build
process uh it's not like a substitution
for having a person do it or having a
pen test but it's like another layer to
help catch more things before they end
up in the product that you ship
application security is a whole
discipline in itself um but there's a
few tips that are clickable kind of
regardless of what your tech stack looks
like or what stage you're at
um shift left is a phrase that you you
might have heard before it's become a
bit of a slogan for a lot of appsec
vendors
essentially what this means is that you
need to shift um
scan results and security information um
as close to where devs write the code as
possible you need to kind of shorten the
cycle between them writing code and
getting security feedback on that to be
as small as possible
and that means it's easier for them to
kind of integrate fixes as they're
writing um
and
they don't see it as like a kind of
annoying chore that's tacked on right at
the end
um
you want to have security in bed at
every stage of the development life
cycle um
but it's really crucial to get the
actionable results delivered right to
the devs as they're working as quickly
as possible um
as soon as you can after they've written
the code
so this is why a lot of code scanning
tools offer like extensions for id's or
text editors that developers use and
this is a really good way to introduce
it because literally as soon as they
write the code they can get feedback on
whether that could have introduced um
security issues as well
another thing you shouldn't do is enable
a whole bunch of different security
scanning tools that can like feel your
build pipeline and without having tuned
them or looked at the kind of results
that you're getting out of them
there's hate this and they'll just work
around the scans and the results that
you have and
ignore the results because they don't
see the value in it so before you get to
the point where some of your scanning
tools should be able to fail bills
and kind of get the code sent back to
devs to fix
you want to make sure you've reviewed
the kind of findings that it has and
tuned it to make sure that they are
sensible and they're valuable
scanning also isn't just for source code
and you get like linters and scanners
for a whole bunch of other things too
config files and yandex make a scanner
for nginx the web server their config
files and they can identify like
vulnerable configurations or common
mistakes that you can write with these
files that can then lead to exploitable
vulnerabilities in your app
you can scan docker files that kind of
define the containers that you you
produce to deploy your product
and you can scan the images that are
produced as well um to kind of help you
stick to best practices and identify if
you're shipping any vulnerabilities in
like os packages or dependencies that
aren't directly related to your product
code
and finally you want to automate as much
of this as possible it takes time to do
but the most desirable end state to get
to is where all of these kind of things
are automated and a dev is only involved
if they really need to be um so for
example if you have a thing that's
updating uh vulnerable dependencies and
packages in your code a dev doesn't need
to do that it's like i'm
changing a couple of numbers in a config
file like it's not a
valuable use of their type so instead
try and fix automatically run it through
all your tests and if something fails
then and it hasn't worked then a dev can
step in and do it but otherwise um the
happy path is that a lot of these things
can kind of be automated away and you
get better security and your devs have
less kind of boring tasks and to work on
um a nice segue between product and
infrastructure is infrastructure is
closed which kind of spans both
so if you played around with cloud stuff
before probably click through a web ui
and or maybe run some cli commands and
you've ended up creating specific
infrastructure that you form
now the idea behind infrastructure's
code is that you define the
infrastructure you want usually in
something that looks kind of like a json
or a yaml type file
and then a tool handles the deployment
part for you to to achieve that end
state
it's a good idea for ops and security
purposes really um firstly it makes your
infrastructure deployments repeatable
and consistent so it's really easy for
you to spin up another environment if
you want to do some testing or you want
to audit things
um
because they're code you can now review
infrastructure changes as part of like a
normal code review process um but you're
no longer asking people to review like
big bash scripts that kind of eventually
end up having some infrastructure
deployed you get them to review the
desired end state and the tool handles
the deployment of that for you and so
it's much easier to review because
you're reviewing the the what rather
than the how
um
and because they're just code files you
can run um security scanners against
them you could scan for like security
best practices or you can enforce your
own rules like
vms shouldn't be deployed that don't
have encrypted disks or port 22 should
be open to the internet and things like
that
and because you've defined that
preferred end state you can also use
tools to enforce that in your deployment
so if you have a maybe like a product
that you've deployed and a dev goes in
and makes changes to how that deployment
is done you can have tooling that
constantly inspects your deployed state
your desired state and undoes the
changes that they've made to make sure
that you always know exactly what
configuration you have deployed
um so onto infrastructure and
particularly cloud infrastructure since
that's where most companies are heading
it's quite reasonable that you might end
up working somewhere and that only has
cloud infrastructure where all of their
infrastructure is in public clouds
um
i'm going to focus on aws as your google
cloud because that's probably what
you're going to end up using
um but don't forget about the kind of
more niche clouds like digit lotion or
heroku or oracle
um
first challenge is to work out what
clouds you're actually using which is
harder than it sounds um a really good
place to start for this is the finance
team or whoever pays the bills and does
the invoices
um because they'll be able to tell you
what clouds your company is paying for
and who's expensing them to help you
find out who the account owners are and
get access to them to secure them
um also another tip is that if you've
got quite a kind of sprawling cloud
estate and you have a lot of accounts um
account managers for the cloud provider
like aws can usually help you to find
all of the accounts that are registered
with like your works domain and that
will help you get a better view of what
you have as well
then once you're in the the best way to
actually identify everything you have
across all your regions and all your
services is to use the billing
functionality and most providers make it
quite hard to get like a full overview
of all the infrastructure you have
across different regions and things like
that
um so usually the only
kind of
true
um consistent place that you can find
out everything you're using is in like
the build pdf which could be like a 200
page pdf from from aws but it at least
lets you see kind of how much you're
spending and what locations and it lets
you prioritize based on on that
um another piece of really invaluable
cloud tooling is cloud security posture
management
or cspm tools
so
these get connected to cloud accounts
and monitor the configuration of all
your resources um in accordance with
like best practices
they can either be taken from standards
like the cis benchmarks that i mentioned
during the start
um or they can be rules that you've
defined for your own environment
and basically these give you a single
dashboard where you can view exposure
status and risks across all of your
cloud accounts in one place so they're
really valuable and some of the more
advanced and usually expensive tools can
also automate the remediation and fixing
issues that they find as well so you
could say that across all of my aws
environments
port 22 for ssh should never be open to
the internet um and you can have tooling
that will wait to see one that is and
immediately just close it again as well
so it's kind of like the infrastructure
as well as having cspm tooling you
should take advantage of the cloud
provider's own native security tooling
as well
so while cspm usually focuses on
like configuration the native tooling
can focus on threat detection and
runtime things
through behavior because they get
visibility into metrics or logs or
telemetry that's not kind of available
to you or other products out with the
cloud provider
um
so the types of tools i'm talking about
are things like aws guard duty or um
security command center uh on google
cloud um depending on the cloud and what
your state looks like they can be quite
expensive but they also provide a really
valuable level um of insight into what's
happening in your environment the kind
of behavioral threat detection type
piece so
these work by essentially processing and
collating logs from from all across your
environment and dns logs um
user activity logs across the cloud
provider um and hypervisor telemetry as
well and this gets fed in and it gets
combined with um iocs from a whole bunch
of security vendors usually
um
and the scale of data that these tools
are processing across like all of a
cloud provider's accounts um
means that they're quite capable of
detecting patterns that are affecting
kind of distinct customers that you
wouldn't see yourself if you were just
looking at your own estate
um and the volume of data they collect
means their machine learning detections
are usually quite accurate as well
so they do the kind of things you would
expect they can detect like malware
brute force attempts or the exfiltration
by looking at the network in the dns
logs and uvms and things like that
um but they can also employ some kind of
other methods that are quite interesting
and not something that you would be able
to build yourself or using non-native
tooling
so guard duty for example in aws
aws can monitor for api credentials that
are created in your account but then
used in another account somewhere else
um which can be an indicator that
there's kind of been some kind of
credential theft and your credentials
have been used by someone else
and
google cloud they announced the thing
just on monday and they built a way to
use their threat detection tooling to
detect cryptocurrency mining
on a vm without having any presence on
the vm or without actually looking at
the network traffic or anything it's
purely by looking at hypervisor metrics
and so kind of the underlying
infrastructure
that runs their servers they can detect
the patterns that indicate
cryptocurrency mining um
without having access to the processes
without having any visibility into the
memory or the network traffic or
anything um so it's a really powerful
piece of tech to have access to
so
obviously you don't want to have all
your cloud infrastructure directly sat
on the internet so anyone can access
if you've already got vpn in place it
gives you like a static ip to exit from
um it's a totally sound strategy to
restrict your your cloud
infrastructure to have access only to
that ip
if you're going to do this make sure you
enforce the fa it's really important to
keep your vpn box patched and don't
forget to remove user accounts from it
when people leave as well
but i will say that's not the best
option to deploy now if you don't have
anything in place at the moment and
there's a few reasons for that
so vpn providers don't have a great
track record um at security and this is
a really critical device for security so
in in the last year alone um
fortinet f5 pulse secure palo alto all
the major vendors for this um have had
really serious problems with the with
their vpn
products and these are really heavily
exploited by actors of kind of all skill
levels and it's quite it's quite common
to see this um they're also not great if
you're a small company that's fully
remote if your staff are quite
geographically distributed um
realistically you're probably going to
end up needing to deploy multiple vpn
boxes in different countries um which is
really quickly kind of balloons and
multiplies the cost and maintenance and
budgets for them
and then finally
the the kind of operating model of a vpn
kind of just isn't really that good
anymore uh it creates a gateway where
basically once you've authenticated with
it anything behind that is fair game
you've authenticated once you've kind of
got access you're behind the castle
walls at that point
but nowadays you should really be
looking to control and restrict access
on on a more granular level which is
where the alternative comes in
um
the alternative is kind of at the peak
of its hype cycle right now so there's
some truly insane vendor marketing um
about it but as long as you just kind of
dig through it um there's some really
solid options available in the
in the space um essentially the idea is
that instead of authenticating once and
getting access to everything
like a vpn does nothing is trusted by
default so every request gets
authenticated and users and devices need
to authenticate themselves to your
identity provider
and
before they're allowed to do anything at
all um
i'm using cloudflare as an example here
because they've got a particularly
mature offering but the kind of concepts
apply
regardless of vendor
the kind of identity broker that you
pick um authenticates you like you'd
expect but then it can also check things
like whether your device is fully
patched and whether you have up-to-date
anti-malware um and things like that
um so basically we've gone from the vpn
model of you're allowed because you're
coming from the right place and to
making a decision using multiple
different pieces of evidence and making
a dynamic decision about whether to
approve or deny based on that context so
if you're going to bring in some kind of
secure networking solution to a
high-tech company
this is definitely a reasonably early
stages technology that's worth looking
at introducing
so to begin wrapping up um
use the things i mentioned here as the
basis to create your own security
roadmap for the problems that your
organization has and
you're there to be the expert so it's on
you to work out what's actually needed
and what's a nice to have and you want
to be sure that you can justify
everything on your roadmap in a way
where it makes sense to the
business you want to work out who can
sign off on it who's going to have you
the money to pay for it and which might
not always be the same person so you
should be prepared to have like a few
rounds of kind of reprioritization and
iterating to get to a state where
everyone's happy with it
and then finally once you've got it
signed off make sure that you
communicate openly um to everyone who
could be affected by it um
hopefully you'll have a lot in there
that's come from solving other team's
problems and people will be happy with
it and but it helps adoption and it
helps people be on board if you're
transparent about what you're doing and
why you're doing it
because for for most people it's easier
for them to support it if you do so
so finally um
make sure that everything you're
thinking about doing you consider in the
context of your business not every cyber
crisis is truly going to have an impact
on what you're doing and so make sure
you don't go too hardcore too quickly
take care of the basics and have a
strong foundation to build up
if you're proposing new controls or
things that need money spent um you have
to be able to explain the business
impact of that it's not enough to say
that you want to roll out uv keys
because it's good for security and you
need to be able to explain the
consequences of not doing that what
impacts it could have
and and why that would impact the
continued success of your organization
and then finally put users at the center
of everything that you do
um don't you like idiots don't tell them
no every time they be they ask to be
able to do something because if you do
they won't stop doing bad things they'll
just stop telling you about um your job
isn't to be the kind of master keeper of
everything that's secure or not is to
enable everybody else to do their job in
the most secure way
that's me thanks very much
[Applause]
i think we have very brief time for
questions
yeah
it do you um any benchmarking security
capabilities
great set of questions um so the first
part was about um do you benchmark your
security team's capabilities um
and the second part i've already
forgotten it was about how did you
prioritize it
yeah um
not yet um
like i say that's that's kind of
something that is a more more mature
process than where we are right now
so yeah that's something that you'd like
to get to but we're not here