Technology enables organizations to achieve more than they ever could before. However, as organizations rely on it more, it is also becoming the source of an ever increasing number of threats. With those threats becoming more widely known due to the many high profile breaches in the last few years, a lot of organizations have been working hard to improve their software security.
In addition to the reputational risk that we all face in the event of a breach, we feel that we have a responsibility to help protect the privacy and security for the eventual users of the technology we develop. End users rarely have any way of controlling or even evaluating the security of the technologies that they often have no choice but to use. On top of this, when things go wrong and sensitive personal information such as private health information and personal financial records are stolen, the damage cannot be undone.
Focusing on actions that a delivery team can take to build security into their product from day one helps them avoid the Security Sandwich anti-pattern.
One initiative we have to help prevent a breach like this from happening is a program of engaging training that welcomes all roles into the world of security.
76% of the 78 firms that participated in BSIMM6 (Building Security In Maturity Model, Version 6) report that they’ve provided awareness training. Such training underpins a culture of security and brings people of all backgrounds up to a common baseline of knowledge and awareness.
Within Thoughtworks, we have developed a training course called AppSec101 (Application Security 101), a one-day course targeted at every member of our software delivery teams. It raises awareness of the threats teams face every day, provides exposure to a few specific attacks, and introduces participants to a number of important secure software principles in order to reduce the risk faced by Thoughtworks and our clients.
While developing a full day training in house has been a lot of work, investing time in it has allowed us to make a number of key decisions that have contributed to the success of the effort.
Compliance and security training has a tendency to be quite dry, which often results in people just going through the motions to get it done without paying much attention. In addition to not being as effective as a more engaging training session, this could potentially have a negative effect if people start actively avoiding thinking about anything security related due to a bad experience in their introduction to the topic.
In order to make AppSec101 more relatable, it is built so that all the lessons relate back to a narrative. We tell the story of Campr, a large retail company specializing in outdoor gear. The day starts by setting the stage: “For the past year, you’ve been working on a third party vendor portal for Campr. This morning, you wake up and see that Campr has been breached... and it’s a big one”.
The Campr storyline is based off an amalgamation of facts from recent, well documented breaches. These facts, along with the storyline, drive home the very real risks that security incidents pose to our business while also making for a fun, engaging training in which the motivations are exceedingly clear.
Conventional security training often relies on remote, unsupervised training courses. While this may help reduce the cost of providing the training, it reduces its value by contributing to boring sessions that participants are unlikely to get excited about. This approach also lacks interactivity, missing an opportunity for people to ask questions and discuss what they are learning with their colleagues.
We almost always conduct AppSec101 in person and try to hold sessions with people from the same team at the same time. The discussion that this generates is invaluable. Often during training sessions we will introduce a concept and someone on the team will immediately ask: “Do we do this?”. A lot of the time, after some back and forth, the team will conclude that they do have controls in place to handle the risk, or that what they thought could be a problem doesn’t apply to their situation. However, every now and then the team will identify an issue right then and there. When this happens, a facilitator is there to discuss possible mitigations and capture an action item for the team to follow up on after the training. The chance to identify concrete improvements during the training is a valuable opportunity, and one that we would not have, if we relied solely on unsupervised learning.
As we feel every role needs to be part of the solution, we hold this training with every member of the delivery team. This includes developers, quality analysts, and business and user centered individuals. It also includes both Thoughtworks employees and our clients.
Participants can choose to follow the Technical QA, Developer, Business Centered, or User Centered track during each of our three hands-on workshops. These tracks include interactions between roles, with QA and Dev roles helping less technical individuals understand the technical details of the threat in order for them to translate them into business or user concerns. After participants finish with their individual exercises, we have everyone discuss any difficulties, questions, or observations they ran into. This gives everyone a glimpse into the work others must do for the team to be successful, and it fosters empathy between people with different responsibilities on the team.
Including everyone in the training clearly demonstrates that we are all responsible for security.
We work with lots of organizations, so this training includes things we frequently see done incorrectly. These mistakes are very easy to make, and tend to happen everywhere, regardless of industry, organization size, and technology stack.
AppSec101 is designed to encourage and empower teams to improve their security practices in a number of different ways, and to catch these common security shortcomings.
One of the most common issues we see is insufficient key management. Without awareness of the risks, it’s easy to unintentionally commit username/password combinations, SSH private keys and application tokens into source control. Management of secrets is a major plot event in the AppSec101 narrative, highlighting that plaintext secrets—even in non-public repositories—can provide a valuable stepping stone for attackers to move laterally through an organization. We advocate for the use of key management tools to avoid sensitive data ever ending up in source control.
Another common issue is old, insufficiently managed and updated systems. Especially if such systems are used to host sensitive applications or store confidential data. In addition to emphasizing that secrets should not be stored in source control, AppSec101 covers the dangers of legacy internal applications that do not receive security patches. We highlight the importance of updating software, introduce participants to existing vulnerability databases, and recommend strategies for proactively staying up to date.
Lastly, application level vulnerabilities relating to user input are widespread and can be found in many if not most new applications. While we acknowledge that we will never be able to teach about every threat, and therefore focus mostly on proactive controls, we do cover a few specific threats that we feel are especially widespread: Cross Site Scripting, Injection, Vulnerable Components and Cross Site Request Forgery.
Pushing Security to the Left
Basic training cannot possibly prevent all problems, and our industry in general still has a lot of work to do, but we believe that what we have achieved with AppSec101 is a great step forward for us and our customers. It has successfully increased awareness, incited interest, and led delivery teams, on their own accord, to improve security practices on their current projects. We will continue to work on ways to push security “to the left” on our projects and in our company, and look forward to sharing more as our journey progresses.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.