As we approach the end of a year and a decade, I decided to write down my reflections on my experiences in the Information Security (InfoSec) field.
This is also, in part, coming from someone (me) who has struggled with how security gets done at most places and nearly quit the field (on more than 1 occassion) due to so many bad (at best) and toxic (at worst) security teams and cultures out there.
It all boils down to this: Security is a service & you are a service provider.
To unravel this, let’s explore what effective and successfull Security programs look like from a culture and engineering perspectives.
If you want the Too-Long; Didn’t Read version, skip to the TLDR section.
Information Security is not only a technical problem, it is also a people problem, specifically, security people. Our perceptions and reputations preceed us, and they’re not the good ones either.
We often come off as an isolated, egotistical, self-absorbed bunch with a god complex.
So, how can we fix our perception and reputation?
Our job is to enable developers and operations teams to do their work securely and effectively.
As such, how do we expect to help them without listening to them, without understanding their business needs, without asking them how we can help them better?
Before you walk into the office, thinking you’re a hero about to save the day, stop and check your ego at the door:
Most engineers love to learn new topics and concepts, so they could share with their teams or improve their work.
Hold weekly, bi-weekly, or monthly lunch-and-learn sessions or office hours to dive into a topic of their choosing.
Put on a quarterly or bi-annually Capture-The-Flag (CTF) competition or a hack-a-thon around enabling, improving, or automating security engineering (who knows, you might even find a few engineers with a knack or a passion for security who might want to join your team?).
This doubles as a means to build or improve relationships with your users.
Not only is security a niche field, it is also a thankless job. Yet, I have always noticed 1 or 2 engineers on every product development team that always go above and beyond their work to improve security in their projects, however small of an improvement it is.
Create a Security Champion program to designate engineers as primariy security points of contact, to recognize them for their work, and to form a support group of sorts for engineers who have to carry this mantle. Give them the space to share their challenges and their learnings with each other and with you. It’s not easy being under constant pressure from project management to deliver on customers’ priorities within tight timelines and do extra-curricular activities.
This Security Champion program also doubles as a bi-directional channel of communication between Security and Product Development teams that reinforces the first point I made, i.e. listening to your users.
As mentioned before, product developers are under project management pressures to deliver within tight timelines and deadlines. If all we are doing is piling on, we are failing.
Engineers, on product development teams or operations teams, are often closest to the product than InfoSec teams are. They likely know more about potential security concerns or vulnerabilities in their products than we do.
You giving them a security report generated from a vulnerability scanner is the least helpful thing you can do.
It is our job to enable our users to do their work securely and effectively.
This means we should be making their lives easier, not harder.
There is absolutely no reason we should be requiring our users to fill out forms and submit tickets to get their work done. Instead, we should be enabling them to be self-sufficient.
Here are some folks who are much smarter than I on the subject:
Remember that security report generated from a vulnerability scanner?
Here are some crazy ideas, what if you:
Yes, most of these tasks would require you to operate closely with your users… As if you’re actually one of them; an engineer on their team, but with a security background.
Now, you finally understand what DevSecOps and Shift Left truly entail!
Plain and simple.
The short version of my rambling is this: