Most security analysts have the same mindset, they want to reduce and avoid risk at any cost. They think in attack vectors, vulnerabilities, access rights and how to minimize the threat.
The security team is a nag.
They won't allow us to ship it like this.
Why is the security team always saying no?
This works perfectly fine in a development process where the waterfall model.
There the security analyst can take care of risk, plan accordingly and in the end have a penetration test and assessment to ensure everything is done in a secure way.
But then agile, scrum and sprints start to happen.
The code is released faster to production, from many months for a release too many releases within a month.
The process becomes faster, the company starts living and breathing agile, the security analysts and security engineers start to rotate and losing the grip on their perfectly secured applications and processes.
The Panic
Everything goes so fast, the development teams release 3 new features and a selection of bug fixes during the two-week penetration test.
Two findings that where reported are fixed by accident in the meanwhile. What is the report worth now?
How can the security analyst even do their job in this environment and protect the assets?
Times have changed my friend, next the analyst falls into a crisis and a breakup phase.
The 5 stages of grief:
denial:
They won't be doing this forever, once the product is released and stable they will go back to the old way.
Most likely not, and they will be striving for even faster releases.
anger:
Why are they not following my processes, they are mandatory and there to ensure the safety.
They also slow down the developers, reduce velocity and give chance to the competitors.
bargaining:
If you follow my processes, I make them a bit easier and say less no to you.
They are already faster than you, you would enter their world at a stage when they already shipped and moved on to the next thing.
depression:
I can't do my job, everyone is working against me, I am always too slow and they won't fix my vulnerabilities I put into their backlog.
This is the time where the analyst should either consider looking for alternative employment options or start un-learning and re-learning what they already know.
acceptance:
The dev team won't change what they are doing, and the rest of the company is on the agile train as well. What can I do?
The Relief
This is the point where the security analysts and teams can start being part of enabling the business to strife, and turn from a nag and no-sayer to an enabler.
But how does one approach this? Everyone is talking about shifting to the left.
There are two obvious starting points, technology, and people. While many would start putting effort into the technology first, they should go and talk to the people.
Put some technology into the development lifecycle, add some code analysis into the build pipeline and make sure nobody can release until the security checks are all passing.
Going this route, will result in frustrated developers that can not make their goals anymore and hit tricky roadblocks set up by the security team (Why do I have to update a database dependency when I am just fixing a frontend bug?).
At this point shortcuts will be taken, technology removed, people might even leave the company.
The nag is back.
People First
In order to do make sustainable changes, the people who work on the codebase, the infrastructure, and the product come first.
The analyst needs to start talking to people and understand what is important to them.
What their goals are and how they are planning to achieve them.
It is crucial to understand the tools they are currently using.
Once the analyst understands the priorities and the used tools, they can get to work and start introducing security features and tooling.
The easiest approach here is to start enabling some security features as warnings on the existing tools.
Make sure that they don't break the build, but people are getting notified.
Define some achievable shared goals with the engineering team, and achieve them in collaboration with them.
Gradually enable more checks as the goals are achieved, and consider what tools would support the teams to deliver value in a secure manner.
Do you have some ideas, critique or want to share your story with me, you can reach me at hello@occamslabs.com
--
Originally published at www.occamslabs.com.
Top comments (0)