Learn how to run productive security meetings

In my experience, engineers are sometimes scared — for real — to join a meeting with a security team.
Lots of engineers I’ve met had bad to at least poor experience in the past with security folks who either shouted over them or were blocking all initiatives and defaulting to NO each time someone asked a question.

To build a culture you need to show empathy and understanding of your co-workers’ intentions. No one really is breaking security just to annoy you, because they simply have no time to play games with you.
People have their own duties and responsibilities and are often forced to cut corners, and if you’re not making their life easier, they’ll find a way to go around you and get the work done regardless of your policies and procedures.

Create friendly atmosphere during your meetings and spend most time listening

Listening is good, throwing silver bullets and expressing your genius not so much.
People you’re working with are really smart and eager to improve their code if you approach the subject in a tactical way.
If you aren’t a savvy leader and speaker yet, it’s a good idea to join other non-security related meetings and learn how they’re being ran. Make notes, learn, observe people’s behavior so you can make the best out of all those meetings and then apply to yours. In general, meetings aren’t the most liked thing by engineering departments. If you make security meetings productive and friendly, your co-workers will be amazed to see someone who fixed — ever disliked — meetings and improved the bad experience they had in past with other security teams.

The approach that works best for my meeting is spending most of the time on listening to the team giving me a thorough product description when I just quietly sit sometimes asking questions but without throwing any outstanding advice(yet). Then I ask what do they feel like wasn’t done the best because of lack of time or expertise — this concept is gold, because who’s the better source of information than a person who wrote given chunk of code — and then I provide my insights but keep them in neutral tone, not preaching but just giving a food for thought. I ask what do they think about idea to do something a bit different way and I explain my POV clearly and calmly including information like why is this important and how they or our business can benefit from it.
After the meeting I’m reviewing all the notes I’ve made and data they sent me so I can come up with guidelines and send them over to the team to take a first glance over it and become comfortable with my requirements. On the next meeting or an online call we spend more time on myself explaining given items and now they’re the ones asking questions to which I must respond nicely without embarrassing them or causing any negative experience even if they didn’t know something basic, because if someone step out to ask a question he should be appreciated, not demotivated by your ego.

All that back and forth makes sense, because if you drop too many information on their heads during the first meeting it feels overwhelming and aggressive. Even if you see all the flaws and suggestions during initial meeting, try to stop yourself from bombarding them with all that, unless you really don’t have much time to afford the polite game. Surely you can give them an initial feedback but keep in mind that they can’t leave the meeting overwhelmed.

The first meeting is meant to create good relationship with a team and the second one is where things actually happen, but without prior, results may be poor and against expectations.
During second meeting we decide if it’s all good or I need to adjust some of the guidelines so the a team feels better about it.

We’re there to serve others, no other way around so sometimes you’ll must to get into back and forth with improvements in your plan to find the most practical solutions. But it’s worth it, because at the end of the day counts only this counts — improvement is there and people are executing on security and they’re not afraid of you.
Learning how to run effective meetings and how to persuade people are essential components to make corporate security programme practical. If you master social skills, almost everything else becomes bread and butter.

Do the work behind the scenes and don’t be a workflow bottleneck

InfoSec as an enabler

Of one thing I’m certainly sure — there is no place for a NO person in security department.
Long time ago already I’ve stopped counting how much time and effort I had to put to convince my coworkers that not all security people are rude bots whining about insecurities of everything and trying to keep the comfortable status quo instead of learning the new technology to allow others do their work efficiently.
All those default-deny-people — which luckily are becoming less common and becoming an artefact of the past — made it very tough for social-savvy security pros to create good corporate culture and healthy relations with engineers and other employees in general.

Saying no is easy, being creative and looking for innovative solutions is challenging and as a hackers striving to solve challenging problems should be part of our DNA. If you’re not creative, people will find creative ways to bypass your NO and it’s all for nothing.

Your goal is to show people that you aim to help them and enable their workflow instead of being gruffy because they haven’t been studying security for the last 10 years like you had and don’t know all the risks involved with what they want to do.
We’re the heroes hired to help build robust security solutions and we need to use all of our greatness to solve the challenges and secure the organization.

Listen and execute behind the scenes

To be a great leader and enabler you should master listening and working on stuff even and/or especially when noone is watching.
Delivering the work no one asked you for, just to improve life of your co-workers will be appreciated and will build the image of yourself as an outgoing person who’s out there willing to help others — the capable leader and problem solver. Our industry desperately needs such people and other employees always seek for someone who’ll inspire them and they secretly want someone to look up to.

If you give people a lot which will outweight what they’re giving you — 51>49- they’ll feel emotionally obligated to give something back and the ROI can be their eagerness to do security stuff for you.
Provide as much value and help as possible, and you’ll see empathetic magic happen because people can’t stand if they’ve received lots of help without offering as much in return.

Sometimes we just need to step out and do take things in your own hands for better future of you and your organisation. Even if it happens, that you need to fix some code and configs yourself and that’s perfectly fine as long as it’s an exception, not a rule as I had explained in the post “Embrace DevSecOps”, where the key message was that you must learn how to balance things if you want to be effective.
You must ensure that you’re doing whatever possible to show people your determination, competence and passion, but be wary of taking too much of little things — like code fixes — on your shoulders which will make it impossible to do the actually important tasks which are only within your skillset.