Your team is thinking about migrating from a monolithic architecture to microservices. You’re intrigued. The promises of additional scalability and more predictable deployments sound nice. You’ve also been down this road before, and you know that those promises don’t always equal reality. You also know that migrations to a microservice approach don’t always go as planned.

At Sqreen, our mission is to make security transparent and accessible to everyone. Part of that mission includes sharing what we learn about security and what happens if we get attacked. In this post, we want to share the details of an Account Takeover (ATO) attack against our own internal Sqreen deployment, how we mitigated it, and what we learned.

Security is an ongoing effort. It’s worth assessing your security situation from time to time, and as GDPR fines have started to land, it’s a good time to review your data movement and storage setup. Recently, the news broke that British Airways must pay an astounding £183 million fine because of last year’s data breach.

The world is becoming increasingly aware of the massive amounts of data floating around the internet. Not surprisingly, many people have concerns about this. These concerns have led to a lot of legislation around data privacy, of which GDPR is just one of many. On top of all of this, there’s been the exposure of thousands of MongoDB databases on the internet.

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. 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.

At Sqreen, our company has evolved and changed a lot since we began this journey. Our frontend team is no exception, and as a member of that team, I wanted to take a moment to do a frontend team retrospective and reflect on how we’ve scaled, the mistakes and improvements we’ve made, and generally share what we’ve learned. I hope that this post may help you if you’re undertaking a similar journey.

So, your company has suffered a security breach, and your team didn’t have a data breach plan in place to handle it. That’s bad news, but take a deep breath. You can get through this. Breaches happen, and can be a challenging time, but with some intentional responses and clear communication, you can satisfy customer concerns and move forward. Responding well to the breach is the most important thing now.

At Sqreen, we have an initiative called “Sqreenities.” A Sqreenity is basically a week where you step away from your normal day-to-day to work on a project or topic that is important to you and that has some relevance to Sqreen or security… Pretty cool, no? Recently, it was my turn to do a Sqreenity, and I decided to use my time to create a company dashboard that you can display on a TV anywhere in your offices.

Recently, I put some time aside to write a two-factor authentication app for macOS for personal use. A nice perk of working at Sqreen is what we call the “Sqreenity” — getting to set aside a week at a time to work on your own project ideas. Twofa was my Sqreenity a few weeks ago, after I realized I would want to use a command-line based client for 2FA for macOS, but one with my requirements does not exist yet.

For many SaaS startups, security takes a backseat to other needs and functions in the early stages of the company. This approach often makes sense (you have to have working applications before you can protect them), but what that means in practice is that building a security team is something that is pushed down the road a ways. Without a security team, all security concerns fall to the CTO or another technical leader who may or may not have a strong background in security.