Seamless and unobtrusive security is the future. We are huge advocates of shifting left and moving security testing earlier in the development process. Leif Dreizler wrote a great article suggesting that not only do we need to shift security left, but shift engineering right. I agree, but why stop there. We all need to cultivate a culture of consistent collaboration throughout the organization in all directions. Especially if security is going to be able to play a key role in business continuity.
Shift left – Dear Devs, Hack the planet
There are several ways to shift security left: training developers, changing security teams from obstacles to advisors, to ensuring security and development use the same tooling. The main focus is to preach and practice the message that security is a shared responsibility. Everyone within the organization who adds value also must help in security. This is especially true for Development teams. In most IT organizations original software products and services are the primary drivers of revenue. For others, the dev teams help streamline critical business operations and make other departments more efficient.
Shift Right – Dear Sec, #LearnToCode
Leading Up the chain of command
One of the most difficult channels of collaboration and communication is vertically through the corporate later. For security engineers, we often spot issues in the organization’s security posture, but don’t have the authority to resolve the issue. We talk about this to someone with the right authority only to be delayed or ignored. Then the breach comes and all hell breaks loose. But there is a better way.
“When leading up the chain of command, use caution and respect. But remember, if your leader is not giving the support you need, don’t blame him or her. Instead, reexamine what you can do to better clarify, educate, influence, or convince that person to give you what you need in order to win.”Jocko Willink, Extreme Ownership: How U.S. Navy SEALs Lead and Win
If we as security practitioners aren’t making a way to influence action, then that means we need to be better communicators. Take the time to question your approach. Are we honestly communicating the risk of the issue(s) in question? Are you being alarmist using FUD (Fear, Uncertainty, and Doubt)? Are we accurately recording the business impact of certain security flaws? Are we offering solutions that make things easier for the people involved? Once the issue is resolved do you celebrate the win and thank the personnel that got you moving? You will make more progress in your discussions if you show that implementing X or patching Y saves the company effort, time, and money.
Stop Trickle Down Synergy
“It’s not what you preach, it’s what you tolerate.”Jocko Willink, Extreme Ownership: How U.S. Navy SEALs Lead and Win
We get executives that come to our training and talks. Some of them get really passionate about security. They go to conferences and pass it along with their inner circle, but nothing happens. Their companies still have a mile-long patching backlog, applications are rushed out the door, and have passwords and PII everywhere. There is a lot of energy after the talk, and on Monday they just accept the risk. You may say. Dude what are you talking about, you’re in your 20s and you get paid to bust holes in walls. Fair enough, but the companies that actually remediate findings have a consistent message of security. Companies Those that don’t often patch one particular instance of a finding and wait for the next yearly pentest. You can’t turn around and just lock down production systems overnight if there was no consideration for security at the beginning.
All of this sounds like pie in the sky thought leadership, but the power in this is practical results that affect the bottom line. When you start bringing people together you get the best insights of different parts of the organization. You’ll see the Red team being more efficient by automating attack infrastructure using vagrant. You see AppSec engineers using the development tools like Postman and Insomnia to test APIs from the perspective of a security champion. Purple teaming stops becoming a marketing term and coordinated efforts on improving overall security posture from both the Red team (attackers) and Blue team (defenders) becomes a reality. You’ll also see empathy from other departments of the business; that means no more punishing user awareness training and creating systems that don’t require that personnel click links and open pdfs.
Growing a mature Application Security program requires a high level of collaboration and cooperation. You accomplish this by shifting security left, shifting engineering right, and improving communication up and down the chain of command. This proactive approach makes development better by moving security in as early as possible and it allows security teams to improve by getting the insights from their DevOps teams. Moving security up the chain of command means that security champions honestly express risk in plain terms and influence superiors to take action. Finally, sending a consistent message on security in word and action presents it in a way that can create a security culture that is beneficial to everyone.