Anshuman Bhartiya - Principal Security Engineer at Thirty Madison

Anshuman Bhartiya: personal site, Twitter, LinkedIn

Tell us a little about your current role: where do you work, your title and generally the sort of work you and your team do.

I am currently a Principal Security Engineer at a health tech startup based out of NYC - Thirty Madison. I lead Product Security for all of our products. We are a pretty lean security team and my peers focus on other areas such as Cloud Security and Incident Response. Within Product Security, our mission is to safeguard our patient and company information by building security in the products’ software development lifecycle. In other words, we are trying to make security easy for our developers so that they don’t have to worry about it.

How do you spend your time day-to-day?

My day-to-day really depends on my priorities, which change quite frequently since I am a one man Product Security team for now. To break it down further, I always have multiple projects in progress that are focused on improving our product security posture. This could be implementing SAST or researching secure by default frameworks and libraries for our custom code. I have to be pretty hands on with these because I own the entire project from the design to the implementation.

I normally break down a big multi-quarter project into smaller chunks (milestones that could be completed in a quarter) and then further break a milestone into 1-2 week sprint tasks. The OKRs are usually quarterly or whatever the organization’s cadence is and there are some success metrics that get tracked based on a milestone and are outcome based that are incremental towards the bigger goal.

Outside of these core ProdSec projects, there could be other cross functional projects going on that could demand my attention. I am always watching our company’s Slack closely to see if anything comes up and I try to unblock others, especially if they are looking for generic security guidance.

In addition to these, I also represent our security team in leadership meetings as well as other cross-functional meetings. One example is the architecture review board meeting, where we have representatives from other teams (infrastructure, engineering, data, etc.) and we discuss the various design documents that get proposed by our engineers. If I still have time left, I try to keep up with our vulnerability management program and ensure things aren’t falling through the cracks.

You first got the Principal Engineer title when you joined Thirty Madison. Can you talk a little about the process for finding that role?

When I was interviewing for this role, I was talking to a handful of companies. I must have spent 2-3 months interviewing and in the end I had 5-6 offers in hand. Some of these offers were from big tech public companies, while others were from private startups (both early- and late-stage). The leveling was also all over the place. I had offers for Senior, Staff, Sr. Staff and Principal (which is what I ended up taking at Thirty Madison) across these companies. It is worth mentioning that even though the levels were so different, the overall total comp package was in the +- 100k range across all of them. In the end, it really boiled down to how much risk I was willing to take in the company as well as my career growth opportunity. It is also worth highlighting that one thing I realized during this process is that companies do leveling differently and so I really don’t know if simply being a Staff engineer in a company is representative of anything in particular as it could mean different things in different companies.

Now, I would be remiss if I didn’t mention the fact that I was also rejected by a handful of them. Most of the rejections came early on as I was still getting in the interviewing groove. I learned from each rejection and made sure I didn’t make the same mistake again. After every interview, I took notes of the areas that I had knowledge gaps in and studied those areas before the next interviews. The interviewing process was also vastly different across different companies. Some wanted me to clear the same tech screen that a fresh graduate would be expected to clear. These included questions like - symmetric vs asymmetric encryption. If you didn’t already know, this is mostly a theme in FAANG companies. I am not a big fan of this style (especially for senior folks) but I do understand and respect the process. Some were more appropriate for the actual job and had relevant questions pertaining to the job responsibilities. One thing that was common across was the type of interviews during the onsite stage - coding, design, behavioral, security focus. Every company I interviewed at had at least these 4 rounds in their virtual onsite stage. There were different flavors within these rounds as well. For example, in the coding round, some wanted me to know the ins and outs of all data structures I chose and their time/space complexity. Otherswere more focused on solving a real world problem, problem solving and analytical thinking. Even writing the pseudocode worked in some of these situations.

In the end, I don’t think there is a right or a wrong way of going about interviewing security professionals as each company’s mileage may vary. But, as a candidate applying for these roles, you definitely have the option of picking and choosing the ones where you think you will have the biggest impact and vice versa.

What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?

Personally, I’ve switched companies more than the average IT professional would (with valid reasoning). I think it has worked out for me in the end because I feel that my varied experiences has given me a broader perspective, having experienced:

• Different companies

• Different verticals

• Different scale/size

• Different technologies

I’ve seen some issues are the same across different companies while some of them are vastly different and company-specific. Having this diverse perspective is definitely one of the biggest factors which has allowed me to join as a Staff+ security engineer in multiple companies.

Vulnerability management and attribution is something I’ve seen pretty much every company struggle with. Things like:

• Which backlog to report vulns in - specially when the security team and engineering teams all operate in their own ways and the security team doesn’t really want to add more work (than what’s absolutely necessary) for the engineers

• Do we report all similar issues in one ticket or file individual tickets per instance. If we create individual tickets, that’s a lot of tickets. If we pile all similar instances in one ticket, how does engineering teams report if they don’t fix all of them?

• How do we know how to attribute a particular issue to a team/individual. Attribution, by far, has been the most common issue I’ve seen in all the places I’ve seen.

• What do we do when tickets are not addressed. How do we enforce SLAs? This is a very hairy topic, one that must be approached with extreme caution ensuring all the stakeholders are brought along with any decision that gets made otherwise it can backfire and create a lot of friction.

In addition to that, my contributions in the OSS community, including security tooling, the talks I’ve given at various conferences and my background spanning multiple areas within Information Security (Cloud/Infrastructure Security, Automation, Incident Response, DevSecOps, Product/Application Security, etc.) have been important in me reaching Staff+. I think your brand matters and people recognize you if you put yourself out there.

Some of Anshuman’s Public Work

• Building a Product Security program from scratch

• A Lightweight Approach To Implement Secure Software Development LifeCycle

• Future of Application Security Podcast: Lessons From Building Thirty Madison’s Product Security Program

Where do you feel most impactful as a Staff-plus Engineer? A specific story would be grand.

I feel I have the most impact as a Staff+ engineer when I consider myself somewhat of a SME (subject-matter expert) in an area. Especially if there are not a lot of folks like me in the company. That, coupled with the breadth of experience I bring having worked in different companies, really gives me the edge where I can reason about the different approaches of a solution being proposed. I can apply how I might have seen them work or not work from my previous experiences.

For example, when I was with Atlassian we conducted a marketplace bug bounty program for vendors who build 3rd party plugins that get installed in Atlassian products. We are talking about more than 50 vendors each having their own bug bounty programs with unique scopes and sets of researchers. We had Bugcrowd’s ASE team do bulk of the triaging but our team was responsible for pretty much everything else: responding to researchers, helping out ASE for clarifying questions, rewarding each bug, determining severity, identifying issues in the core framework provided by Atlassian to integrate these plugins, resolving conflicts, etc. I was the tech lead on this project and my job was to ensure we ran this program successfully and that we improve the application security posture of our marketplace ecosystem overall to help build trust in our customers.

Not to mention, the communication and decision making involving multiple stakeholders (our customers, third party vendors, researchers, Bugcrowd ASE, our engineering teams, our own security team) had to be swift and efficient to avoid any major hurdles and break down in the process since we were running this entire program in a time-boxed manner over the course of few weeks and the success of this program could really help shape the story of how Atlassian secures its third party marketplace ecosystem.

Now, I had been on both sides of bug bounties - as a researcher as well as a program owner at prior companies so I was very well aware of the gotchas, things to do, things not to do and how to run bug bounty programs to get the max ROI out of it, as well as ensure that the researcher community was treated fairly. I felt really comfortable leading this program as I had done similar things elsewhere but at a smaller scale. This was my opportunity to do it at a much larger scale where in I could apply all of the learnings I had from prior experiences.

As another example, I’ve been able to take my experience across security programs to create a hands-on framework for Building a Product Security function, that I’m able to apply at my current job.

Can you think of anything you’ve done as a Staff-plus engineer that you weren’t able to or wouldn’t have done before reaching that title?

Making decisions that could potentially have an org wide impact is something I would normally not have done before reaching Staff, even if I was very confident in that decision. I believe reaching Staff+ gives you an implicit authority to make those kinds of decisions. There is some rapport and trust you build when you reach Staff+ levels and you should be leveraging that to the best of your abilities. However, I also think there is some impostor syndrome factor in play at Staff+ levels. But I think this is completely normal. In fact, I would even say that some level of impostor syndrome is absolutely necessary to get to Staff+ levels. It is a spicy take but I can bet there is some truth to it because as a Staff+ engineer, you are expected to be humble and constantly learn/grow not only yourself, but others as well and some of that is definitely fueled by impostor syndrome.

When you’re doing this big investments or cross org wide impact initiatives, how do you vet ideas before going all in on them? Trying some cross org initiative that ends up not working out or needs to meaningfully change could damage your internal capital as the only or small security team, how do you gain confidence in your decisions and validate them, build consensus, etc.?

I follow the tried and tested way of building a POC, getting buy in from stakeholders, proposing the actual implementation via a RFC/Design Doc along with the comparisons of alternative ways. And, doing all of this whilst ensuring that I am constantly communicating and answering questions as they come along.

I believe that good documentation goes a long way and gives you the opportunity to show others that you’ve done your homework and also allows others to pitch in with their ideas and feedback in an open forum (i.e. have the discussions openly on the design doc).

I am not scared of failing as long as I have done my part of ensuring that I have brought along everybody with me at every step of the process and made it transparent and clear as to how decisions are being made. Working openly in this manner where I am not dismissing anybody but rather inviting others to collaborate and empowering them to contribute their own ideas has allowed me to build rapport with my stakeholders.

If in the end, it doesn’t end up working as desired or intended, that’s totally fine because then we would have had everything documented and well thought out with the hopes that we can learn something from it and try not to repeat the same mistakes again.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

I’ve had some great conversations with folks who I met through “Donut” in Rands Leadership Slack. I highly recommend joining that if you haven’t already!

What about advice for someone who has just started as a Staff-plus engineer?

1. Take a step back from your job responsibilities; as a Staff+ engineer, the expectations can be a little vague, or even seemingly unreasonable in the beginning. In other words, your job responsibility could mean you doing a million things (Build a Product Security program, help the org achieve XYZ certification, Improve Detection & Response, etc.) but it’s just not possible to do so, especially if you are the only one in your team. In that case, it is more important to not focus on what your responsibilities are as much as it is to figure out what the problems are, and what is it that matters to the org, so you can meaningfully bring about change for the better.

2. Start having conversations with your peers; talk to them about their problems and concerns, what keeps them awake at night, ask them if they know about any major security debt or concern that hasn’t been addressed, figure out how they work so that you could try to help improve their security posture by integrating within their workflow

3. Try to listen more and talk less.

4. Figure out ways in which you can connect people who are trying to solve similar problems, if not same - across the industry. It is also important to connect with people facing the same challenges in your org so that you could learn from their experiences. Talking about those issues or broadcasting in all hands, other org wide meetings could be a powerful way of getting this message across and asking for help. Getting folks to fill out short survey forms could also be a good way to get a pulse on things.

5. Build relationships with folks who can really partner with you and act as a champion in your initiatives. This could be tricky but identifying folks who show genuine interest and curiosity in the things that you are trying to do, selling to them that your problems are worth their attention. It could be an EM or an entry level engineer in a team of engineers. These are the folks you would want to be partnering with to champion your initiatives. For example - you present about threat modeling in engineering all hands. You suddenly get 1-2 folks reaching out to you and thanking you for the presentation and sharing their experiences. Another example - Someone in the org posts a lot of security articles in a Slack channel and wants to engage in security conversations. You would want to start building a relationship with these folks and eventually have them champion and partner with you in your initiatives.