Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Blogs Banner

Rolling out security consulting: an impact-driven approach (part two)

Part one laid the foundation for our Information Security Center of Excellence’s (InfoSec CoE) new approach to getting Thoughtworks teams and leadership to adopt seamless security thinking. Part two elaborates on what went into the roll out of the security consulting approach, on the ground.

 

#1 Avoid forcing a change with the use of external triggers 


Project management tools help teams identify (or visualize) and understand requirements, next priorities, bugs and defects. The InfoSec team also started visualizing requirements by providing a snapshot of priorities. 

 

This empowered teams by letting them plan their security journey and incorporating requirements as part of their roadmap. Controls were created to move a card into analysis and development alongside a sanity check. 

 

This approach not only supported the teams’ current working style but allowed security champions to lead, mentor and train the team. This workflow with security controls resonated with the team’s way of working and indirectly supported the sec champ or security champion’s journey in magnifying AppSec’s in the organization.

 

For instance, instead of dropping monthly ad-hoc security requirements, the InfoSec team created a list of controls for product teams that helped them navigate the security journey. The controls were mapped to the delivery phases and aligned with the Build Security In (BSI) cycle.

Visualization of the controls in three swim lanes and the controls highlighting the value divided to map to the delivery phases so that the BSI cycle has a connection with them.
Elaborating on the kickoff phase from the earlier image that includes these steps in order – design, build, test and deploy and feature

Fig.1 The list of controls for the product team

 

#2 Reinforce the value of ‘why’ rather than how 

 

Our experience taught us that for any change program to be successful, teams must understand both the value of their work and how the value relates to agreed business objectives and goals.


New and improved security controls act as story cards to illustrate the context and value of each control, its outcome and how it can be achieved. With such controls in place, product development teams can securely deliver functional requirements, incorporate security tooling for faster feedback and continue embedding security-build-in practices. The controls have three main sections: 

 

  • Why - context with links to breaches, OWASP guidelines and material that highlight the value of incorporating this control

  • What - expected outcome 

  • How - techniques that could be implemented to achieve the outcome 


Shared below is a screenshot of the actual board that was created for every team. The board highlights controls right from the kickoff to the release phase. Given below are how the controls are categorized:

 

  • Education and guidance

  • Design

  • User and role management

  • Data

  • Secure delivery practices

  • Secure secrets management

  • Security incident management

  • Defensive security
  • Infrastructure

 

The screenshot shows a snapshot of a board containing 4 swimlanes (left to right) Information about practices, Backlog, In progress and Completed. Each control card has a category of either infrastructure, data, development, etc. The controls have a label highlighting if this should be picked in kickoff phase or iteration 1. The type of product for which the board is created is a homegrown service. The board is a snapshot of the lifecycle of a delivery team with cards moving from backlog to completed

Fig.2 Screenshot of security controls on a Trello board

To better understand what goes into each control, here is an excerpt from one of the control cards; secrets handling:

Why should effort be invested?

 

  • Secrets are mishandled by hard coding them in to the source code, littering them throughout configuration files and configuration management tools and storing them in plaintext in version control

  • Leaked secrets can lead to a security breach

  • A document shares a few examples of breaches 

 

What is to be done to implement this control?

 

  • Invest effort in to planning a secret management strategy for the service

 

How can this control be implemented?

 

  • Ensure a team password manager is in use

  • Ensure talisman is added as the pre-push hook to check for leakage 

  • Check if talisman is setup correctly


Link to the secrets handling playbook is provided

The creation of the above Trello board is automated and the controls are populated depending on the team’s requirements – could range from a  homegrown service to an integration / api service to connecting various systems to an SAAS tool etc.

 

This approach is coupled with a capability to draw insights from the progress and help with self-quantifying security improvements.


#3 Nominate vs. voluntold/voluntary participation

 

Every team lead nominates a security champion which indirectly reinforces the importance of the work. The Infosec team pairs with the security champion using the controls, resulting in effective action. It enables the security champion and the respective team to take ownership of their product’s security using the controls.

 

The next step is the sec champ community creation and it begins with a workshop that delves into identifying a north star – which helps sec champs engage with the new approach. Sessions cover security principles, threat modeling, application security review, incident handling and more.


#4 Let the data tell the story - augmenting data-driven security

 

The insights derived from the security control board customized for each team are shared with the IT leadership during the monthly governance meetings using a maturity model. This helps visualize the teams’ security posture.  

 

Levels ranged from security processes and controls being unorganized and reactive to proactive repeatable processes and controls being implemented to processes that were partially in place and repeatable with defined controls and processes.

 

Depicted below is the journey of delivery teams to reduce security debt and achieve application and infrastructure security standards:

Security maturity

Level 0

 

Security process and controls unorganized and reactive

Process not defined and documented

Level 1

 

Basic* security processes and controls are implemented

 

Proactive, repeatable processes partially in place

Level 2

 

All security processes and controls are implemented

 

Proactive, repeatable processes partially in place

Level 3

 

All controls and processes repeatable and defined

Level 4

 

Continuous monitoring and remediation

*Basic controls include: security awareness and training, threat assessment, security incident management, user and role management, infrastructure, secure secrets management, data security 

 

Fig. 3 Application security maturity stages: a maturity model with evolving security practices

 

The visualization shared above was used across forty teams and helped leadership view teams’ progress alongside teams that were slow to respond and how they could be supported. The visualization augmented risk-based decision making and smartly displayed the team’s security maturity level.

 

Ground reality of rolling out the new security consulting approach

 

Thoughtworks’ internal product teams that power the company’s operations using the latest technologies and frameworks were the first to implement the new security controls. 

 

Their products range from platforms to web applications to integrations and more. The new security approach was implemented across 40 globally distributed teams who vouched for its efficacy, the clarity with which to pursue product security, the roadmap that helped prioritization and the levels of the security maturity model that could be scaled.

 

A big boost in usability that led to effective adoption was how teams saw every visualization mapped to the controls – this helped reduce the cognitive overload.

Feedback from stakeholders

"The intent with regards to security is to build it as a culture within our teams and not look at it as a separate piece of work and this model is a starting point."

"Looking forward to the sec champs to build security into our daily work and keeping it a top priority instead of thinking of it afterwards."

"I believe security should be built in and I see this model/approach as a step forward in that direction."

"Having this model has changed the way the team approaches security."

"As leaders, we need to make time for initiatives that support building a culture of thinking about security as BAU. This is really important in today’s rapidly changing landscape of security threats."

"We are grateful to know this program is holding us accountable and supporting us, in our goal to ensure that we will always exceed the expectations of the Thoughtworkers we serve and their clients."

"To be 'ready for anything' we truly need our Security Champions and this Security Team more than ever."

"This program will be a great platform for all the folks from different teams to come together and share knowledge."

We believe the new approach worked because:

 

  1. It was human centric and collaborative

  2. Used workflows that reduced friction

  3. Followed a hypothesis-driven development

  4. Reinforced the power of why


The InfoSec team’s goal remains making themselves redundant by empowering other teams to take risk-based decisions, by clarifying the expected outcome and value of implementing these security controls and baking security in right from the beginning. For those who would like to know more, check out my talk on Security Consulting at AppSecCon.

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Keep up to date with our latest insights