I realized I found security really interesting early on in my career as an engineer, back in 2015. It was a useful complement to infrastructure and networking, the other interests I quickly picked up. However, while security roles are notoriously hard to fill, they’re also notoriously hard to get when you haven’t had one before. I assumed security work would be something I’d pursue once I felt more grounded in my skills as a site reliability engineer – meaning I might have waited forever, if left to my own self-education.
Instead, early last fall, a friend reached out to me about an opening on her team at Salesforce. They wanted someone with an SRE background and security aspirations. Was I interested in pursuing it as a job, she asked, or was it just a professionally adjacent hobby?
I had to sit and think about that.
For about five seconds.
I typed back a quick I VOLUNTEER AS TRIBUTE extremely casual and professional confirmation that I was indeed interested in security as a career, and then the process began in earnest.
Starting the conversation, completing the interview
My interview and hiring process, from first conversation to gauge interest to phone screen to final interview, took about two months. (This was longer than is typical for this role, as I was out of town for three weeks when I first applied.) I have an eclectic resume, as you’ll learn later, and, during my interview process with Salesforce, I got to highlight things that I have learned in different ways: through casual conversations, the formal interview, and even some impromptu network diagramming on a whiteboard when I realized my hand gestures were not up to conveying the complexity of what we were discussing. (Spoiler alert for preparing for a security interview, which I’ll talk much more about later in this post: if in doubt, it’s always the OWASP Top Ten. Also worth checking out: Salesforce’s interviewing trail.) I was also able to meet a DevOps architect who, like me, thinks it’s extremely important to encourage junior engineers, which gave me a good feeling about Salesforce being a place I could be supported to successfully make the move into AppSec. We benefit enormously from diverse experience, so I was glad to know I was being assessed on my skills, not my years on the job or other sometimes-superficial markers of seniority. When I left after the interview, I wasn’t certain if I’d done well or not, but I felt like I’d done as well as I could have and demonstrated the things I actually know, which is a good interview in my book.
An ops CV for security
I began my career as a writer and editor. I attended code school in 2015, and my first engineering job was at a consultancy that focused on infrastructure and process. After three years of consulting, I moved to a role as a site reliability engineer (SRE). Throughout all this, I cultivated my interest in security by going to DEF CON, Women in Security and Privacy (WISP), Day of Shecurity, and the many other security events that take place in the Bay Area. It became clear pretty quickly that ops and security have a lot of things in common – that is, beyond a reputation for being risk-averse and more than a little curmudgeonly.
There are skills that are essential for both, including:
- Networking, infrastructure, AWS, and port hygiene
- Coding, especially scripting; Bash and Python are great choices but aren’t the only valid ones
- Command line skills
- Looking up running processes and changing their state
- Reading and manipulating logs
The skills that are less explicitly required but that I’ve found to be really useful include:
- Communication, both written and verbal
- Documentation creation and maintenance
- Teaching
- A UX-centered approach
Here’s what I mean by that last one: I have some education in UX principles and practices, and I’ve done official UX exercises as part of previous jobs. I’m still able to, if needed. The part of it I use most often, though, is what I’ve come to think of as a UX approach to the everyday. (Beginner’s mind is a similar idea.) What I mean by that is the ability to come into a situation with someone and assume that you don’t understand their motivations, previous actions, or context, and then to work deliberately to build those by asking questions—while resisting the very normal human inclination to think that you totally understand this other person’s situation well before you actually understand it. The key part is remembering that, even if someone is doing something you don’t think makes sense, they most likely have reasons for it, and you can only discover those by asking them.
This was useful in ops, when I was often dealing with app engineers who weren’t familiar with my part of our systems, and it’s useful in security, when an incomplete understanding of why people do what they do can result in processes that no one will use and vulnerabilities left unchecked. It makes you nicer to deal with, yes, but also much more effective in your work.
My accidental security education
Here’s something I only realized after getting this job: I’ve done a LOT of security learning since becoming an engineer. I just didn’t fully realize what I’d been doing because I thought of it as just having fun. Meaning: I did none of these things with interview preparation in mind. The closest I came was thinking, “Oh, I see how this might be useful for the kinds of jobs I might want later, but I’m definitely not pursuing them right now.” It’s a great way to get an education in something, with no pressure and all of the enthusiasm of the hobbyist, but I realize it’s not going to be accessible for everyone.
These are the things I did over the last four years that ended up being really helpful as I went through this process:
- Going to DEF CON four times
- Going to Day of Shecurity three times
- Being a beta student for an eight-part course all about writing secure code from a friend’s security education startup
- Attempting Capture the Flags (CTFs)
- Talking security with my ops coworkers, who all have opinions and stories
- Volunteering for AWS IAM work whenever it came up as a task
- Classes at the Bradfield School of Computer Science in computer architecture and networking (I suggest getting a company to pay for this)
Every one of these things gave me something that either helped me feel more adept while interviewing or that I was able to mention when answering questions and discussing the job. Four years is a lot of time to pursue something casually, especially since I went to an event at least every month or two.
I’ve also benefited from industry newsletters, especially these:
- The Cloud Security Reading List
- Julia Evans’s weekly emailed engineering comics
- Devops Weekly
- SRE Weekly
- Crypto-Gram from Bruce Schneier
Many of these are ops-centric, but all of them have provided something to this most recent professional transition. Very few issues and problems exist in only a single discipline, and these digests have been really useful for seeing the regular intersections between things I knew and things I wanted to know more about.
Interview preparation, done deliberately
Once the interview was scheduled, I dove into interview studying. I made a wishlist of everything I wanted to be able to talk confidently about, prioritized it, and began working through everything I could. I touched on about half of it, as it was an ambitious list. I studied for about a week and a half, a couple hours at a time. I focused on three main things:
- Exercism, primarily in Python
- The OWASP top ten from 2013 and 2017
- Blog posts that crossed my current discipline and the one I aspired to
The Exercism work was because I never feel like I code as much as I’d like in my jobs, and I feel more confident in technical settings when I feel more fluent in code. The OWASP reading was a mix of official resources, their cheat sheets, and other people’s writing about them; reading different perspectives is part of how I wrap my head around things like this. And the blog posts were for broader context and also to get more conversant about the intersection between my existing skills and the role I was aspiring to. Studying a high-profile breach that happened due to misconfigured AWS IAM permissions, something I was already well versed in, was really useful for this.
(Read about our open source project Policy Sentry automates least privilege in AWS IAM.)
Here’s a grab bag of some of the other things I read, watched, and used that helped me feel better prepared for the interview.
The great and terrible thing about infosec education is that there are so many resources out there for you to learn from. Pick a couple of things you want to get really good at (ideally that you already know something about, that’s already important to your current job or field of study) and keep digging into them. The other thing I’d recommend, which I hear suggested less often, is making sure you can explain what it is you’re trying to understand to another person. I have a couple non-engineer people in my life who let me explain things to/at them, and it’s the single best thing I do to make sure I actually understand something, instead of that inaccurate feeling of “understanding” that actually means “I read that, and the individual sentences made sense,” which is a bit different - and not something you want to realize in the middle of an onsite.
No, really: you can too
I want to leave you with some more general ideas of how to shape your career to more effectively get to the security role you might be seeking.
Find a couple security-essential skills you already know something about and dive deeply into them. For instance: I have a lot to say about IAM stuff, in AWS, Jenkins, and general principle of least privilege contexts, so that’s been something I’ve really focused on when trying to convey my skills to other people. Find what you’re doing that already applies to the role you want, and get conversational in it. Keep up on news stories relevant to those skills. This part shouldn’t be that hard, because these skills should be interesting to you. If they aren’t, choose different skills to focus on, and keep that in mind as you continue figuring out the right place for you in security.
While you’re doing this learning, make sure the people in your professional life know what you’re doing. This can be your manager, but it can also be online communities, coworkers you keep in touch with as you all move companies, and anyone else you can speak computer or security with. Don’t labor in obscurity; share links, mention things you’ve learned, and search for other people interested in the same things.
Build that community further by going to meetups and workshops. When I think about living outside the Bay Area, one of the things that would be hardest to give up is all the free education that’s available. Day of Shecurity, OWASP in SF and the south bay and so many more—and with everything being online now, there are so many more resources available from wherever you live. Follow some infosec folks on Twitter, search on meetup.com, and find your people.
Finally, remember that security needs you. Like all of tech, security is better when there are a lot of different kinds of people working out how to make things and fix things. Please hang in there and keep trying. And good luck. <3
Top comments (0)