Recently, we sat down with David Scrobonia, Application Security Engineer at Segment, to discuss his approach to security and what he’s learned as far as security goes throughout his career. We wanted to share the great insights that came out of our conversation.
Tell me a little bit about yourself and your time at Segment
I started at Segment about two years ago as a security engineer. At Segment, our security engineering team is responsible for a couple different security areas: cloud, application, and product. My role is primarily focused on application security, but security at a startup requires flexibility and I often spend time in all areas.
One of our team’s goals is to figure out how we can take idealized, abstract security concepts, like the principle of least privilege or frictionless SDLC integration, and make them practical. It’s easy to talk about security best practices, but much harder to make them a reality at scale.
Making the secure route the easiest and having momentum that pulls people towards secure practices will be much more effective in the long run
One example of how we’re trying to make security practical is by rethinking our approach to internal access control. Maintaining least privilege can be difficult while also ensuring that all of our developers have the access necessary to get their job done. In the past, we’ve had a single person acting as the gatekeeper for granting access to our internal apps, which doesn’t scale and leads to over-provisioning. So now, we’re decentralizing this process through an internal web app that allows people to request access and have other developers peer-review it for approval. Because peer-reviewed approval can be much quicker, we can also now enforce time-based access. For some categories of internal apps, we can force all access to be temporary, without getting in the way of our developers. This is a huge win for practical least privilege.
What is your history with security?
My original interest in security came from my time in school at Cal Poly. We had a member of the Raytheon security team come down and do a full weekend deep dive workshop on security. It was fantastic, and I knew I wanted to get involved with security.
After that, I worked in several internships to explore different kinds of security roles, and spent a lot of time contributing to open source security projects, like ZAP.
How have you approached security at Segment so far? What’s your philosophy?
We have two guiding tenants at Segment for our security team:
- Be pragmatic. Prioritize issues and weigh them against their business value and impact.
- Enable developers. The “old security” mindset looks to say no and add roadblocks. We try to invert that. If there are new projects that aren’t secure or are ignoring security, we look to pair with our developers to address them and make them secure. We work to say “yes” rather than “no.”
We don’t think the right approach is to write a bunch of tickets and dump them on a dev team’s lap. It can be overwhelming and lead to alert fatigue, especially if a number of those tickets are for minor issues. If you don’t work within your developers’ workflows, you won’t be successful.
We find that our developers want to be secure. They want to collaborate with our team to figure out the best way to accomplish their goals in a secure way — where their focus should be and what the risks are so that they can continue to move fast without sacrificing security. Our goal is to provide the tools and collaboration needed to be as effective as possible when considering security.
Netflix’s security team has a great approach to this problem with their “guard rails vs gates” and “paved road” philosophies. Making the secure route the easiest and having momentum that pulls people towards secure practices will be much more effective in the long run as you continue to scale.
How have you scaled and evolved security at Segment?
Scaling security really depends on the stage of your company. It’s much different at a startup than for a large enterprise. The tech stack is simpler, there are less people to consider, and there are no legacy apps to deal with. These factors make things much simpler when you think about scaling.
Static analysis tools are a great example of where I see a change in the security community’s approach. A lot of SAST tools aren’t designed for startup needs. They’re built for older languages, take too long to run, and try to do too much. For small security teams, it’s much more effective to spend time automating away low hanging fruit with smaller, targeted tools (like security linting), and then scale them up as you grow. Security linting doesn’t provide the kind of coverage or depth traditional SAST does, but they also don’t have false positives and the maintenance that traditional SAST carries with it. For a small security team, this is an easy tradeoff. Linting runs faster and is quicker to integrate with startup processes and infrastructure.
Once you have a good solution for your needs as a startup, you can iterate on these tools and grow them from there. This is an excellent way to scale until you hit the stage of many frameworks and languages, in which case you’ll need to either migrate to a SAST tool or build an internal management layer to aggregate all these specific security linting tools.
Start with low hanging fruit and work your way up. It’s more manageable to continually raise the security floor up an inch where you can, than trying to solve a problem all at once.
When you’re thinking about scale, you also have to look beyond tools. Systems and processes that work fantastically at one stage may be completely broken at the next stage. This is something we take stock in at Segment every so often. A good example of this is our security design reviews. Today, one security team member will meet with devs to diagram out a threat model for new projects — the risks and requirements. As we grow, this is starting to hit the scale limit, and the sec team is becoming a bottleneck. That means we need to change the process to enable devs to do threat modeling themselves and submit to the sec team to review, rather than let the sec team become a blocker in the development process.
What are the challenges you see blocking your ideal state of security today?
For me, the ideal state of security is about automating out classes of problems and vulnerabilities that have already been solved. Many security problems have been solved today technically, but actually making that real and putting it into practice is a real challenge. Figuring out how to take these technical solutions, automate them, and fit them into real-life working processes is an ongoing problem.
Personally, when I think of challenges, I have to include the fact that the security space is huge. There is so much to learn and take into account. On top of that, there’s a lot of strong opinions out there, so it’s not obvious what’s right. Figuring out how to be pragmatic in this space is a challenge for everyone and something I believe we can all do better at.
Additionally, something I work on and think remains a need is to make security usable and approachable. Having processes and tools that do the job in a technically correct manner but are difficult to interact with are essentially useless in practice. We need to have usability and relevance for our tools and practices. It’s about getting people used to doing security and getting involved so that they can scale from there.
What excites you about the future of security?
A major thing about the future of security that I’m looking forward to are tools geared towards visibility, whether that’s asset management, data classification, or dependency management. These are all hard problems, especially at scale. There are some really cool tools and projects focused on trying to simplify and automate visibility, so that you can actually see and understand what’s happening in your environment without having to manually crawl through it all.
Part of the difficulty with this problem is that everyone’s infra is inherently unique, so teams often have to build solutions themselves or ignore the problem. It’s a huge gap in the security tooling landscape that should be exciting to watch. The tools that are solving this problem are leaning into industry trends to make their solutions more general and scalable: greater numbers of organizations leveraging development frameworks that are easy to integrate with and an explosion of SaaS tools that provide API’s to tap into.
Do you have any advice for companies or people beginning their own security journey?
For people who are trying to get into the security industry: contribute to open source projects. The community is super strong. Go to local meetups and get involved. Ask for advice and hear other people’s experiences. The industry is very friendly if you just show up and are excited to learn.
If you want to get into security and you have a different type of IT background, one thing I recommend is learning how to code (if you can’t already). Security teams need to be able to build, and being able to code can help you empathize and understand your developers, which is a key part of being a good security engineer.
For companies starting off their security journey: start with low hanging fruit and work your way up. It’s more manageable to continually raise the security floor up an inch where you can, than trying to solve a problem all at once. Focus on the pieces you can quickly automate away. If there’s a product out there that fits your needs and tech stack, go get it. If there’s not, see what you can build with your team.
Work to instill a security culture at your company. Everyone can be some level of a security champion, and develop a security “Spidey-sense” for knowing when something needs a little extra security attention. It’s not about always having the right answer, it’s about being aware of when you need help.
People’s mindset and awareness is what matters. As a security leader, you want your team to perform constant mental checks for what they’re working on if it touches something that merits security attention (e.g. auth, crypto, sensitive data). The team should understand which parts of the company or application could pose security risks and to pay extra attention if anything they’re doing touches those areas.
Thanks so much to David for his time. If you’d like to read more interviews with people in the security space, check out our conversation with Adam Surak on approaching security at Algolia.
