We're going to talk about here shifting security left. And we're going to talk
about what that means. What security means in an age of agile methodologies
and DevOps practices. So let me tell you a little bit about myself. My name is Chris Merkel.
I do security stuff. I've been doing
security stuff in a lot of areas for quite some time. Right now I work down
the street at Northwestern Mutual. And
I've lived here in the Milwaukee area my whole life. I really love it here.
And I was thinking about what to put on my, what would be relevant to put on m
BIOS slide. And given the vintage hat challenge, I figured I'd put up my first
computer which was a Commodore 64. Typical disclaimers,
so these are, these are my opinions, my opinions alone. These are the bad ones. I
stole those from somebody else.
And the third bullet point here is something I really do want to stress, is
that a lot of what I'm doing here is highlighting the work of other people.
What I'm trying to do is bring that together in, in a cohesive way that helps
us how to understand how to solve some security challenges. And as a result, I
try to do good attribution. I try to call out people's contributions and if I don't
do that at me, I didn't give you what it like digitally at me. I mean, just come
talk to me. So here's our agenda. You'll notice across these bullet points that
only one of them actually has to do with technology. I really appreciated the, the
keynote from from last night. And if you were in the keynote last
night, and you were paying attention, you realize that there were
really two things big talked about. The first on the surface you might come away
learning something about NAND flash memory and translation layers and things
like that. What was really being talked about, was questioning our assumptions
about what we do and why we do it. So I really appreciated that, that kind of
warm this up a little bit for m. Because I'm going to kind of talk about that too.
We're going to talk about what it means to try harder, what it means to
eventually fail when you've tried harder. I'm going to try to provoke an
existential crisis amongst all of you at 10:00 in the morning. Break down for a
bill jump a little bit. Then we're going to talk about giving up our desire for
control. What it means to trust other people, become an enabler, a healthy
enabler. Not the kind of enabler I saw at the Safe House last night. And then
finally, we're going to talk about how you make modest improvements to security
through a couple of smart technology decisions, okay? So first is clarify what
we're talking about here. When we talk about security failures. Typically
security failures in my mind come down to three basic problems: code,
configuration, and people. What we're going to talk about first, is we're going to
talk about people, not in the traditional sense of you know, people clicking on
phishing and things like that. But kind of people you got to work with to actually
achieve you know, good outcomes in security. Then after that, once we get into
technology, we'll talk a little bit about code. We'll talk a little bit about
configuration. So, as we start to talk about people, we have to talk about the
natural life cycle of information security in the typical organization. And
in most organizations when you get started in security. So I try to be
randomly interactive. How many of you are working in security at a
company where you are one of the first people in security, doing security at
your company? Just out of curiosity. [People raising hands] All right, all right. Cool.
Congratulations and I'm sorry. [People laugh] Um...
Depending on the, the situation and the circumstances that brought you to that
organization, you may or may not be starting out with a good working
relationship with the people you're, you're working with. And so a lot of the first
things you do in security is trying to make sure that the rest of the
organization actually understands why you're there what value you bring to
this conversation and the the thing that we always talk about is being involved
in the conversations getting a seat at the table and if you're good at that if
you're good at managing those relationships and getting a couple of
wins you are going to get a seat at the table
so congratulations this is how I feel sometimes when I find myself having a
seat at the table like you know I have no idea what I'm doing
so now that as security professionals we come in and we look at a situation and
we go all of this stuff is broke I we have to fix it and so we're going to
secure everything we will then all of the systems and all the stepping out of
my will I'm gonna be on every single project because I am the security
subject matter expert and I will be there I will be at every project meeting
every status update and I would make sure this all happens and I'm also going
to make sure that I don't have to sign off on everything and I'm gonna weasel
my way into the change management if you got change management and I'm gonna make
sure that I sign off and approve on everything along
I'm not really going to test a whole long weeks that's what a penetration
testing score will do that in the end and don't change anything after you've
built it because I got other projects happening module okay that that's not
gonna work in a lot of ways I'm describing as I talk about project
methodologies I'm talking about waterfall methodology where you do
things about set of sequential orders until you reach your desired outcome so
I'm going to say that in waterfall security models things like angst cost
and delay failure these are features they're not bugs so in that that
traditional security player you think you can wrap your arms around all of
this and actually secure all the things this is this is what you come up with
I'm doing human in the form of Gantt chart I'm sorry I'm a little sorry
because the text is a little small here but basically what we find is that if
you do get involved you know we make these decisions on technology projects
and you'll notice here that the time that you develop it you know goes way
past your goal line of tape so at the point in time at once you actually want
to put this this system into production all your business holders they're
they're upset you've missed your goal life game at this point
and then and then typically what happens is they're going to quickly go and
launch and then and then security you come back and say okay cool I have to
test it now you're ready live in your production but you do it when your
security test and you know a lot of months and months of work you know they
tell you you got exactly six days to find out everything that's almost
imperative is your product go
so you do some security testing some kind of penetration test or something
like that where you're kind of working from the outside in okay you can spend a
little bit of time agree about the actual findings they're
gonna tell you that these aren't problems I want to deal with them you
know then they start to go through the table full of six inches of grief you
know so you get you know shot with the arm now I'm not a trained psychologist
you know we do a little bit of bargaining and then eventually they
decide they're gonna commit to this you know they'd start doing all the
remediation work and then somewhere along the way you get breached and
that's what happens and and part of the root of this problem comes down to
something that IBM pointed out is that all bugs cost money some costs more than
others so this is from a classic paper that I be able to put out quite some
time ago so when I screenshotted into the super pixelated because I think it
was made unlike WordPerfect or something the cost to fix a bug in maintenance
mode which we would say is beat the production phase of the system costs a
hundred times more than fixing or avoiding the defect during the design
phase of a system so the original name of my talk is shifting security flaps of
the natural question you might ask yourself is left of what exactly okay so
what I'm going to talk about is going to presuppose a little bit of understanding
on how software projects tend to be made and built and things like that right so
we've got all the left we have our code we have two different pipelines we call
this CI CD continuous integration continuous delivery and I'm going to
talk about this in terms of teams that do this kind of work okay now I know as
a security for myself personally I come from a
network and infrastructure background I'm not used to actually dealing with
what happens in a development lifecycle you know developers go up and do stuff
and then they have this big blob of stuff called like code and then that
cook goes on the server everything that happens before that is either like black
magic or doesn't really happen probably understanding because I write that code
I compile my backbone and then I just like copy to server if I'm done right
there's nothing else to talk about but other than that right well not really
so in a modern CICS system we we talk about information or process moving from
left to right and and typically speaking most of the time that security is
involved we're involved we were on the right side of things we're dealing with
things when they are about to go into production
we deal with things that are built so let's say we get to catch up report goes
to production typically security we want to see a built rock we want to say I
want to make sure that I can test a built product call me what you have
something I can actually do something learn and it's too late at that point
because again if you go back to this IBM statistic at best you're doing a really
good maybe you're only costing the organization 15 times as much instead of
a hundred times as much so I said I'd talk a little bit about DevOps this is
the basic operating model and really really really oversimplifying us for the
purpose of conversation and it's also worth pointing out that when we talk
about this bank automation in CIS EE most of this is application designed to
build and a lot of this is deployment and
structure and things like that it's also worth pointing on this as we as we move
into new operating models with flour and and things like that this isn't just
application code there were moving to a place where code drives everything so if
you've done any work in cloud spaces you you realize that the basic model of
being able to like point like to make a server that's neat but that's not the
that's not the future that's not the operating model the the fact of the
matter is I can build an entire data center in code and I can push one Enter
key on my keyboard and I can give you a whole data center
nobody's racking and stacking anything nobody's plugging in wires
nobody's manual installing operating systems all of that is represented and
it's an cheated by a code that's the kind of environment we're talking about
operator so let's talk a little bit about DevOps what is DevOps and for
those of you who you know flinch a little bit when I use industry buzzwords
sorry but I don't like the word cyber but I'm stuck with it so we all have to
have to deal with those kinds of things just keep the Gantt charts coming we'll
forgive you
DevOps is a universe and foremost is a cultural philosophy principle practice
it has a set of tools but but this is really important because anybody who
says I have this tool therefore I'm kebobs is doing it wrong if somebody
says that the way I'm doing DevOps is the right way
doing it different therefore you're wrong is also wrong because DevOps agile
these are methodologies approaches and ideas that need to be crafted and adapt
to the way your project demands the way your business operates the weed
destruction routines and things like that but the outcome the outcome is
really the only way if you want to know if you're successful or not the measure
is high velocity can you deliver applications and services at high
velocity now wolf asked me can I keep the Gantt charts coming I'll go back to
this one I have so many more than that this is not high velocity this is low
velocity because in my in my fictitious chart that basically sums up about every
other press product I've worked on you know if we can get a major enterprise
system out in less than six months we're awesome okay and this is again
left-to-right is planned everything out way at a time they're executing on it
they're late it takes forever the the time you actually realize value in this
equation is here so the whole point of a trial is actually getting to deliver
systems and services quickly so what are the cultural philosophies that are
inherent inist first of all remin small multi disciplinary teams who work
autonomously they do everything in small increments and they do this by getting
continuous feedback and continuously testing adapting and revising and in
this idea with small interdisciplinary team what's not stated is that this
doesn't work in a large monolithic technology organization where one team
is responsible for their work then they throw it over the wall to the
next team throw it over the wall to the next team that's that's how we deliver
systems in the low velocity way so ITT broadly has realized that this is a
problem this is why we are moving to two demos it's not just the the flavor of
the week here so in terms of practices as I indicated before we talk about
everything as a code I was the fortunate opportunity to take the SANS classes
last year in cloud security and in it we had one large confirmation template that
built that will be PC and when we were done I executed one script and I
destroyed an entire data center with one command that was pretty awesome as a
security professional sauce little scary we have talked about automated
provisioning because as as we deliver tools of functionality we have to
deliver these to people in a way that you know adapts to them that gets out of
the way that delivers some of the functionality they need without having
to come and ask work to place an order a lot of how we do it-- in general is
order creation and order delivery you have a ticketing system a self-service
request system a paper form who knows what and somebody somewhere fills out a
form that gets routed to a person that person who approves it and then it goes
this other person who then approves it and then it goes to this other person
and this other person pushes a bunch of buttons to to effect a change and then
eventually somewhere along the way you can deliver some sort of access to
something and you know in a high-performing organization you you
know that could happen in a couple of hours and I say this is this is where we
have to have data central crisis don't do The Tempest
figure out how to give people what they need based on who they are and have it
ready that's it
a lot of these practices also include things like you know incremental testing
the continuous moderate that's been baked in security now as as a security
professional if you find yourself in a situation where you get dropped into
some sort of agile or DevOps practice this is essentially what tends to happen
okay
the security team doesn't quite get what's going on here
right they the the developers they see that concept of a pipeline that I talked
about they see it as an assembly line a factory a way of moving things along to
incremental to create and deliver features functionality stuff security
looks at all this and they see Jackson public and that creates some problems
soon as a security professional I think sometimes it helps to talk a little bit
about you know I talk about those things engine kind of you know vague and
abstract terms I want to talk a little bit about a high-performing DevOps team
so we're gonna do a little bit of a case study here so got this company in comedy
security their billion dollars in revenues and thirty six hundred clients
they've got unified cross-functional DevOps teams they're investing in top
talent they're using things like JIRA HipChat Azure cloud and they're they're
creating software and they're delivering a software thousands and thousands of
endpoints across the globe with release cycles that are measured in two days if
they need to add new functionality they have the discipline as a team to write
tests integrate and deploy that software
thousands of endpoints and we're not just talking about you know consumer
great stuff we're talking about people in food service hospitality healthcare
and they managed to do that without killing their employees their employees
that awesome work-life balance they rarely have to work nights and weekends
this is what in high-performing agile and DevOps team looks like they're all
so excited friend Guinea okay fight you know customer actually meant victims and
I mean honestly what's the difference between infection and deployment you're
still just getting soccer or going into point B right you gotta be good at it
you both have a financial motive right and and yes they've been plundering
clients across food service hospitality financial services gaming the list goes
on and on and on and on and if you don't get the Unicorn things you know Silicon
Valley billion-dollar valuation but kind of a thing so if we take a step back and
we ask ourselves is this agilent devops thing like a passing fad or what let's
talk about the people who truly have the purest of economic motives who are they
criminals so if this works for them
there's probably something to it we should probably stand up and pay
attention because if it didn't work they might have to do it they don't have you
know senior leaders who feel like they want to get on the front
InfoWorld with the cool thing they did and sandbag their organization with a
bunch of junk in technology process to do so no their whole town is to make
money and make money quick and effectively okay
and some misses the results is how I felt because in you know one thin parts
of the organization without responsible for this is my atmosphere my adversary
is more agile and can adapt better than me the night I got my NV checked Donaghy
and his seemingly miraculous it was bottled whiskey the other thing that to
keep in mind here is as I said before a lot of people like to throw long throw
around buzzwords and say that we are at child say that we do Dow Bob said things
like that and I did a little bit of research into this and and basically a
lot of teams that say they are agile often don't really have the the
technical practices that come along with this so I took the question if everybody
is as agile as they claim to be now as a security professional that's actually
partying a little bit because what it means is that you you still have an
opportunity to wrap your head around what's going on here adapt and and start
to start to help so this this kind of concludes the part of my talk where I
wanted to break you down a little bit and and tell you that this is here it's
here to stay it's going to require significant amount of a mindset shift
about changing the way that we think about these things
questioning about how we do security when we deliver
security who our customers are and things like that so now I'm gonna I'm
going to shift a bit into some of the technical things and here's what we're
going to is we're going to talk about we want to talk about training threat
modeling requirements architecture food quality tools and why I make poor life
decisions so I'm not going to get back like ten slides but one of the things I
had on that graph as we talked about the left to right from creating to delivery
the one thing I don't really have on that slide because I didn't take that
from somebody else is that before we do any of this we have to make sure that
everybody is capable of doing the job they have in front of them okay so let's
talk about training and I know a lot of organizations training is it is a
difficult thing and asked for but I'll tell you that more I've been working in
technology for over twenty years and there is no time in history that I can
recall where we have as much free training resources available at our
disposable disposal than we do right now and on top of that the place where the
best and large quantities of training is in this space with the types of tools
used in agile devops shops cloud services continuous delivery integration
and things like that so you know first of all you know we
need to make sure that that our developers actually know how to write
secure code you should you know start with that they're fairly available if
you don't understand you know if I say you know we need to
do something with AWS lambda and you know what that is
Amazon has a series of things that explains to you what that is
it's just as Deadpool in Calamba Microsoft answer they've got a huge
learning world there is so much good stuff available that if somebody were to
come to me and say well I'm sorry but my my organization just does not send me to
training I question whether you're trying hard enough
so when we talk about shifting left the first part is long before we have a book
yes I keep wording and start working with technology the next thing is we
need to start talking about threat modeling because you know you know
traditional software development lifecycle we start with requirements
definition and as security professionals we are trying to tell people what types
of risks they need to avoid what types of negative outcomes they need to avoid
and in order to do that we actually have to construct a threat model if you have
ever had this conversation and security where you show up and you start with you
need to use this technology and you get pushed back in arguments and things like
that as security professionals a lot of times we say to ourselves well they just
don't get it no there's a good chance they actually
do get it but they understand their data they understand their business process
and they're not convinced that the risk that you're trying to get them to invest
in is actually the biggest risk for system bases that's what we start out
with rahama and what I'm showing here on the right-hand side of the screen is
threat modeling as soon as a game I'm read plenty of books on Drive
back several years if you would have asked me three to five years ago you
know should we do you know threat modeling with you know normal teams I
would say no that's that's like an exercise for like governments and
militaries because it's going to take you days of planning and things like
that um threat modeling can be lightweight
one of the best lightweight ways to do this is through gamification so
Microsoft has their elevation of privileged University of Washington as
security parts of similarly I love the Microsoft game because it's
actually licensed three like really really free so you can imprint cards if
you want it to like sell these parts on the internet and make money you can do
it and it's and basically if you use it the same suit as a normal debit cards
but what you get into is everybody looking at different ways that's
something that fails so you start with a real basic you know you pick some some
key transactions Pyrus transaction that this does and you play this in and it
eventually help helps you to spawn conversations around what you need to do
to improve your security if you're progressing from there you can start to
actually build threat modeling into your code there's an open source project out
right now called threat spec that actually allows you to document your
code with security requirements and allows you to create really cool graphs
and things like that so now that you've constructed your threat model now we
need to actually translate that because the threat model tells you what could go
wrong the next thing is the question what do I do about so this is where we
have to start delivering requirements now again that threat modeling game if
you're good at it they play that without you okay you do not need to be the
dungeon master of threat modeling okay
each time to play the game to build their own threat models they can keep an
eye on but you even Abel the next thing you do is give them the ability to
define their requirements in its application development and I done a lot
of work recently in apps X so I'm going to lean on that a bit heavily in the
first part of this I Olaf has the application security
verification standard that helps you design requirements in software for how
secure software is built slack releases to another tool called OST else your
develop lifecycle user customizable systems that help you identify security
requirements and guide people from threat model to what they actually needs
you to build out as stories and requirements as the builder software
where do we get some of this from well you can go to you know all awesome
everybody's you know off the top ten top ten is great but it's a list of things
you don't do it's not a list of things to do right so
listen next to do right it's in the application security verification
standard that will tell you you know don't have path traversal esps will tell
you how to avoid having a path traversal which is a really important point if we
take step back from the language of code development as security professionals we
can't show up to our customers and say don't have this bad outcome we have to
show up and say here's how you appointment this bad outcome doesn't
sound like a major shift but in terms of how we talk with people it really does
matter if we start to move into you know platforms like services and things like
that we can start by defining some secure architecture standards so AWS you
know a lot of people well less no like a deter EWS they're
doing a better job in helping organizations understand how to do
security than just about anybody else right now and sure has that Microsoft
has their best practices okay so that's on our website now we're finally going
to get to the point where somebody puts their hands on keyboard and starts
writing code because what you've done at this point is you've trained them on how
to write secure code or how to do cloud security of platforms and operating
systems you've helped them identify the requirements which is the list of work
of things they're gonna do to actually do this you've done this based on
standards benchmarks frameworks all those kinds of things now the first
thing we do is we have to help them identify their bugs okay so we have to
make this seamless so again I talked about auto provisioning developers need
to be able to just consume these kinds of things and find their own bugs okay
all the code quality stuff that goes into app set that gets built into
templates you can template these things out they need to be able to find their
bugs because developers are used so working in an environment where they
write code they see how they messed up their code they go to stack overflow to
ask other people have not mess with their code they copy and paste that into
their own stuff and then they try again which is kind of cynical I'm sorry
and and they learn by making these if
failure fix over and over and over again insecure we have to be able to do the
same thing we have to give them the ability to surface all of their own bugs
so that they can figure out how to fix their bucks so that means you know
building this into those automation processes continuous delivery
situation that it stinks like Jenkins Travis CI
gitlab etcetera as a security organization we still have to build a
direct accountability so all that data that comes out of these systems and
tools we do need to kind of keep an eye on there is an accountability aspect to
this that we have to we have to maintain and then finally we can get to a point
where when we've got a lot of this built into our development lifecycle we can
start to warn people when they're when they're proceeding towards production
with something still being wrong whether that's a code flaw it could be in this
configuration in an easy-to instance or an Amazon s3 bucket that's open list
goes on and on none we can warn them so that when they try to build and push
their software into a test or push their software through a production system and
say hey just you know broke okay that might be an approach with some
organizations because if you go back to your threat model and you look at your
actual Boehner abilities you know the business opportunity is such that you go
yeah our local maturity we're going to let some bucks go to production but at
least you know about then as you mature you start to break things
oh I'm sorry this server is up spec this code up spec you're not going to
production we're gonna stop this from happening along the way we've got some
code quality tools we've got a you start with the natural editor and then for
your developers that you shouldn't actual like ite isn't they're not just
using light dimmer or something things like sonar lint fortify security
assessments there's a whole bunch of tools that do static analysis so they're
looking for you know patterns or we call Manta cabins patterns of bad code so
sequel injection cross-site scripting cross-site request
dynamic analysis of your security professional you a little more or less
this is when you're actually interacting built application that can transact data
with you and then finally and this is this is I'm going to stop and focus on
this the most in this because this is overlooked is we also need to look at
the competition of the software that developers are writing because how many
of you have written an application in node in any way okay that's awesome
we're people I expected the first thing you do is you to NPM get and the package
you want and then you use that package and the actual code that you write is
like usually like one or two lines because you're just borrowing another
package right so in a typical codebase if you look at the code that you were
actually write and all the lines of code in the packages you import the most
charitable estimate is that a node project contains only 20%
you know code that you wrote the other 80% is code that you brought in from
somebody else and in the open source world anybody can publish to NPM and the
idea that many many is make all bugs shallow I would argue that the 20 year
old open SSL on our village we find suggests that that's not actually true
now that's open source it just doesn't mean it's a panacea and it doesn't mean
that you can just automatically trusted so that means we actually have to verify
the security these code packages we're bringing in a lot of the way we have to
check for these dependencies we talked about delivering bulton images so AWS
has this concept of golden emi pipelines so you can actually configure your EWS
accounts to have pre-built images that are hardened for security that means C
is security benchmarks things like that and and you know in a more mature
organization you actually stop taxi
Faith's it sounds kind of crazy you don't actually pass running instances
you patch your golden image and then because you're so good at building and
delivering that software or deploying it out you literally like I said before I
can take down an entire data center you just destroy an application and you
rebuild it deploy new servers and you put your throw it on there and then
everything works and that is grossly oversimplifying how that works but
that's the concept we also shouldn't overlook containers so some how many of
you have used a docker container or vacant or or something like that
cool all right I love dr. Wright docker is so fantastic because no longer do I
have to mess with dependencies and all that junk i download one image file and
I say dr. up and everything works is so cool we have to scan these containers
from all our villages we put these things into production they have
built-in libraries they're kind of an abstraction of the operating system we
need to make sure that what's running in there is is is good vulnerability
management so in this type of not have an operating well but early management
is more than just scanning your assets typically servers and desktops and
finding the same patches because if you're if you're operating in this kind
of a model you should actually know what our abilities you have because you know
the relative age of the of the templated resource that golden ami that template
container the template that came from you know the security posture of that
you can infer from that the rest of the vulnerabilities that are instantiated
from that so if you're golden image is six months old heaven for bed you know
that all your service that six months worth of all our abilities so actually
individual instances of servers but you can also attach that gold am I the other
thing is as we're giving away control using things like cloud formation we're
not just telling developers they can do whatever they want
we give templates and we have the ability to inspect these templates
templates in confirmation are just a basic descriptive language and we can
audit for obvious dumb stuff if you should never have port 22 open to the
Internet you can code lint four or 22 in an in confirmation
template if your confirmation template is depending on ec2 instance you can say
is it spinning out my ec2 instance or just some Rando one from the AWS
instance story is catered containers and then of course the other thing you can
do is if you use a modern owner abilities can read your environment you
know flawless tableau rapid7 all of those have api's so at every
point when somebody is deployed onto production you can interrogate the api
of the vulnerability scanner you have in your environment already and ask it is
this environment still authorized to run in you know based on current state and
if it's not gradient because you want your developers to force a conversation
say why why should i am the language market broken and then we can work
together as that single cohesive team to to go in and make things right we talk
about instant response okay AWS new club Trey loves plug try everything put it in
the s3 buckets s3 bucket storage is cheap okay there are scripts out there
that allow you to do cleveland forensics on in ec2 instance basically it's gonna
isolate and copy off somewhere else amazon guard duty allows you
who will learn on bad behaviour and things that go on in your environment
and guard duty basically sends a notification not in the sense of a push
text message things like that that's the eventual outcome it has a notification
service that allows you to do something based on a condition being true so if
all the sudden guard you have guard a new role that says you shouldn't have an
any any firewall rule the second that happens if triggers are caught trail
events you can then script remediation functions so if somebody just made a
change to a fire mobile that says any any the log fires the reactive action
fires and you go ahead and roll back that role you can do that or you can
alert somebody who goes and slap somebody hand depends on the maturity of
your organization you can look for obvious stuff who's clearing your logins
who is logging in with you know root account instead of your your I am
accounts things like that so Incident Response can also be done in a way that
is and user facing first that puts this warning this this message of something
that happened into the hands of the the developers first rather than an incident
responder and then finally to be the secret detection um if you have if you
get in your organization you have passwords sitting in those git repos
they're all the scripts it's really ugly it's bad you shouldn't do it you should
scan your repos so there's tools that are out there to do that there's better
ways to store your keys that's kind of a clock run thing Amazon an answer that's
defaults and again this is self-service right you come to your developer and you
say you don't start with hey you checked in a bunch of open SSH keys into your
codebase that's wrong don't do that because their
next question is will power you're right the solution is show up with solutions
if you don't need a VIPs things like that these are all patterns
you can search for I mean I literally went up to give up the other day and I
googled for you know the the top line it up in a Nova's an SSH private key and
it's too small to see on the screen from anywhere but there are a million
instances of artists and private keys and github right now so we've got a
monitor for these things you can use DLP on the desktop across the network things
like that so the natural question is where do we go from here
because in a relatively short period of time I gave you a whole bunch of ideas
and what I'm not going to do is do things I'm not going to say that you
have to do all of these things and I'm not going to say that if you do all
these things everything's going to be great
instead what I'm saying is we have to adapt we have to become me the service
provider not a gatekeeper and enabler and take stock of your own capabilities
what you're capable of doing do you have a strong infrastructure background cool
good work on the ec2 stuff do have a development background hopefully
developers write better security write better code security work on these
things and small pieces incrementally but fundamentally what I'm asking is as
you do so do so with a new mindset a mindset that says instead of saying no
gives guide rails that drives accountability without actually stopping
progress that's that's what I mean that's what I'm proposing that we do
here and this is the evolving developer mindset a security is everybody's job so
developers now have to truly take responsibility for their security
outcomes and that it's nice to see but that doesn't mean that we just put our
hands up and walk away it is our responsibility
to bring them along on this journey it has to be integrated into every step of
the process and the earlier you do it through training through checking for
bugs the sooner you do that as applications
are being designed built and delivered the easier it becomes the less it costs
and the less impediment and delay you impose on your software teams and your
projects so with that I've got at about two three minutes and I'll open it up to
to see if if this is raised any questions ready here
I practice we have a set of controls we are basically coming up with technology
solutions to you know meet those controls right so I can probably give an
entire talk about how threat modeling and risk management fit together or
control management but basically if you have a control that says you must do
password handling safely you have a bunch of technical solutions for doing
that right and so if you have your your actual risk management controls
understood and you have a matching link to your technology patterns then you can
actually validate that as you do these things they not back to each other
that's my best shot and answer your question awesome thank you all for your
time I really appreciate it
you