Security Architecture, Application security, DevSecOps

How Target baked security into a tech transformation, just in time

A target store is seen on August 19, 2020 in Miami, Florida. The company saw astounding growth during the pandemic, thanks in part to a tech transformation that enabled secure online commerce. (Photo by Joe Raedle/Getty Images)

While many businesses struggled to stay in the black amid the pandemic, Target did not. The retail giant grew sales by a whopping $15 billion in 2020. But had the company not begun a technology transformation years prior, the surge in demand combined with the security ramifications could have been a disaster.

The global shutdown from COVID-19 drove many shoppers away from brick-and-mortar stores and directly to online shopping. Target’s digital sales increased 145%, contributing to 2020 revenue growth that exceeded the 11 prior years combined. In the words of Jennifer Czaplewski, director of the product security team at Target, “every day was like Cyber Monday.” At the same time, the headquarters team went fully remote, with the workforce requiring a quick transition to new collaboration tools to operate, while also demanding more flexibility.

“Had we not started our own transformation at the same time as our tech partners [inside the company], our security team would have quickly been left behind,” said Czaplewski, speaking during the RSA Conference.

Click here for more coverage of the 2021 RSA Conference.

About six years ago, Target began a comprehensive tech transformation that involved hiring 1,500 engineers and adopting a product model, where the security team would enable developers to build more secure products through a real-time partnership. Key priorities of this partnership include addressing flaws, focusing as much on ease of implementation as security, and integrating security with developer tools. As an example of the latter, Target’s static application security testing, or SAST, is powered by a vendor tool on the back end, scanning code automatically without any action needed by the developers.

The product security model involves six overall capabilities: code analysis, runtime analysis, business logic analysis, distributed security advocates, security health, and awareness and knowledge, with the goal to enable the secure delivery of software at scale and to integrate security into the tech culture.

Three areas of focus produced value out of the gate, said Czaplewski, but also evolved from the initial rollout of the program: product intelligence, a security champions program and penetration testing.

Before rollout of the transformation effort at Target, a team was dedicated to managing security findings stored in a governance, risk and compliance (GRC) tool.

“Only the team could access them,” Czaplewski said. "So every month this team would go into the GRC tool, export the data, manipulate spreadsheets, and email those out, asking teams, ‘Did you remember you had [a] finding? Do you have an update on when you’re going to close that finding?’” At the same time, “we had a lot of different security teams reaching out to development teams, asking them to do things to better secure their products; but those requests were not necessarily coordinated, and it was hard for the development team to know what was the most important thing to do next.”

Target’s product intelligence tool, or PI, launched in 2017 as a collection point for security data. Currently there are 20 data sources in the system. “We wanted to offer a way for teams to compare [the] security health of different types of security data points collected together, so they could measure the health of their product,” Czaplewski said.

The system delivers a ‘PI score’ measuring the overall security health of products at Target. That score ranges on the same scale as personal credit score – 300-850 – but unlike credit scores, provides transparency about the algorithm and the data points that feed in. The score factors in whether the team is using the security services that will help secure the app – pen testing and dynamic scans, for example. It also measures whether the team is closing identified findings of issues in a timely way, implementing a security culture, and whether the team has experienced a security event in the last 12 months.

The system then shows specific actions that can improve the score.

More recently, Target made adjustments to improve PI. It transitioned the user interface from the open-source project Superset, which enabled the company to get PI off the ground quickly and prove the concept, to a proprietary offering that enabled more functionality. The company incorporated a customized notification app. And it continued to tweak the algorithm – in the third year, for example, eliminating impact on score from low severity findings.

“It’s sometimes easier to close low-severity findings, so teams were taking those actions over closing high-severity work,” Czaplewski said. “So we took out any incentive” to put off addressing the more significant issues.

Also critical to Target's tech transformation was the formation of a security champions program, which involves tapping a select group of the tech population – 5% – to serve as ‘security ninjas,’ that devote 20% of time to security activities, acting as an extension of the security team. The program is intentionally exclusive, right now including only 175 people of the 4,500 engineers on staff, to encourage a higher degree of engagement, to be more nimble, and to focus on meaningful training.

The program has also “served as an accidental talent pipeline for security team,” Czaplewski added, pointing to a ninja that this month joined the security team directly. 

“In a world where infosec talent is hard to come by, that’s valuable,” she said.

Finally, Target adapted its pen testing program, which has been in place for many years (and run internally for five) to provide testers greater empowerment. Historically, internal pen testers would do around 250 engagements a year – primarily request-driven, as developers were incentivized to do pen testing as part of the PI system. Many of the tests were motivated to meet requirements tied to the Payment Card Industry Data Security Standard, or PCI.

In the last year, pen tests became more strategic. Senior testers were assigned to specific areas that are inherently riskier: supply chain, infrastructure, stores.

“They learn more about the systems in these areas, the risk, and then decide ‘this probably needs a closer look,’” Czaplewski said. “They create test plans, then execute against those. Today, most systems are a combination of microservices put together to form a business process. We tackled setting up boundaries for a test that wasn’t as straightforward.”

An additional benefit of this change is pen testers, who previously moved on from the roles rather quickly when the repetitive nature of the work became too monotonous, remain more motivated, she added.

“Since we started empowering our testers to follow the risk – even if it takes you outside the boundaries of what we would traditionally have done for a pen test to create their own test plans, and take a more comprehensive approach – our turnover has dropped to zero.”

Jill Aitoro

Jill Aitoro leads editorial for SC Media, and content strategy for parent company CyberRisk Alliance. She 20 years of experience editing and reporting on technology, business and policy.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.