Today, we have a new entry in our security leader interview series. Recently, we sat down with Adam Surak, Director of Infrastructure and Security at Algolia, 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 how you got to where you are at Algolia
My name is Adam Surak. I am the Director of Infrastructure and Security at Algolia. I originally joined Algolia in 2014 as an SRE focused on automating infrastructure. At the time, Algolia was 8 people. Now it’s 350, and I manage a team of 22, so quite a bit of growth!
Prior to Algolia, I was a teacher and researcher at a technical university in Finland.
What is your history with security?
Probably my original and most fun experience with security was back in high school. I spent some time developing a web game. At the time, it was a popular thing to try and hack web games, so I had to spend a lot of time figuring out how to protect it.
Later on, at my job at the university in Finland, I worked with several Russians who had worked in state security in Russia. They were very strict and focused on security. Whenever we developed something, they took the approach of asking “how can we hack it?” This was my first exposure to this angle of security; this way of looking at things.
How have you approached security at Algolia so far?
Over the years at Algolia as we grew, we started to have real security requirements. Our primary problem, from a security point of view, is that to make Algolia’s service work, we need to have copies of our customers’ data, and we need to be able to read it, so we can’t just encrypt it at the edge and never look at it. This opens up a lot of potential security risk. As a result, we started to focus on security early on in the company’s life.
In early 2015, I was tagged to take on security for Algolia, as I had the deepest knowledge at the time. Now in 2019, I have a team of 3 security engineers, compliance lead, and support of an experienced legal team. We focus on security, compliance, and activities like gap analysis and SOC2 audits.
One thing we started doing super early on was focusing on building a habit around securing personal devices. We had a lot of people coming in and out of the office, but people frequently left their laptops and such unlocked. We implemented a “shame channel” in Slack, so that if you catch someone’s device unlocked, you post in the shame channel on their Slack account. It’s a lighthearted way of keeping people accountable and building the habit around keeping their devices secure. Nowadays, people tell me they even lock their computers when they’re alone at home and get up to go to the bathroom! So the habit has really caught on.
What is your philosophy on security?
I would sum it up by saying that security shouldn’t be something that gets patched on top. I truly believe that security and compliance need to be automated. A lot of things that we’re doing with security can be written as code. Historically, security engineers haven’t been looked at as software engineers, but they need to be today. Their job is to automate. The scale is too large to check everything manually.
Don’t reinvent the wheel. There are a lot of tools that have figured an aspect of security out. Take advantage of them.
Another thing I believe is of the utmost importance is finding ways to hardcode security into software. In the past, a lot of security has just been policies that no one wanted to follow. Today, these policies need to be brought into the software. One example is with passwords. Nowadays, you prevent people from having an insecure password in software. You force them to enter a secure one or else they can’t sign up or log on. We don’t do that with other security issues, but we should.
Security needs to be brought closer to developers. At Algolia, the security team sits down with developers and does a PoC of the code they want to create. They look for potential weak points and security risks together. You have to find a level of cooperation, and have the teams work together to solve problems. If the security team is just calling out risks or compliance issues and walking away, you won’t end up with a strong security situation.
How have you scaled and evolved security at Algolia?
Scaling security is a tricky question, because it’s rarely possible to scale the security team at the pace that company scales. That has been the case for us at Algolia.
In 2015, one of our customers requested that we do a pentest. It was our first one. When the report came back, they called out a couple things that didn’t matter, and a couple things we didn’t originally think were too important, such as our SSH board being exposed to the world (since we had built protections on top of it). Eventually, we realized that some of these items were worth fixing and it’s strengthened our security.
At the end of 2015, we felt confident enough to open up a bug bounty program, in invitation-only mode. We were 25 people at Algolia at the time. We invited a lot of people and eventually felt like we had caught most things, so we opened it up to the public.
It was the biggest security surprise in our company history. After a couple days, everything blew up. We got flooded with alerts and emails, and things started breaking. It took us two months to recover. There were a huge number of issues!
It’s much smoother these days, since we caught up on our security debt from the first effort. It also has another important effect: when you’re on the public record, you can’t rely on “security by obscurity.” It adds a level of pressure. When people internally are saying something is an issue, it really helps to also have someone external say the same thing. It makes it real and makes you want to fix it, rather than fall prey to the belief that the issue is too small and no one will find it or be bothered by it.
Don’t treat security like an afterthought. Invest in it early. The longer you delay, the bigger your security debt becomes.
We’ve also tried to bring about a security mindset at Algolia. Security people think differently. They’re not focused on what a feature does; they care about the risk and how they could be exposed. This mindset tries to do away with the natural inclination to be protective of your work and shield it from a security eye. By paying attention to security and showing people the impact of an exploit (by exploiting it internally for example), you can really communicate the importance of security in a way that sticks with people. It makes the impact real.
What are the challenges you see blocking your ideal state of security today?
The tools out there aren’t focusing enough on the signal to noise ratio. We need to shift that mindset and push tools towards only outputting actionable information. A lot of security tools output absolutely everything, so the real signal is buried in noise. This is super discouraging to the user. It would be much better to start narrow with the outputs and incrementally improve.
Another thing I see is the fact that security is flooded with massive amounts of data. Multiple layers, multiple applications, multiple stacks. The volume of data is so massive that security teams are pushed towards anomaly detection — just looking for outliers.
Another challenge is around vulnerable dependencies. In an ideal world, all dependencies would be kept up-to-date. In reality however, it’s not always possible. Sometimes, a thing you rely on gets deprecated in a new version or the new version breaks something in your flow, and you’re forced to stick with the old version. As a result, you need to be very aware of which CVEs you’re exposed to so you can find ways to wrap protection around them. You also need to decide if these CVEs are actual risks to you and your business. They need to be exploitable and something that could have an impact.
Security needs to move towards actionability everywhere. We need clear signals and clear recommendations of actions to take based on actual risks that could have an impact on your business.
Do you have any advice for companies or people beginning their own security journey?
If you’re thinking about starting a public bug bounty program, pause and talk to someone who’s done it first! It’s a much bigger event than it seems!
Really though, here are some pieces of advice based on what I’ve learned along the way:
- Don’t treat security like an afterthought. Invest in it early. The longer you delay, the bigger your security debt becomes. I knew a company that ignored security for years before finally doing a pentest. The report they received was 100 pages long. They had to stall work for 3-6 months just to take care of the major issues.
- Look at automated tools, especially early on when you don’t have to time to look at all the issues that crop up manually. You likely don’t need to be resilient against big state actors; you just need to protect against competitors and script kiddies at first. The level of security you need depends on the level of threat you can reasonably expect. For most businesses, protecting your code and your applications is enough in the beginning.
- Don’t reinvent the wheel. There are a lot of tools that have figured an aspect of security out. Take advantage of them. Even outside of security tools themselves, you should leverage other companies’ security teams. For example, leverage Slack’s security capabilities rather than creating your own messaging app.
- Finally, ask people in the industry for help! Despite some reputation to the contrary, most people in the security space are happy to share their knowledge and experiences with you. Ask them for coffee or to sit on your board of advisors. Involve them, and they’ll be happy to help.
4
1310
