In our blog, Security in a SaaS Product, we discussed three things: being Aggressive, Impactful, and Evolving. One of the strategies we use to help all three of those principals is our weekly Security Guild meetings.
The guild’s task is helping engineering keep security on their minds. We use our weekly meetings to keep us up to date on the threat landscape. Diversity is important to the guild. By bringing together non-technical leaders, as well as engineers from our SaaS development, quality, and DevOps teams, we’re able to keep everyone focused on security. Our strategy focuses on engaging those who are closest to the product and those who feel the most impact when changes to processes get made.
So we sent out the call, and the response was incredible. One of the ideas we stressed the most was that experience wasn’t necessary.
The only thing we wanted was for them to be curious. What was awesome to watch was the enthusiasm that the members brought to the discussions. They all sent emails to their scrums introducing themselves as “THE” security guild member. What they have evolved into are important intermediaries with incredible impact. They now take the messages back to their teams and help keep our security focus. Part of this evolution is that membership isn’t static. Engineers can tag in and out as their availability changes. Other engineers have asked to join so we rotate to give everyone the experience.
The topic of security is and always will be sensitive, so we knew we needed to set ground rules for our discussions. Membership in the security guild comes with a certain amount of responsibility. We looked to our love of mafia movies for a simple concept: The Code of Omerta, which is Italian for “a code of silence.” Discussing this we usually laugh about employing such a term, but it is serious. The things we discuss in the security guild could be sensitive. A changing threat landscape means it is important that there are safe spaces. The guild should be one of the safe places for discussion and exploration. Keeping things confidential creates a deep level of trust which increases its impact.
One of the great things about SailPoint is that we don’t look to reach goals with one solution. A single initiative will not reach the goal of securing our product. Meeting weekly with engineers who are in the thick of delivery is one of our ways of accomplishing this goal. What has most impressed us with the Security Guilds is how effective it has been at keeping all engineers informed of the current threats we face. So much so that other departments in the organization have started their own guilds. They are doing the same type of evaluation and investigation into their tools, processes, and workflows.
If you want to start your own security guild here are some tips:
Call for volunteers. Having members who are willing and interested is key to the success of the guild.
Tilt the membership to non-leaders. It is important that the guild not be only managers or tech leads.
Keep the conversations confidential. This should be a safe place to ask questions and brainstorm.
Start small. The first meetings should be short brainstorming sessions. Flex this muscle and watch it grow. It will be great to see the ideas that get brought to the table. We started with identifying areas we thought we had a risk. Then began discussions on each of those areas.
Be consistent. With weekly discussions, we kept the members thinking about security.
Understand your purpose. Identifying risk and keeping security in the team’s minds is the main goal of the guilds. You don’t have to solve the problems in the room. We definitely seek help from others when needed.
Communicate. Confidentiality can go too far. Letting your leaders in on your guilds wins is an excellent motivator to your members. Look for opportunities to celebrate and call out engineers for great participation.
Be retrospective. As a guild, take the time to assess recent work. Be honest with each other about where the guild could improve. If the meetings are not bearing fruit, say it, and work together to get them productive.
Be introspective. Consider the makeup of your guild. Does it need to change? Are any members burned out? Does another security engineer need to join? Would fresh eyes on the topic help?
The Security in a SaaS Product blog provided a broad view of our security approach. What we want to show you in this writing is one of the many ways we seek to meet that goal. It is on us, from SailPoint’s Executives to our summer interns to face and strive for a continual strengthing of our security posture. Security Guilds offer a significant contribution to that goal.