DevSec: Empowering DevOps with Security
By- September 04, 2014
We’ve had an interesting journey over the past few years at Tinfoil. Each year technology evolves, but security is often left behind. As more of you scan with us, we see more issues with current security processes. The biggest problem? Agile development.
We love pushing code often. We’ll make changes to our website or scanner on a daily (and sometimes hourly) basis. As a small team we’re able to run our security tests pre-deploy without a problem, but have noticed a large gap amongst our customers. Over the past year we’ve worked with some of the best and largest enterprise companies to establish a new security practice: empowering DevOps with security and bringing it closer to the source.
Security teams are small, much smaller than development teams. Some companies have a single person thinking about security issues and others have hundreds. A few years back either was OK. New code was deployed once every few months and went through a full QA and penetration testing process. With continuous integration systems and DevOps teams forming, security can’t keep up. New code is deployed daily, if not hourly, and security has yet to become a part of the testing process.
Tinfoil is now working with security teams to relieve some of the pressure so they can work on the big picture. Starting with our web application scanner, you can now pull Tinfoil into your DevOps process without adding any extra burden. Many customers use our API to hook into their CI systems, and we’re working on specific integrations with tools like Jenkins and CircleCI to make the process even easier. These integrations are set up so as soon as new versions of a website are pushed out, Tinfoil scans are run. As we find vulnerabilities we have many ways to export the data, including directly into your JIRA or issue tracker so your developers can fix the problems right away. Our goal is to simplify security while not compromising security.
DevSec is the joining of DevOps and security. Your engineers should feel empowered with security, not burdened by it. We’ll be posting a series of posts on best practices for getting your development teams up and running with a DevSec process. As always, you’re welcome to use Tinfoil to supplement this process. We welcome questions and feedback as we explore this new focus shift. Email or chat with us anytime.
Looking forward to more years of interesting adventures and challenges.
Hiring Great People
By- March 12, 2013
After Tinfoil’s initial funding round, we started hiring engineers but had no idea how to do it. We promised ourselves we’d adhere to two rules:
1) Hire smarter than ourselves
2) Each hire must pass the Sunday and Caller ID Tests
We wanted to hire people that we thought were smarter than us in a relevant domain. A lot of founders we speak to often shy away from this, because they’re uncomfortable leading a team of people that in some way are smarter than them. The “big company” mantra says that you should hire “trainable” people, but never hire people who are as good or better than you; this is known as “job security.” We think that theory leads to a team of B-players, at best, and the speed at which you execute suffers from it. This is one of the few advantages a startup has over a larger company; because you are smaller, you are also more agile and flexible. I like to use the analogy that it is much harder to change the course of a cruise liner than it is a rowboat. The former takes a far longer time and the decision has to be made significantly farther in advance. So, hire smarter than yourselves, move faster than your competition, and win.
I’m not sure who originally told us about the Sunday test and the Caller ID test, but if they remind me I would certainly like to thank them. [EDIT: Turns out Stripe came up with the Sunday test and told us about it. Major thanks to them.] These two very simple ideas have kept us from making some very bad hires, and have convinced us to make others that were great. The Sunday test is as follows: if the candidate is in at the office alone on a Sunday afternoon, would you be more likely to come in and work with them? That answer has to be yes. We want to be excited by our colleagues, and not feel like we’re holding them up or they’re dragging us down. The Caller ID test is equally important, and is as follows: if the candidate calls you on a Friday night and wants to spend time hanging out or working, are you more likely to pick up or let it ring to voicemail? If you wouldn't pick up the phone, that candidate is the wrong hire.
In addition to the above two rules, we later developed a third one that saved us a ton of time. We call it ‘interview day.’ We set aside one day a week where we do all of our recruiting for that week. Prior to implementing this, we would do recruiting basically every day, and it would take us out of the zone, distract us, and so forth. After picking a set day on which to do it, we knew that at most one day a week was taken up doing recruiting, and the rest of the week was spent working on the product for our customers. Having only one day a week on which to do recruiting also forced us to be more selective about who we chose to interview and speed up the process. Since we were only looking for incredibly talented A-players that were smarter than us, this was a great thing.
[UPDATE] Just to clarify the above, we do not mean that we ask candidates these questions. These are questions for the existing team when evaluating a candidate, and it isn't about forcing people to come in on a Sunday, or convincing ourselves that candidates are just like us. It is simply about hiring people we would want to work with, be around, and help / be helped by, no matter what the occasion.