Sometimes Life Is A Sprint And Not A Marathon

Carlos Rodriguez, Director Of It Security & Risk, Citizens Property Insurance Corporation

Digital transformation has finally arrived in the insurance industry to address the demands from stakeholders for initiatives that focus on customer self-service, predictive data analytics; cloud adoption; and many more.

Development teams, under pressure to deliver high quality products in small increments, have adopted agile techniques such as SAFe, Scrum, or Kanban to deliver features incrementally within a “Sprint.” While speed of delivery is a good thing, we still must manage IT risk to acceptable levels. A key component is knowing how security teams fit within the Software Development Lifecycle (SDLC), and how best to communicate system requirements and close risk and compliance gaps as the development process unfolds. To do so effectively, security teams need to “sprint” at the same pace of development teams.

“Sprint” and “Agile” tend to be a negative term to most security teams. While developers may yawn when hearing about security policies they do not understand, security teams roll their eyes when asked to provide user stories, and plan work for each Sprint. When we began collaborating more than two years ago, our experience was no different, but I’m happy to report that we overcame initial challenges and have adapted to work successfully within the Scrum framework. Today, our security team members come to quarterly planning sessions armed with User Stories for planning boards, so developers can plan work to address risk and compliance issues. As a result, we are experiencing less friction between groups and an across the board reduction of compliance and control deficiency gaps.

The Cultural Shift

The shift to Agile is not a painless process. During the first team meeting I convened after joining Citizens, my team members lamented that developers didn’t include them in conversations or brought them in too late and things had to be fixed. But when I asked whether my team had made developers aware of their concerns, they looked at me like I was speaking a different language. “They should just know we need to be engaged.”

My first task, then, was to enlighten my own team on the value of educating other divisions on how we could support them throughout the process. The second task was to open the door for more back and forth conversations with developers early on as constant communication is key to getting your team onboard. Expect some push back because you will be effectively changing the way the team works. You will now hear a different lament-“They don’t leave us alone!”

It’s also critical that security teams be willing to bring solutions and suggestions rather than simply saying that something cannot be done. Gaps need to be addressed, but if we are part of teams experimenting with new approaches and we have enough compensating controls around a solution that allows us to move forward, we can come back with a stronger solution later as long stakeholders know the gap exists. This is different from the old paradigm in which security and compliance teams would not support delivery until all control gaps were addressed.

Today we consult with different teams throughout the seven stages of Citizens’ Agile Release Train–from Ideation through Validation–supporting efforts such as risk analysis; controls assessment and design; controls testing, contract review; access review; and third party controls review. This has led to reduction of existing controls gap; risk and compliance issues; as well as better collaboration. The key to success is communicating and educating the organization about how and when to engage teams.

We have also developed some of our own tools. One common theme we heard earlier in our journey was confusion and frustration around security and control requirements. While this is something that we are constantly refining, one of the most valuable tools we have developed is our IT Security Standards Assessment, which is used to gather information to display inherit risk. Sometimes we have used this tool before knowing what controls may be available, but our architects and IT leaders have become adept at understanding where to focus their attention early in the process to assess risk. We get bonus points by having turned their feedback into action.

The security team at Citizens has demonstrated that we embrace the company’s culture and adoption of Agile practices and is delivering visible value to the organization by welcoming continuous feedback, developing tools that build clarity on security requirements, working with the rest of the organization to manage risk together, and allowing for experimentation that leads to better understanding of risk that is addressed at the right time. As a result, we have changed the way the security team is seen at Citizens–from a blocker to a trusted business partner focused on delivering business outcomes while managing risk for IT and the organization.