AWS re:Invent 2022: How Neiman Marcus transitioned to developer-first security
12 de dezembro de 2022
0 minutos de leituraAt this year’s AWS re:Invent conference, Snyk’s VP of Product Marketing, Ravi Maira, spoke with Omar Peerzada, Cyber Security Architect at Neiman Marcus, about how his team transitioned from older security practices to a developer-first security strategy. Watch the full talk now, or keep reading for the highlights.
From legacy to cloud
Peerzada explained that Neiman Marcus, a 100-year-old company, was one of the first retailers to embrace digital transformation. At the beginning of its transition, the company worked with a lot of legacy infrastructure and applications. The typical problems that plague an on-prem system (scalability, performance, and security) were the key drivers that forced Neiman Marcus to look beyond on-prem to cloud.
Mapping the journey: What did the move look like?
Maira asked, "What did the move to cloud look like? How did that transformation happen?"
After a lot of research, they chose AWS as their cloud partner. Next, they created a group called the Cloud Center of Excellence, who was responsible for deploying the DevSecOps practices across the organization. They build pipelines, ensuring that security is embedded at different gates. They also provide a scalable architecture for developers to work within security guardrails.
Peerzada pointed out that with scalable architectures in the era of digital transformation, it’s critical that security is not compromised. Now, in their sixth year since shifting to cloud, Peerzada's team has migrated almost 90% of their workloads from on-prem to cloud.
Answering the pivotal question: Who owns cloud security?
"So," Maira said, "you’ve moved into the cloud. You’ve got your cloud migration started. How did the security part of the process get started, and what were some of the early lessons from that?"
The million dollar question that every organization grapples with: who owns cloud security? Is it the devops team? Is it the traditional infosec team? Or do you have a cloud security team? That is where you look to leadership for guidance.
Peerzada’s team decided that their Cloud Center of Excellence was best suited to run the cloud security program, because they were the “team on the ground” with hands on the process — but that they would have to operate within the larger guardrails of the company’s security policies. Within those guardrails, the team could choose the tools they’d use for security. This was a critical decision that enabled the Cloud Center of Excellence team to operate at scale, without blocking product teams in the company’s fast-paced environment.
Finding the tools for cloud security
The team started deploying controls in AWS by keeping on-prem as a template, looking at on-prem and cloud as an “apples to apples” comparison. But they faced the same problems in cloud security as they did using on-prem. So the team quickly pivoted to AWS cloud-native tools, which helped them maintain speed at a reasonable cost.
Peerzada’s team deployed AWS security controls. With automation as their key focus from the beginning, they deployed several security designs by default, and encrypted everything. They prioritized “basic cyber hygiene” by ensuring that identity access management controls were tight, which helped them to build a “zero trust” framework. They enabled automated remediation of key controls; for example, with their data lake on AWS, they used S3 to store objects, enabling auto-remediation for S3 encryption.
Adding application security to the mix
Maira then asked: after addressing cloud security, how did you get into more traditional app security solutions, like static application security testing (SAST) or software composition analysis (SCA)?
Peerzada recalled that his team used a few different open source tools to do basic security checks and code quality checks. While they focussed on deploying their cloud infrastructure into production without vulnerabilities, Peerzada’s team realized they needed better application security. They wanted to connect the two silos together, applying the same cadence and feedback loop they had for cloud security to their application security.
We were facing a gap in application security. We wanted to somehow connect the silos, connect these two worlds together to make sure that we had the right cadence, and the feedback loop that we have for cloud security... (and also apply that) to application security. That's when we looked at Snyk and understood that it was exactly what we wanted.
The team started using Snyk Open Source to scan third-party dependencies and packages as part of their SCA process. Then they hooked Snyk to their Git repositories to learn what vulnerabilities would emerge — and they saw instant results. Based on the value that Snyk brought by enabling developers to fix vulnerabilities, Neiman Marcus quickly became Snyk enterprise customers.
Maira asked, "how did you get developers more involved in security?"
The team introduced Snyk gradually. They first used it with only a few hand-picked, critical projects: integrating Git repositories and allowing developers to slowly learn how to work with Snyk. But soon after, they made Snyk a mandatory onboarding point for developers. Developers started scanning code with Snyk in their IDEs and became more engaged with security practices. This was how Peerzada’s team set the foundation for their developer-first approach. Their next step was to add a Snyk plugin to their development pipelines to enforce DevSecOps automation.
From the perspective of how it has benefited us… we have regular cadence calls with Snyk, biweekly calls where we speak to the solution architects from Snyk. They provide us data and help us understand the dollar value that has been saved (by measuring) the man hours (that this work would have required) if we had to fix these vulnerabilities without Snyk. That’s a really important thing, a reality check for customers. They also provide a list of developers who scan lines of code in their IDEs, and based on that data we are able to identify developer security champions.
In the serverless-first strategy at Neiman Marcus, different layers are abstracted and security responsibilities are increasingly being pushed to the cloud. But application code and libraries are still sitting on containers — and there's still a need to secure them. That’s why Peerzada's team focused on connecting cloud security posture management and application security, and on allowing developers to make security part of their work instead of an afterthought.
Lessons learned building developer-first security
Peerzada cited the following points as the most important takeaways from his experience.
For cloud security, start with basic cyber hygiene that involves access management controls, which help to build a zero-trust architecture.
Don’t consume information that you can’t react to. Some companies use a variety of tools that generate a lot of alerts. But you have to do contextualized, risk-based assessment. There are a lot of fish in the ocean — you have to go for the sharks.
You have to treat cloud security differently from on-prem. It requires a different approach. On your cloud security journey, don’t be afraid of using open source tools.
Connect the silos of cloud security posture management and application security, and treat them as the same entity. What Snyk is doing as a single policy engine is absolutely great. When you treat these silos as a single entity, you’ll have a robust cybersecurity framework.
We're thankful to Omar Peerzada for sharing his story with us at AWS re:Invent! We love stories about how Snyk has helped organizations empower developers to build security into their workflow.