Show up, adapt and deliver results

Everyone needs to be made aware that security testing is a time consuming activity, so it must be included in release planning schedules.

It’s generally a good idea to jump in with security tests when QA Team is given their time to do the “regular” testing. While we’d love to receive stable and fully functional software after QA is done and functional bugfixes are in place, it’s not really practical in most fast moving environments. Asking for a separate time after everyone else had completed their tasks, would significantly slow software delivery. Slowing anything down is something we should try to avoid at all cost, because as I’ve mentioned previously, we must strive to minimize the costs of running security operations.

It’s great if your coworkers actually know about your existence and trust they have a go-to person in the company, who’s competent in security and eager to help them. We sometimes get ourselves off the radar while doing our work, and people start feeling like there isn’t anyone watching their backs anymore.  You can show your presence at the company by dropping suggestion here and there, by asking people if they need your help, by plugging security automation into Continuous Integration process and doing anything that’ll show people that you’re there, and that you care for them.

The CI/CD part is important because it’s beneficial when you have tools that give you clearer view on change management which enabled you to act accordingly and e.g. run your tests and respond in a timely manner demonstrating people that you’re on top of things.
l that you’re keeping an eye on everything, that you’ve got it all covered and you do stuff on your own. Showing people that you’re a person that takes ownership and goes an extra mile really matters, so if you talk to someone out of the blue about the issue you identified, even tho they hadn’t notified you about it, then you may change their perception of you to better.
That’s how you build respect really. You show up, you deliver results and you do stuff behind the scenes to make people’s life easier and then you come out letting them know about the cool stuff you’ve been working on lately.
If people see you hanging around all the time during design discussions, they’ll organically learn you’re needed and will let you know whenever there is something new coming up. Just be there for them and make it easy to approach you and ask for help. Professionals do enjoy companionship of other professionals, so if you become one and build such image of yourself, people will be happy to collaborate with you.

Become a leader capable of stepping out and delivering, especially in moments when people least expect it.

 

Make security simple

Simplify it for them

Security is often perceived as complex and cumbersome which makes engineers unwilling to work on it. Such attitude has its reasons, and I myself experienced that security processes at most companies actually suck and create problems.

You can make no mistake while making things simpler and carefully explaining your requirements. Easier and cheaper you make it to build secure products, more likely it’ll get included into SDLC. You need to take an ownership over the processes and simplify the frameworks, knowledge base and other resources so people can actually consume it and use it to add value to the business. Having a huge and rich in value knowledge base, doesn’t mean a thing unless you’ve got people actually using it. So make it simple and spread awareness about it, so your work doesn’t get lost in the noise of daily grind.

Developers have their own stuff to learn and they don’t want to waste time digging thru confusing documentation which doesn’t provide clear guidance on problems’ resolution. They’re looking for high quality resources, so you are expected to provide well described set of practical action items. Remember, that all I’m talking here is about making people leave their comfort zone. So you need to incentivise them learning new stuff, and generally lower you put the entry bar is better.

If you ask people out of the blue, to use some security product like 2FA or SSO integration, ensure it provides great user experience. No one wants to waste time on learning ugly UI, just because security folks require them to use yet another tool.

If you don’t keep it simple and your requests become too irritating, you won’t be able to build healthy long-term culture. You can not allow a situations to happen which make people create mind maps where security equals discomfort, pain, anxiety and shame.
To me, security is all about the mindset and it’s very little about technicals. Because we already have all the tools necessary to improve safety of our businesses, but what we often don’t have is a buy-in from stakeholders.

 

Everything is just a tool and the mission is the only thing that matters on the macro level

Technical actions are parts of your strategy, which is just a vehicle meant to help you achieve the goal. So if the goal is to secure your company, usage of specific tools is a tactic meant to bring you close to the goal. So don’t hang on to existing strategy or tactics, and tweak them as much as needed, because if something not contributing to the bigger picture, it needs to be thrown away, no matter how appealing it may be. If something works, that’s awesome. If something doesn’t work, then tweak it. If it still doesn’t work, and creates more confusion than it creates protection, then throw it out the window, and move to something else.
Do not fall into the dangerous trap of romanticizing your strategy or tactics. Those are just tools, and practicality beats romance every single time on all possible layers and dimensions.

 

Encourage and teach instead of demanding and judging

It’s easy to assume that your peers should have certain level of security awareness, but it’s as wrong as it gets. I’ve met successful senior software engineers and managers who after two decades of work experience had very limited knowledge about security engineering. Everyone comes from a different background and have worked on projects with different priorities, so the safest option is to assume that they haven’t had a chance to become security-savvy.

It’s on you to create a foundation on which you can build later on. It makes a lot of sense to create low-mid level security trainings to equalize the level of security awareness — both general safety(e.g. phishing) and technical security(e.g. secure coding) If you create such a baseline, you’ll be able to speed up discussions and save time in the future.
When you know that everyone is on the same page and you don’t need to repeat yourself on basics, you can go right into the specifics and discuss matters that matter.

It’s worth it and it made me much more productive so I encourage you to follow, even just to save you from a burnout caused by a need to repeat same things like a broken record.

 

Extensively explain security requirements and identified issues

Every time you file a bug report or request a product feature, pay attention to the communication vehicle. Elaborate as much as possible to make clear what your intent and business profits/risks are.

While writing technical details, consider using ELI5 approach, so there is no confusion along the way and no surprises when the code is shipped. Describe what the problem is and provide practical solution i.e. pseudocode, configuration excerpt or an actual piece of code that can be copy/pasted to fix the bug.  
While taking such approach, make sure that people understand you’re using ELI5, because some people may take it personally. It’s important to not hurt anybody’s feelings and it can happen if one thinks that you’re using ELI5 to diminish their knowledge even tho your intention was to make everything clear so they don’t need to waste time on individual research.
Express that you want to share your knowledge so they can learn quicker and to make it easy for next generations and juniors to understand what was the case. It may seem to be a small thing, but you don’t want to create toxic atmosphere because of such trivial misunderstanding.

 

No matter what your specialization is, we all share the same goal – improving the defense

Let me go a bit deeper on why I believe in overcommunication so much, because there are two reasons for it.

If you don’t want to be disappointed and anxious then overcommunicate. It’s simple, but in life, we tend to blame the other person that they haven’t understood us well, while it was us who haven’t expressed our thoughts clearly enough. Always blame yourself first and reflect if you’ve done the best job possible to ensure that there is no chance of someone misunderstanding your requirements. Yes, people should ask more questions if something isn’t crystal clear instead of jumping right into implementation, but life is what it is, everyone has their own struggles so you need to take this into consideration as well.

The other side is that engineers are often tired of cocky security rockstars who don’t bother putting in the work in helping engineers address the issue, besides finding the bug and shouting loud how great they are. Don’t drop a fancy vulnerability name with brief description of “Fix it, it’s simple, you can google it out!”. We’ve had enough of it, everyone is tired of it, so I implore you to not add to this bucket anymore. Finding a bug means 0 value for the business as long as the vulnerability hasn’t been addressed. Right, maybe you’ve made everyone aware of the risk, so they can take it into consideration, however that’s not an ultimate goal of a red teamer. Goal of every single one of us, is to improve the defense, not to boost our egos by trying to show people how much better we’ve got it than them. If you act this way, you aren’t better than anyone, you suck. I don’t want to put you down, maybe you have huge potential and skill set, but it’s ego that’s playing you like a marionette. Been there, done that, and then evolved to bring actual value to the business, rather than just for myself. Intentions are fantastic and I get that you may have it all good, but actions speak louder than anything else, so even when you think you’ve done your job as an offensive security professional, ask yourself a question what’s the actual outcome of your day’s work. Did you contribute to the bigger picture? If you haven’t then it doesn’t mean it’s your fault, maybe it’s business or indeed someone else’s responsibility to take it further. That’s fair enough.

All I’m saying is that you should give yourself some time to think about it, embrace that the result of your thinking may be uncomfortable and then take it to improve. Don’t beat yourself up, just improve, move forward and don’t waste energy on looking back.
Once again, if you get the results you want to get and everyone is happy – keep doing what you’re doing. But even then, ego check may be a good thing to do, to make sure you’re not getting out of sync with reality, because further you got with that, harder it’ll be to get back on the right track.