![Destigmatizing DevSecOps Security Policies [Interview with Brittany Greenfield] - cover graphic](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2Ff7c704cb-35e9-4bc8-857a-6f55616e6b5f%2Faid_field_img__85d03953833db1c5d0b7eac8f7a7158e.png%3Fw%3D864%26h%3D370%26fm%3Dwebp%26q%3D75%26fit%3Dcrop&w=3840&q=75&dpl=dpl_BHtzFuj7x8fHcssjFHrhmmifkwhC){kind=small}
Next up in our series of interviews with DevSecOps community leaders, I chat with Brittany Greenfield, founder and CEO of Wabbi, a SecDevOps orchestration platform that blends application security processes and tools into existing development workflows. By starting in the design phase, Wabbi enables companies to engage in AppSec as part of a healthy development process, to improve application security without sacrificing development agility and velocity.
Why is it so hard for security teams to enforce policies and what can they do about it?
Brittany: Policies have gotten a bad rap. Development teams hear the term and think “compliance” which has become shorthand for “things I have to do so I don’t get into trouble (or spend 3 hours with an auditor).” However, the reality is that AppSec policies are not about compliance, but are actually a common development practice, just recognized by a different name: “design & coding standards.”
If security wants to destigmatize policies to make them a normal part of coding standards, they need to enable development to own the day-to-day management of AppSec through three mechanisms:
- People: Support a culture of thinking about security as a normal part of the SDLC by engaging development teams in their day-to-day, to be an advisor, not just a gatekeeper.
- Process: While process always sounds cumbersome, it’s really about introducing transparency and predictability. I often joke that a SecDevOps process is like a prenup: let’s decide in times of good how to handle when something goes wrong.
- Tools: While talent availability is a major bottleneck in every security initiative, people aren’t scalable, so automation and orchestration tools are critical to scale an Application Security program.
What’s the difference between SecDevOps and DevSecOps and why is this important?
Brittany: With any new market, there’s anew lexicon that comes with it. And this is no different with a litany of terms that are now used in regard to embedding security into development, including shift-left, security-by-design, and rugged DevOps to name a few, the biggest debate has been where the “Sec” belongs in DevOps.
DevSecOps has become the bucket term for any kind of joint development & security tool: emphasis on the word tool. And as the DevOps toolchain has grown, the tools needed to secure them have proliferated beyond vulnerability scanning. However, if you focus just on the tools, you’re just creating more data in a silo. That’s where SecDevOps comes in. By integrating AppSec into development processes—not just tools—security becomes a normal part of the SDLC and can start in the design phase to provide context to the results that come in from DevSecOps tools down the line, giving both security and development teams just-in-time actionable information.
To recap:
- DevSecOps: Integration of security into development testing
- SecDevOps: Integration of security into development processes
What does the future of penetration testing look like in an automated world? Will we always need humans and, if so, what makes us special?
Brittany: We will always need humans! I don’t care if the singularity comes tomorrow or in 200 years, no matter how advanced automation, machine learning, and AI become, it will never be any match for human creativity, which is at the core of penetration testing. The most harmful adversaries will always be the human hackers because if they’re motivated to hack into a system, they will find a way. Think about Stuxnet: that was a feat of human creativity that pulled together many components to be able to exploit a simple vulnerability. As long as we have human hackers, we will need human penetration testers. It is not coincidental that concurrently with widespread adoption of security testing automation, we’ve seen new approaches to penetration testing, such as bug bounty programmes and crowdsourcing platforms likeHackerOne, which are on the rise.
When is the best time for product teams to perform threat modeling? Are there any fun ways to do this?
Brittany: Threat modeling is a great way to get people thinking about all the ways code can be used in ways that weren’t intended, and how to proactively mitigate them. While you do want a specific example to think about when threat modeling, I’m a believer this should be done regularly as part of the team culture (no different than code reviews) not just a step in design.
I recently saw anad from Hasbro that’s part of a series called “Life Lessons” that encourages game play to create innate behaviors from good money management (Monopoly) to patience (Operation). Threat modeling exercises should be the same; not just something you do when you have to, but rather something that trains you how to think. And there is a fun way to do it! Microsoft’s Adam Shostack (who literallywrote the book on Threat Modeling), published a threat modeling card game called ‘Escalation of Privilege.’ You can download ithere.
I recommend keeping a set of the cards in whatever the usual hangout space is (kitchen, couches, etc.) and when there’s a group of people hanging out, pull out a couple. That’s a trait security and development teams share—neither will ever back down from a good competition!
When you get the teams continually thinking about security at every stage of development, threat modeling becomes an intuition instead of an exercise.
Is security a functional or non-functional requirement and why?
Brittany: Without a doubt, security is a functional requirement. However, it should not be seen as a separate line item, but rather integrated into all components from epics, stories, and tasks, to story points and tech debt. It is just one more component of making sure a feature or product does what it is supposed to do, and the backlog is managed in line with business priorities. For example, if an ignored policy or vulnerability puts an online trading platform at risk for a DDOS attack, why would that be different than a design flaw or a bug that could cause availability issues?
What are your top 5 security tools for a DevOps toolchain?
Brittany: I’m a fan of the free and open source AppSec tools, which make it easy for an individual or team to get started on a SecDevOps journey.
- Policy Management: GoSDL
- Cloud Security:Fugue
- Security Testing:SonarQube (SAST);OWASP ZAP (DAST)Contrast Community Edition (IAST & RASP)
- Container Security:Snyk
- Vulnerability Management :NIST CVSS Calculator
However, don’t get trapped into thinking more tools equals more security. If you are not effectively pulling this data into a workflow, then it just creates more work with fewer results. This is where SecDevOps orchestration is important to link the data together to provide actionable insights and a single source of truth.
In a containerized, microservices world where machines are proliferating, what’s the best way for people to be sure their machine identities (e.g. SSL/TLS certificates) are protected?
Brittany: This is simple math: Increased Microservices = Increased Attack Surface. It is one of the most obvious places to engage security to consult on the right architecture and incorporate basic automation to ensure machine identities are protected based on the company’s policies, yetless than 20% of companies do. This is a great example of why it is important to focus on AppSec processes, not just the tools, to make sure the right policies are applied at the right time.
What’s the best way for application development teams to use machine identities that don’t create vendor lock-in to a particular tool, cloud provider, or certificate authority?
Brittany: Vendor lock-in remains one of the biggest concerns across all solutions, which is why leveraging orchestration platforms that have been built with interoperability in mind (think plug-and-play connectors) to manage machine identities as part of a comprehensive SecDevOps program (not just standalone automation) will make sure that development or feature teams can effectively use machine identities without vendor lock-in.
What do you think of RASP? Has it the potential to make people lazy and circumvent proper process?
Brittany: As with all security testing, there’s a right time and a right place to use RASP, but it has to be part of an application security program, not the lone approach. I won’t go as far as to say that it will make people lazy and circumvent proper process, but using RASP alone is like loading up on vaccinations to bolster your immune response, and not managing your health day-to-day (policies), or getting check-ups (security testing).
What’s your favourite SecDevOps fail story?
Brittany: I wish it was just a story that happened one-time, but unfortunately, it’s the same story that I hear again and again. I call it ‘AppSec Roulette’: a development team starts a project and has read all the policies, so they make their architecture decisions without consulting security. Fast forward two months and they’re ready to ship and finally engage security. They assume they’ll move to GA as 5 out of 6 times they can either quickly mitigate the issues or override any objections to fix later, but the sixth time… that’s when they have to trash the whole thing and start from scratch because they followed the wrong policy; a mistake that would have been easily prevented if security had just been a part of the decision making process from the beginning. Unfortunately, the reluctance to engage them earlier comes from concern that security will be an inhibitor, when the reality is that they’re an advisor.
How would you describe security posture ideal state?
Brittany: There is no perfectly secure code. New attack vectors are created and discovered every day, so yesterday’s “secure” may not be today’s, which is why the adage “perfection is the enemy of progress” is important to remember in AppSec. Teams need to make this their mantra in regard to AppSec (as they have already done with other SDLC components). This means that in the ideal state:
- Security teams are embedded in the day-to-day of development
- Security policies are clearly defined and understood before coding begins
- Security testing is done regularly without fear
- Security debt is managed in line with business priorities
- Security has regular feedback loops at every stage of the SDLC
This is not a utopian state, but rather a pragmatic and achievable one that should feel very familiar as it is not unlike the marrying of Dev and Ops.
How can organizations get agility and security without sacrificing speed? What’s the best way to maximise developer productivity? Letting them go rogue or giving them guardrails?
Brittany: The core of any successful AppSec program is its policies. When you have good policies, developers are enabled to choose when to go rogue or follow the guardrails. With the right information from the beginning (AKA policies), these educated decisions become part of feedback loops and reduce future work, which has a hard ROI for development costs of up to 100x less than when vulnerabilities are fixed in production.
Will DevSecOps last forever?
Brittany: No. And that’s not because the threats will go away, and therefore the need for AppSec, but rather security will become such a normal part of our development processes that there will be no reason to distinguish it separately. The need for AppSec processes to be a part of the SDLC will only grow as our digital world grows as the only way to close the gap between the adversaries and defenders will be to security is built into the code from the beginning.
Machine Identity Security Architecture
Related posts