In this episode of the We Hack Purple podcast host Tanya Janca met with Frank from Phoenix Security in the UK! We talked about this latest white paper ‘SLAs are Dead, Long Live SLAs!’, how AppSec folks aren’t necessarily ‘great’ at maintaining their own SLAs, and how to empower a team to do their own governance and be responsible for their own risk. We talked about how to figure out the security maturity model you are looking for, and what kind of language we can use to help a client decide it for themselves. We also talked about how to get several industry experts to work on the same document together: spoiler alert, it’s hard! Listen to hear more!
The White Paper: SLAs are Dead, Long Live SLAs! Data Driven Vulnerability Management
Frank’s Podcast: Cyber Security and Cloud Podcast
Several MORE White Papers from Phoenix Security:
Vulnerability management and regulation: https://phoenix.security/whitepapers-resources/whitepaper-vulnerability-management-in-application-cloud-security/
Upcoming Webinars with Frank!
16/02 - 4m GMT - Brooks Shoenfield - SLA, application security and data driven programs : https://youtube.com/live/dfANH8WKavY?feature=share
22/2 - 5 PM GMT - Chris Romeo - Data Driven Application security programs, how to measure maturity and scale : https://youtube.com/live/wqlC-cClqYE?feature=share
Frank’s Bio:
Francesco is a seasoned entrepreneur, CEO of the Application Security Risk based posture management Appsec Phoenix, author of several books, host of multi award Cyber Security & Cloud Podcast, speaker and known in the in the cybersecurity industry and recognized for his visionary views. He currently serves as Chapter Chair UK&I of the Cloud Security Alliance. Previously, Francesco headed the application and cloud security at HSBC and was Senior Security Consultant at AWS. Francesco has been keynoting at global conferences, have authored and co-authored of a number of books. Outside of work, you can find me running marathons, snowboarding on the Italian slopes, and enjoying single malt whiskeys in one of my favourite London clubs.
Very special thanks to our sponsor: Phoenix Security!
Phoenix Security ingests data from any security tool, cloud, or code, correlates vulnerabilities, contextualizes, prioritizes and translates into risk. Phoenix Algorithm selects the subset of vulnerabilities more likely to get exploited in the next 30 days, delivering them to the engineers' backlog.
From Code to cloud contextualize, Prioritize enables security engineers to act on the risk that matters most without burning out.
Join We Hack Purple!
Join us in the We Hack Purple Community: A fun and safe place to learn and share your knowledge with other professionals in the field. Subscribe to our newsletter for even more free knowledge!
You can find We Hack Purple Podcast, in audio format, on Podcast Addict, Apple Podcast, Overcast, Pod, Amazon Music, Spotify, and more!
In this episode of the We Hack Purple podcast host Tanya Janca met with Frank from Phoenix Security in the UK! We talked about this latest white paper ‘SLAs are Dead, Long Live SLAs!’, how AppSec folks aren’t necessarily ‘great’ at maintaining their own SLAs, and how to empower a team to do their own governance and be responsible for their own risk. We talked about how to figure out the security maturity model you are looking for, and what kind of language we can use to help a client decide it for themselves. We also talked about how to get several industry experts to work on the same document together: spoiler alert, it’s hard! Listen to hear more!
The White Paper: SLAs are Dead, Long Live SLAs! Data Driven Vulnerability Management
Frank’s Podcast: Cyber Security and Cloud Podcast
Several MORE White Papers from Phoenix Security:
Vulnerability management and regulation: https://phoenix.security/whitepapers-resources/whitepaper-vulnerability-management-in-application-cloud-security/
Upcoming Webinars with Frank!
16/02 - 4m GMT - Brooks Shoenfield - SLA, application security and data driven programs : https://youtube.com/live/dfANH8WKavY?feature=share
22/2 - 5 PM GMT - Chris Romeo - Data Driven Application security programs, how to measure maturity and scale : https://youtube.com/live/wqlC-cClqYE?feature=share
Frank’s Bio:
Francesco is a seasoned entrepreneur, CEO of the Application Security Risk based posture management Appsec Phoenix, author of several books, host of multi award Cyber Security & Cloud Podcast, speaker and known in the in the cybersecurity industry and recognized for his visionary views. He currently serves as Chapter Chair UK&I of the Cloud Security Alliance. Previously, Francesco headed the application and cloud security at HSBC and was Senior Security Consultant at AWS. Francesco has been keynoting at global conferences, have authored and co-authored of a number of books. Outside of work, you can find me running marathons, snowboarding on the Italian slopes, and enjoying single malt whiskeys in one of my favourite London clubs.
Very special thanks to our sponsor: Phoenix Security!
Phoenix Security ingests data from any security tool, cloud, or code, correlates vulnerabilities, contextualizes, prioritizes and translates into risk. Phoenix Algorithm selects the subset of vulnerabilities more likely to get exploited in the next 30 days, delivering them to the engineers' backlog.
From Code to cloud contextualize, Prioritize enables security engineers to act on the risk that matters most without burning out.
Join We Hack Purple!
Join us in the We Hack Purple Community: A fun and safe place to learn and share your knowledge with other professionals in the field. Subscribe to our newsletter for even more free knowledge!
You can find We Hack Purple Podcast, in audio format, on Podcast Addict, Apple Podcast, Overcast, Pod, Amazon Music, Spotify, and more!
welcome to the We Hack Purple podcast where each episode we meet a new person
who is part of the information security field but usually, quite frankly, appsec. I
just want to talk about application security! I'm Tanya Janca I am your host as usual but today I have Frank from
Phoenix security and our sponsor is Phoenix security
so what a coincidence will you please introduce yourself Frank
I'm Frank or Francesco cipolone as my mom used to call me a Franco friends
um I've been insecurity for quite a long time and doing a lot of different things I
started the careers developer then move into infrastructure security when it was
still uncool and you had to still configure server and other stuff and then move slowly and gradually to the
cloud from the very early days when it was we've really agree to configure Azure and other stuff thank you
and Cloud security and and back all full force in application security and then
trying to combine the two so here we are talking about abstract once again
yes so Frank and I have been friends for quite a while and oh yeah and I'm Tanya
Jacob I'm very bad at remembering to tell people who I am I'm the host I'm old news you all already know me so
Frank and I were talking and he said he wrote a white paper and I was like
tell me more and then we're talking and talking about it and then it was like well what if you just came on the podcast and told people about it because
so you first like you wrote away paper away papers are hard to write but
somehow you managed to get all these different people from the community to so can you tell us about how you did
that exactly um I I think every time I put something together
I think wouldn't be so cool if somebody write a
section of it and there is a good part in the bad part let me start with a good part that you get a lot of different
perspective on a white paper and a piece of paper and
the bad part is that it grows inorganically and you need to add a little bit of coven and create a single
voice on the white paper because otherwise it's just a bunch of sticked out article in in section but it's
really cool because especially right now I think we are at the cosmos something different we are seeing application of
security really flourishing and application security and Cloud security
with a fantastic discussion around contextualization or how we can do
really application security better because just fixing consistently stuff doesn't work anymore and that
fundamentally sparked the discussion of all right so how do we do better
vulnerability Management on application security but most importantly how do we manage and measure progress
and all of a sudden all Us in application security we we just said we need to be the best and everybody needs
to be the best and having that conversation slowly but surely we realized but not everybody's at the same
level of application security at the maturity level there is a maturity scale and not all the measurements are
actually fit for purpose so we said okay now we need to write something we need to write about
maturity and different level of maturity and what works at the early days and it
doesn't work at the later days and vice versa and then we start seeing some patterns
because we start saying okay how do we measure how to fix stuff slas it's the
most things that or service level agreement that insecurity is how long do you have to actually fix something
and then we start thinking well as upsec has this measurement also operational
security has this measurement and what is the difference and then we
start debating okay maybe there are some consistencies so let's add also operational security to the mix because
it's still part of the same vulnerability management life cycle and something that became
seven bullet points on a piece of paper and and a lot of ideas turn up into 40 pages of a book
and there's a good and bad part I guess on the white paper but um it took us eight or nine months to
put it together because we brought it we rewrote it uh we're divided in three sections to actually uh govern all this
mass of knowledge that start growing um but in the end we managed to put it all on paper in a coherent form
in a flowing forms that I think I'm really proud of because it's really hard to write collectively collaboratively
but most importantly writing about the subject that is so complex and has so
many face setting and and areas that people get it wrong
I feel like working with other people when you create is kind of
wonderful because they have all these great ideas and different experiences that they can share but I also find it
kind of awful because I'm like why is this taking five times as long
yeah an open source and and writing and navigating our own time you can be
really strict on things or you know you can but you can't you need to be subtle and like
please please please get these reviews yes and it's okay
you manage service level agreements or you taught you talked about service level agreements slas
I don't know if you've noticed this but I think you might agree like us security folks will say you said you know the SLA
says this will be fixed in three days blah blah blah but then when it's us
being on time with stuff we're not as good sometimes right
we're not scalable I think we're not scalable and I think the conclusion that we we
reached when we were talking about SLA was
we detect something but we don't know the impact of that Tic Tac so we say you
shall fix things in x amount of days but not all those things are actually the
same and I think in operational security we we get it a little bit easier
quote-unquote easier airport for who is listening foreign
effect of applying a patch could be straightforward could also be
disastrous when you when you switch a framework when you upgrade um
Apache for example or your swap virtual machine from java version to another
Java so it could be quite distracting but most of the time it's kind of goblin is kind of well tested now in software
security it's a wild west because there is a lot more stuff that can get deprecated the unit testing the
traditionally we don't see in patching it's much broader
and the reason that I think rigor and governance and
need to fix that we have in operational security we've been living with patching
with fixing things for quite a long time and there is two or three framework like PCI DSS soft to another framework that
dictate um how long you should fix certain things so overall as a security and operation
we're quite well used through the patch Thursday of Microsoft or when we release things I mean upset we don't have the
equivalent so it's like telling developer to actually change mentality but in application
security we haven't had that mentality for almost never and I suppose the funny part of actually
seeing how operational security goes used to certain things that are perfectly applicable to application
security but also how difficult is to adopt the same concept because there is resistance from a developer world to
adopt new things as human we don't like to change the way we operate it also on the other side we developed
are not encouraged to fix stuff unless there is business buying
but the challenge is how do we talk to the business about problems then you think you have a
fantastic stories about that I have a whole bunch of stories about that there's I was thinking though like
whenever someone says we'll just patch it when they use the word just
to me it means they don't necessarily understand the level of complexity like you were saying like if if it's a piece
of software and it has a dependency well that dependency might have eight other dependencies underneath that that has 12
more underneath those and it could be that you have to re-architect your entire application or
rewrite certain parts or remove giant parts and I think that the level of
complexity just it's not acknowledged when you say oh yeah just patch it just fix it
which is upgrade well I think upgrading a library is probably I'll go on a limb is probably the easier
Parts but then the challenge is you have to ripple effect of all the dependency and the challenge as well is those
dependents it might be on a piece of code that has been built and nobody has even touched anymore so nobody has
knowledge about that piece of code has a ripple effect that are hard to get well
in patching we don't see that many effects like this because we get a package we upgraded Maybe
they'll the the equivalent I can think is if a system is not maintained anymore and you know you don't want to touch it
you leave it there because it probably works until it tumbles over
um it kind of can't stay like that I agree I want to take this brief moment to
thank our sponsor and our sponsor is Phoenix security and Frank since you're
actually on the show while you are the sponsor can you say a bird an execurity
just like a couple sentences yes and I think our philosophies to help
the human aspect of application security we are trying to help both aspect in both
areas or from a developer perspective from a security perspective not getting burned out and the way to do this is to
select what's really matter what what are the vulnerability real Matters by contextualizing vulnerability looking at
what's of the Iran and where you run it and as well connecting to the third aspect that is
the business so how do you translate all these very very complex problem to the
business to a business Persona and go there and say we have this risk profile we have this potential impact can you
let us Focus for the next couple of Sprint for one Sprint you decide to get
to this level that as an organization we agree and creating that line of connection is really really important
for us for a single reason we don't want security burnout and we don't want people to fall out of this industry
because it's already so hard to get into and that was my why why I started the Phoenix security so as a tagline we are
contextual based risk vulnerability management from code to Cloud
oh that's a really good Tech I like that tagline that is very attractive but thank you speaking about that though
it leads me into so one of the things you covered in your white paper that I was excited about was
you talk and this is a thing that I I talk with constantly when I work with clients uh through Ian's research
the maturity level they want to meet so like what security Assurance level or security posture are you looking for how
do you how do you approach that in the white paper or how do you approach that in general well I think in general is more
against whom you want to defend like which threat do you want to defend and
in the white paper we we tackle that in Risk level what is the risk level you want to be at
um that is not entirely considering the threat that you want to defend because certain threats you'll be almost
impossible to defend against um you want to defend at NSA level against National States attacker yes do
you have National States uh attack budget will actually put two or three four companies in control and then an
operational team they react on a millisecond like probably not probably you want to scale it down and probably
defend your business against script kPa and um well who doesn't know the script give
you people that can just download things from the web and just launch an attack with meta exploit or other tools and
those probably occasional attacks look at it with some targeted taxes is what most of the business will be in unless
the national critical infrastructure where in that case they might be targeted and the other side is okay now you
decide the risk level do you want to be how quickly do you want to recover from an attack that I think is cyber security
resiliency so you get around someone do you have backup that you can restore or do you get a service knocked down uh or
do you get a Ransom or The Leverage of vulnerability on a service that get knocked down can you scale it can you swap it how quickly
can you do it how quickly can you get back to operation that are I think the
same two-phase of the same coin want to not get attacked and the other one to
recover very quickly and sometimes as a business we we focus on one and we
forget the other one I I have worked at so many places where
I say well what's our business continuity plan or do we have a disaster recovery plan especially when working
with governments uh if if something happens what are we gonna do and I remember one of the
directors saying oh well I'll Panic accordingly and I was like no we need a plan and he said
well I'll just resign and I was like no quite frankly if I as your boss I I'd
just fire you if that literally was your plan like oh I'll just abandon all hope I'm like no there might be an emergency
someday and we have to be ready for it and when I worked in the government um I got to see disasters and sometimes
they went really well and I was really impressed and um Titans they didn't
um so when you're talking about it in your I have so many questions about maturity
level um does does the white paper give any and for everyone that's listening just
to be clear obviously in the show notes we're gonna have a link to the white paper we're gonna have a link to all the thing all the things that Frank talks
about because I don't want you to be left out um so if you're panicking and you're driving your car somewhere you're like
oh no where will I get the white paper you'll get it don't worry um but in the white paper how do you
how do you get them to decide the maturity level or like how are their approaches for that or is there any
advice maybe that we could give our listeners questions I think what we have what we try to keep
we try to keep it simple uh because you can have endless questionnaire but then nobody replies uh the question is you
know do you even do pen testing do you do cold scanning do you do you assess uh any threat like four or five questions
like this gets you very quickly to a maturity stage where you don't have any maturity and then you know you can even
report to the board or to the rest of the business we have X number of vulnerability and that's perfectly fine
I think we're demonizing a lot reporting based on severity and vulnerability and
I'm full of your debts because I said we shall report based on risk it depends
actually it depends on the stage of your maturity level or your stage of the organization so
not because I mean if you get on the Journey of risk that is not that complicated and we make it very
complicated for some reason and security but it's actually not but I'll talk about that later around about that later
but there are maturity stages in maturity Journey um even if you ask do
you have an upset person you know that could be a determination of where you are with the program or not in that
particular case or do you do any threat assessment threat modeling any pen testing you know those are simple
questions that you can answer and if you reply yes to many of them then probably you're a higher maturity level I think
we we go up to maturity level four and then you get to the enlightenment of this maturity level
um higher than four I mean we have a couple more levels we started for zero for some reason
Seven Levels some companies are at zero Frank I do
meet with companies sometimes and they have made zero application security
efforts so far and some of the companies are are larger companies where they have way
more than 500 people and they have you know 20 30 40 devs and they they literally have nothing and so
I like that you give them a place to go because quite frankly sometimes I'll start the call and the people seem
nervous it's like I'm not here to judge you if you're here you want to make it better so you and I are on the same page
with that so let's find out how we can go from zero to one and then plan for
one to two Etc I I really like that you have a level for everyone even if the
level is welcome laughs it's because we realize that we're very
judgmental as a security and sometimes we say we shall do this so you shall do that without recognizing that even a
small percentage of improvement is better than you know Ten Thousand Mile journey and ten
thousand more Journeys start with a single step one in front of the others and that's how you get the momentum but
also I recognize that not all the teams are not the same maturity level you
might have teams that have a security Champion or that's a cops person in the team or somebody's security minded and
sometimes they have absolutely no clue where even to start and that's why I really like the ending
or the second part of the white paper where we talk about security okr and when you do risk level vulnerability
management across application security or operational security that's really powerful because each team can
self-govern you can define a strategy as a business saying we want to be at this
risk level and then every team can self-govern and can decide okay maybe for two sprints
we're not going to deploy any security fix any security patch because we need a release in x amount of days otherwise we
might lose that market opportunity whatever but in that way you compare security risk against operational risk
against um business risk and it's the same risk we
try to make it different but it's actually the same risk and business people are paid well and are well
trained on actually evaluating risk so if you communicate with a business owner about this is your risk level you are
responsible you are accountable for it we help you going faster it's a totally
totally different topic in discussion rather than
go in there and saying you have SLA you need to fix all your critical vulnerability in two days and by the way
the clock already started taking two days ago ah
yeah that's not security that's gonna work it's not gonna work so there was another thing in your white
paper I know I'm asking 100 questions but there's another thing that I liked where you talked about I like the way
you worded it how can you Empower a team to do their own governance and to be
responsible for their own risk and so I want to highlight enabling them rather
than yelling at them or telling them how wrong they are or giving them a 100 page policy that makes no sense but actually
preparing them and giving them the knowledge and training they need so they can do that and actually be responsible
for their own risk can you talk about that a little bit yeah and I talk you even better a story
because I lived through it I leave the mental shift in the in the Shifting the eyes of the business and
the developer how they look at security um so I've run multiple programs and
fundamentally Phoenix in in a lot of the things that I write is trying to distill
a lot of this knowledge on what I learned what they did wrong and what would be good
and when we were reporting of course vulnerability by the numbers and and pushing SLA because that was the policy
we had consistent fight and we don't have time and maybe prove me that this
vulnerability is actually hackable in my home and then I had my security Champion team spending three days trying to
figure out if there is an exploit available how bad it is let me do approve a concept it went back after two
weeks of development and they didn't even remember having that conversation well when we started empowering each
team and saying okay we have measured that you know by your code base your library based on where they run your
current date is risk level and the organization has decided to be 10 below that risk level so are your
current speed of rate of measurement you it'll take you I don't know 10 days 50
days to fix the amount of vulnerability we want you to fix but having this
inside having looked at your code base or your vulnerability you have I don't know 50 cross-site scripting that you
can solve for 50 input validation issue that you can solve with a simple OS library that does input validation for
you and maybe there will be some exception but the one upgrade or using this in the code you can fix at scale 50
vulnerability Happy Days you can go back to doing your job all of a sudden they start welcoming Us
in every Sprint in every spring planning because we were helping them hitting their own goals
faster because all of a sudden we had this deer call they were saying the steering committee around vulnerability
management that was setting risk Target for Rich lying business and then those cascaded to which business owner and as
a product owner you start saying you're developer this is one of the scorecard one of the things that we're going to
get measure against all of a sudden it wasn't security dictating things or specific stuff it was empowering them to
decide what to do when to do it and then maybe raising an exception and an
exception was risk against risk so it was a much more flexible and fluid way
to treat security risk in the way it should be and then as a security
Champion team was coming in there as a hero to help them achieving faster and
getting their goal faster so they were welcoming us instead of six months before they were fighting us to death
and it was a total total shift my security Champion team was ahead of work 80 guy they they regained
their passion to actually doing security they were helping people getting better
not bashing them on their head to to say you're an idiot and sorry for the word
you need to fix vulnerabilities because they're bad they were actually helping them achieving their objective faster
and in a smart way it was a dramatic change I love that so there's so few happy
security stories I know right maybe I should add that as
a feature to the podcast like tell me a happy security story where something good happened and you were like that was
awesome I love this I really liked the positivity and I like how in the white
paper it's we can do this like you know here's things
actually by the way I have that rules in my podcast to actually close on a positive message
is the rule for every guest to close on a positive note because security time and it can be mentally
training it can lead to burnout I've seen tons of burnout in my teams and
it's painful it's it's because I think we have lack of communication
and we do things over and over
without thinking on on how to make them better because we have so much work to do and sometimes with two pieces of
rolling a square Stone without thinking well maybe let's hold on a second maybe let's make it round and let's work in a
smart way but that requires two things they're surprised stopping for a second it is scary and business support will
actually say let's stop doing the things that we were doing yesterday and let's do something new and something Innovative and something
more clever it's hard no but uh
it's I hope there are listeners and our viewers are like yeah a happy story where it worked we can do this
so I am supposed to wrap out with wrap up with you now um
I so there was a surprise that you have for OAS members yes
so we released we actually released in in January um now this month uh the version 3 of
the platform and um we have a historical operation with the war spin because we are where we are
with the platform because of all the help but all there was member we want to give an extended license to them to
actually test only the full pledge platform with unlimited resources so we're gonna reach out to all of them
with their freebies to actually use the platform and get they're both rolling with their application security program
even if they don't have any security tool we offer them their ability to actually plug in in their
um clouds in their GitHub uh doing web assessment and web does assessment with
our orchestrators up so we give even a startup that doesn't have any security
knowledge or any security tool Deputy to actually get going with this methodology and Enterprise resources at zero cost
because we want everybody to be a little bit better off from an upside perspective and be a little bit happier
to do upset so anyone that has followed me at all knows I love love oh ask I'm such a huge
fan so if you are an OAS member you take note and also you get
um a license I believe to secure the flag and there's a couple of other things too now so it used to be you
became a member and you got literally nothing except you could say I'm a member and then you have 50 less dollars
but now or if you're meeting your lifetime member you have 500 last
dollars um but now you get things for being a member and so uh Andrew vanderstock if
you're listening everyone become an oauth member um it's roughly fifty thousand dollars
or seventy thousand dollars worth of freebie right now oh
yeah so
um for people who don't know what oasp is it's the open web application security project it is a gigantic
Community online um there's an international non-profit foundation and they organize
a bunch of stuff like OAS appsec which is happening next month in Dublin and
I'm one of the Keynotes and I'm ridiculously excited they also have chapters all over the planet
including in Victoria BC where I live in Ottawa where Frank lives in the London
UK in London UK not the London UK um and many and over 300 places around the
world we have open source projects like defect dojo and they're just they do awesome stuff and if you haven't heard
of Oz I suggest you go to owasp.org and check it out right after you visit our
sponsor Phoenix security um and with that security it's actually
easy it's super easy we made it got security and Frank is there anything
else that you want to promote or share or talk about before I wrap up
yeah we brought other white paper uh you actually contribute to the early book
where we described few things about how to get upset uh program going and we
wrote another couple of books on um contextual vulnerability management so how to translate fundamental disc
vulnerability with context and how that gets you better off at prioritizing things and what are the regulation
Frameworks that you can use leverage to actually push your vulnerability Management program to The Next Step
um and I've learned a lot about upset so if you're not sick of object I have also podcasts running that is called the
cyber security podcast about all or cseb that is available everywhere over csep
or cybercloudpodcast.com you can find us awesome this is fantastic listeners I'm
gonna have a link to everything Frank said so you don't have to go try to search the internet for it and find random things that aren't as good
thank you so much to our sponsor Phoenix security and Frank thank you dear
listener and viewer I really really appreciate the support you give we have purple and with that we will see you next time
let's say bye Frank thank you so much stay safe