Creating a Safe Environment for Raising Risk Issues
Shannon Lietz
?? Writes lots of free content about Tech Influences | ?? Serial Entrepreneur specializes in Start-ups, Culture Hacking, DevSecOps, Red Team, Cloud & AI | ?? Ex-Adobe, Intuit, Service-Now, Sony...
Some things truly need to change within the Tech industry as security evolves to accommodate DevOps practices and distributed security decision-making via DevSecOps. Sadly, this evolution begins with creating a safe environment for raising risk issues. With a growing number of security breaches, companies simply cannot afford an environment that isn't able to stay ahead of attackers. Organizations must engage in discovering attack vectors and resolving them before attackers do. But even the most well-intentioned organizations are having a hard time understanding how to be Rugged/Anti-fragile and accept that finding and remediating security issues quickly is the new norm.
I'll admit that having a safe environment wasn't the first lesson learned while enabling a DevSecOps mindset but it has become one of the most important. Without a safe environment people are prevented from feeling empowered to do the right thing for fear of retaliation. Or they could be too scared to find out if they can raise issues without fear for their jobs. This is especially true when security gets distributed throughout the organization, such as when you move towards a DevSecOps model, and doesn't simply relate to helping Security staff. But more importantly, these same people are often unlikely to raise concerns about the environment not being safe either. Ultimately this creates a double whammy for the organization and gives attackers a leg up. And these issues have the impact of eliminating any progress that could be made as we evolve security as an industry. But mostly, it has the negative effect of reducing an organizations ability to thwart attacks before it's too late.
So what can be done? Truthfully, it's not easy. In fact, some of the most difficult change required for DevSecOps to take hold comes from creating a culture that embraces security and ultimately a Rugged/Anti-fragile mindset. Some companies are lucky enough to find a change agent and double down on their approach, realizing that it could be a complete 180 and that some eggs must break so long as business goals remain the guiding light. Other companies don't have the fortune or luxury of emerging change and have to find a less aggressive path. This article is geared towards a middle-ground approach, with the following steps:
- Designate a Risk Steward. Much like a sin-eater, this person is known for their ability to navigate the organization, highlight issues, and escalate on behalf of those who need help. The Risk Steward has no staff and their sole job in the organization is to ensure that risks can be heard and dealt with. They set the tone and constantly take the pulse of the organization to help build the right type of environment for risks to be evaluated inline with decisions. The Risk Steward highlights opportunities for leaders to understand and appreciate the issues being raised by their teams. And they ultimately help to create the right risk culture.
- Implement a Risk Council. Take a bit of a rugged approach and actively look for risks within the environment because they do exist. Engage Executives and Leaders throughout the organization to summarize the risks within their department and share those at a formal meeting dedicated to understanding and evaluating risks cross-functionally.
- Create a Rugged/Anti-fragile culture and incentivize the right behaviors. Make risk part of the culture of getting things done. Don't allow escalations to turn into a way to "defeat" staff that raise risk issues. Make it possible for team members to address risks as a percent of time spent on a project. Drive SecOps to engage in detecting weaknesses through hunting and then training on how to avoid issues as part of the remediation process. After all it's better that SecOps discovers an attack vector before external attackers do.
- Add goals for risk detection and mitigation to every manager's list. Increase engagement and momentum to reduce risks as part of everyone's responsibilities throughout the organization. Measure outcomes and ensure that enforcement occurs. Reward the right balance. Then figure out how to have your Security Staff help teams make better security decisions by ruggedizing and hardening applications and technology via Red and Blue Team activities.
- Embed risk artifacts into work streams. Use templates to drive the right types of understanding and enlist staff members to leverage templates as part of their day job. Make the templates easy and self-explanatory. And have manager's review artifacts to ensure that risks have been covered during routine planning and development discussions.
Within a short period of time, the organization will realize that the mission is not just about delighting customers but also about ensuring the safety of their data and experience at speed and scale. And that it's everyone's mission to make sure that attackers aren't successful. But more importantly, the industry must realize that its necessary to experiment in the right way and reduce the impact of issues by creating a culture that isn't afraid to fail safely.
Come up with a framework for how to engage in experiments and make these guard rails known. Publish policies that make it possible for teams to make decisions, reduce complexity and measure success. Avoid pushing out training to Developers with the intent of making them security aware with lengthy and complicated training modules. Instead come up with ways to make security easy to digest and part of the day to day operations. Moving Security Awareness team members closer to Security Operations and engage in discussions with teams that get attacked to make it a teaching moment.
And by retrenching how security operates, a culture will evolve that makes it safe to hold difficult discussions to ask for help instead of letting attackers discover the same issues.
Director Networking & IT - Engineering | Architecture | TeleCom | Cloud | SaaS
9 年Well said. Organizations need to understand that turning a blind eye to security vulnerabilities to save face is completely counterproductive. Security needs to be at the forefront of each business. It doesn't mean that we simply take each security best practice and apply it blindly across the board; however it's imperative that organizations see security as a partner and allow change agents to work collaboratively with security to ensure the integrity of the organization is not placed at risk. Hackers are getting smarter and more brazon in their methods for exposing weakness. E.g. It took merely 48 hours for CodeSpaces last year to dwindle from a thriving business to a now non-existent company because of improper security hardening taking place within its AWS environment. DevOps must incorporate proper security hardening, change/code validation, and proper segregation of duties to minimize the footprint of risk.
Chief Executive Officer at Security Risk Advisors
9 年Shannon, 1 question, 1 idea, 1 comment: #1 – What organization does the Risk Steward sit in for best combination of organizational credibility and proximity to the issues? #3 – How about a License to Kill certification that can be extended beyond the Red Team? The idea is to give the customers (developers, IT) a training program which creates credibility & confidence to self-identify issues and escalate to Red / Risk Steward #5 – Templates – excellent idea for consistency & measurement Thanks!
Principal DevSecOps Product Manager at Intuit
9 年4. Add goals for risk detection and mitigation to every manager's list. This is brilliant, Shannon. All too often, IT professionals (including Security practitioners) are of the opinion that risk is the Security team's job. As a result, they tend not to raise risk issues as part of a deployment process, simply because they are afraid that voicing concerns may slow down or halt progress altogether. Simply stated, this is where the principle of "leaning-in" can go a long way to correcting this perception and related behavior. However, I would take it a step further to say that we should add risk management to goals for every IT resource...since let's face it...most people in the individual contributor seats know the detailed ins & outs of the technology better than their managers do. True story...some of the best exploits (a.k.a. Security workarounds) I have seen have been delivered by the engineers/admins on staff. However deep we go with this strategy, the bottom line is that cultivating a safe environment that embraces identification of risk goes a long way to improving prevention strategies...and as we have seen in the last few years, risk mitigation goes a long way towards preventing incident response. As I say all too often, "an ounce of prevention is worth a pound of cure". Maybe that Ben Franklin guy was on to something.
Director of Operations
9 年Very good point Shannon makes about creating a culture of security. As companies develop and processes change due to new technologies, likewise, there will be new threats and new vulnerabilities in data protection. It is important to implement a continual assessment of your workflows and infrastructure as well as utilize outside resources for security audits to provide thorough investigation. I would like to make an additional point that non-hacking related threats can be just as devastating. Floods, fires, natural disasters, hardware failure and human error all have the potential to disrupt an organization's business processes, sometimes indefinitely. That is how sometimes data security becomes an issue of making sure information isn't lost, instead of making sure it is not found by the wrong person. Also, when operating as a small-mid sized company, sometimes the "Risk Steward" can be better served by an outside resource like All Covered in collaboration with an Office Manager or Administrative Assistant. There is a cost efficiency threshold that every company will have to recognize to see if their money is better spent on additional human capital and hardware or outsourcing their security needs. Thanks for taking the time to write this Shannon!
Cyber Architect Senior Principal at BAE Systems
9 年Great post Shannon and well aligned with an executives point of view. As Barry implies, this also includes a bit of the 'Which comes first, the vulnerability, or the trust?' line of thinking. That statement refers to vulnerability and trust between people, not DevSecOps. Security practitioners have a hard time allowing themselves to be vulnerable to peers. This can make it hard to build trust. Leadership must strive to grow teams of professionals who care and trust one another, while allowing themselves to be vulnerable in sharing their viewpoints, all while driving from a DevSecOps vision perspective. Great read! Thanks for taking the time to write it.