I've reached a point in my professional life where as much as I love popping & dropping (shell's and domain controllers) it's actually more effective that I influence security change culturally rather than as an Infosec purist.
this post is more about working as a team member long-term in environments that may have previously not had strong security programs or are new to effective security practices
While my years as a junior, a CHECK Team Member, and a CHECK Team Leader have prepared my cynicism to politely and diplomatically dismiss assertions that a system at hand will be fine what it doesn't prepare you for is a whole new world of non-consultant learning and challenges
... learning and challenges is me being diplomatic, what I mean is there is a level of diplomacy, patience and explaining that you never thought you would reach when looking back at the days of dropping a report with an exec summary a list of issues and (to cover your own arse) the best way to fix it as per the best available guidelines at the time
That's expected, limited time on a gig means limited learning of what information might be valuable to the customer, take a risk or play it safe? - well, I'm accountable so I'm playing it safe with the resources and knowledge I have, that is 3 days ? 1 day reporting - they are getting best practices because I don't know enough to be 'truly valuable'.
what we don't often see as a cosmetic/short term consultant is what happens in the background when these reports land... here are a few of my favorite scenarios:
A little bit thicker
yes, the folder full of sensitive Pentest reports is a little bit thicker.
Confident/competent(?) security forum members will very creatively navigate the issues to the point where nothing is a high so the findings don't get escalated to people in the business that would force change and it's all scheduled to clean up the other issues on the 36th of Octember, the consequence of this is a collection of things we as consultants often have failed at, married up with existing ongoing IT programs, no emergency windows, bad threat modelling, legacy support and more importantly in some organisations they aren't mature enough to not pick someone to blame, ... I mean maybe someone is to blame but let's focus on the fix first and if someone is to blame, the fix is always education.
Polish the turd
This is for the web application gigs where you smash it to pieces and day one you're feeling pretty swordfish but day two you're thinking shit, I have to report ALL this ... and I have another gig in 4 days.
when you're re-testing you know they have specifically fixed the issues at a cosmetic level because to take your advice around correct threat modeling, using proven, heavily supported frameworks and libraries is a huge rebuild, so this is the creative compromise that allows them to say THAT issue is fixed.THAT issue is fixed.THAT issue is fixed.THAT issue is fixed. and because your retest is only specific to those issues in the report, you have to say yes those are fixed.
The reality is, while an offline site makes £0.00 a compromised site puts you in the negatives financially and reputationally.
HOW COULD YOU DO THIS TO US!
I've had more than one conference call where the collective narrative was that I made these bugs and I shouldn't have.
It's really important to stay composed, let them finish ...and then correct them.
but in the background whats happening is someone wrote that code the best they could in the time they had, some think security testing is the only security they need, they'll learn, others get penalised for being the owner of vulnerable code that's unfair, and out of my control but one of the drivers someone might push hard to deny ownership or get creative to how something got there, when we as consultants all know, it's there because it's there ... it needs to not be there.
that's an educational piece, reports aren't very enjoyable journeys and there isn't really time most of the time to explain to people what SSDLC might look like or how it might work in their organisation, devs get a list of repeatable issues and are told to fix, and if it's bad enough, we'll talk short-term risk acceptance while we can suppress panic and keep eyes on the prize - securing the product
another thing is, devs are smart generally, sometimes design decisions or direction is poor but generally devs are smart, they can learn how to hack too, if not better, and as short-term security workers we don't really get to bring that out of them or do anything other than tell them where they went wrong and that possibly makes people feel bad if that's all you've got to say.
Did you enjoy that?
Damn this app is good.
You the consultant feel vulnerable!
and that's alright, eventually, you'll mature into knowing that you did the best, you follow the good methodology, you researched known vulnerabilities you have a few tricks up your sleeve, you've seen hundreds of apps... it's not that you suck it's that the app doesn't.
That might be because it's been tested dozens of times, that might be the developers understand all of the value in a proper SSDLC it might be both anyway, light reports are a great challenge and a great validation exercise
while every report should find a way to complement the efforts or presence of good security practices these ones usually have the most in.
Cover Your Own Ass(ets).
For the past 5 years I've been on longterm gigs one was permanent for an investment bank in central London and the others primarily eCommerce (fashion) and Fin-Tech
The landscape is different
As an internal consultant or long-term on-site contractor, you care more ... you have too, it's not to say short-term workers care less, just they have less time to care in. so being around more you hear more, you see more and you want more to change because you're there to be valuable and you also want to promote good security where it can be enhanced
But you might not be doing 3 day pieces of work x the number of days in your contract or if you're permanent, traditional reporting and traditional engagements are different, there are many spinning plates many different velocities of projects, requirements, deadlines, and personalities, if you give someone a few pages of fixes it's quite refreshing when they come back and challenge you as they should and when they do it's best to take it as an opportunity to educate so the more ears the better...
the point is you're utilised more in different ways, sure you aren't dragging your arse out of bed at 5 to get to a datacenter in $deity knows where for 9 and you aren't having to take a day off to do your expenses or bummed out that someones put you in a really crap hotel, but you're the security guy, when they need you they need you, be there and when they don't like what you're telling them you aint gone in 3-5 days, so manage those relationships and make no assumptions about anything that you haven't tested (except that it needs testing again)
eventually, if you're lucky the security champions will present themselves, you really need at least one per team/function to really get it... or if they don't, just really care about what you recommend, and in the same breath you'll have at least 1 person per team that thinks you're slowing them down, and you are kinda, but they just don't realise that they've never done it right until you're involved (diplomacy).
Security people are weird.
Yeah, I said it.
I'm not even being sarcastic when I say, we really care about security because that's what we live and breath... other people kinda care about security in varying degrees but mostly they care about their own primarys dev's care about development, project managers care about deadlines, call centres care about customers so on and so fourth... while security is vertical in every organisation it's often left upto security to do security (as the devs dev, and the PM's PM etc...) but we are in an age where there are so many things to consider we need to distil the thinking 'when planning, make sure security is present or has visibility' and that might seem obvious to some of you readers but believe me, it's out chaos out there, and everyones just trying to do their job
from finance, marketing, developer teams, call centres, cloud engineers, desktop engineers, physical security, product security, 3rd party security the list is huge, there is always something that needs doing - usually that's the newest thing, when really you're worried about the legacy stuff (equal amounts of fear is the right amount).
So how do you communicate with such a diverse mix of minds that all have different agendas but common goals?
Here's the thought
regardless of the department, what can we ask of people that's an easy reminder to include security in thinking (Aside from security teams of course)
First off we need to get their attention:
The good thing about the graphic above is most of the responses are yes. and to know, you have to give it some thought.
Cover your own ass(ets).
what we are saying here is making it personal (cover your own ass) but also reminding them of their business responsibilities (cover your own assets) what are you responsible for here.
CYOA is a term most of us know, but let's make sure everyone is thinking about it, and as Dan Cuthbert reminds us Keep It Stupid Simple
By keeping this in peoples minds we aren't going to fix everything, but we are going to be involved sooner have better visibility of projects the velocity and business appetite rather than finding out by the coffee machine 2 days before going live.
Casey Ellis (CEO @ Bugcrowd) says:
"make secure easy, and insecure obvious"
I couldn't agree more with him, for this to work we need to be at the forefront of business thinking in all areas, is either a vertical a critical missing component or a failure.
It also doesn't negate correct practices but it allows us to distill them, this only affords us the introduction we need to ask the right questions, involve the right people, present the right concerns, action testing and questioning of stuff and things.
so for those of you that have internal security teams but find it hard to get traction, give it a go
from my experience I've always used a security improvement opportunity to introduce this kind of thinking, If you have some change that effects each department one way or another let them know that we are only here to keep things safe, but we can't do it without them, we'll do the crazy hacking but we need them to remember
Cover Your Own Ass(ets).