In February 2019, Threat Stack hosted a meetup with the Boston chapter of Operation Code. Operation Code is a 501(c)(3) non-profit intensely focused on helping veterans, active duty military, and their spouses successfully transition into technology careers and providing continued support as they become established in their new careers. Operation Code is largely veteran-run, but it places a heavy emphasis on bringing non-veterans from the technology industry into its community for the invaluable mentorship and experience they bring to the table.
For the Boston chapter, working with companies like Threat Stack to host events is a crucial element of that mission at the local level. Numerous leaders from Threat Stack across technical disciplines and departments, including Threat Stack CSO Sam Bisbee, spoke at the February event, joined by a common interest to establish lasting mentor relationships with the veteran attendees.
Following the event, Operation Code’s Boston chapter leader, Jack Robertson, reached out to Sam with a number of questions based on feedback from the attendees. While the following Q&A was designed specifically for veterans, it’s worth a read for anyone thinking about a career in technology.
JR: — Sam, you made it clear that Threat Stack is a big proponent of DevSecOps. How do you make this work as an organization without having an equal number of security engineers and developers?
SB: — We have a small platform security team at Threat Stack and are far from a 1:1 ratio between security and engineering. But the very fact that we have a team puts us ahead of the industry, since the average ratio is 0:1. This is especially true for companies of our size (~130 employees).
Having a dedicated, centralized security team that spans platform security, corporate, security operations, and GRC has been important to us from the outset. I’ve seen a lot of unsuccessful attempts at completely distributing security responsibility into other parts of the organization, usually described as “security champions” or “ambassadors,” who are typically well intentioned engineers and PMs who volunteer for additional responsibilities. Generating interest in security and developing allies is absolutely a great idea — but it’s a far cry from actually distributing ownership and responsibility for security.
In contrast, our dedicated team is physically embedded into the various organizations that it supports most often but acts as a central function. The platform security team’s engineers sit with the engineering and operations team members they work with frequently. The Security Operations Center is both internal- and external-facing, but primarily works with customers, so it is physically located closer to the customer account teams. This has been amazing for building empathy (“I know how hard that ask is going to be and they’re already hurting, so we might want to rethink”), easing ad hoc recommendations, and overall building a water cooler sense of one team.
Too many security teams lock themselves in an ivory tower and then wonder why people think they’re acting superior. We’re all on the same team.
JR: — How do you approach getting an organization to care about InfoSec? What have you seen work/fail in the past?
SB: — The short answer is that you can’t make an organization care about security, but you might be able to show them that you both want the same end state and are just using different words to describe it. This can be especially frustrating for professionals coming from other operating environments where an organizational premium on security is presumed.
The old ways of asking for budget simply “because security is important” and hand waving with FUD are quickly losing steam. Security teams have realized that this typically results in sales dictating the enterprise security roadmap and a budget-less security program.
Instead, I take the approach of talking about resiliency, which involves more than just security, in respect to building a “Trust and Safety” program at the company. This isn’t unique to me, and you’ll find a lot of companies starting to have this same conversation, especially as the cyber and physical realms converge in consumer markets (for example, ride sharing companies).
Trust and safety aren’t just compliance checkboxes rewrapped: It’s about instilling trust in your company so the market knows it can interact with your business safely. This forces the business and security teams to orient their conversations around external outcomes, not just tactical operational metrics like CVE counts, and address the entire organization and product, not just the areas they’re interested in.
Many teams automatically jump to technical examples like APIs and encryption in these trust and safety conversations, but a better example is something like “Can parents trust that our mobile game will protect their children’s PII with intuitive privacy settings and moderated interactions?” APIs and data encryption support technical controls, and decreasing the risk of COPPA fines is a positive business outcome, but they’re not the program’s guiding principles.
JR: — How can the organization of the C-suite at a company impact the CSO’s ability to implement policy? Has this changed or evolved over time?
SB: — To your first question, if the CSO doesn’t have supportive peers, or even worse if they have supportive but weak peers, there’s a very small chance of success. This applies to any position and seniority.
To your second question, right now the industry is focused on buy-in and reinforcing culture down every branch of the organization’s structure. If everyone understands the importance and holds one another accountable, then the security team’s perception rises because they’re not the only ones enforcing policy or correcting behavior.
One of the simplest cross-industry examples of this is locking laptops and workstations. If the security team are the only ones enforcing this policy and policing this behavior, then you’ll naturally have a combative relationship. Managers and peers play just as much of a role, whether it be in reinforcing the importance, calling out peers one-on-one for leaving a laptop unlocked, or simply locking the laptop and telling their coworker they “saved them.”
JR: — What percentage of an InfoSec job is course-of-action evaluation and policy writing vs. engineering/code/network analysis (i.e., tech work). Is this where the Compliance vs. Security Analyst/Engineering split is? Does that work-type balance change as one moves upwards into leadership roles?
SB: — I would estimate that the majority of the industry is still in the former category, relying on other teams to remediate the risks that they identify and “manage,” but this is changing in more high tech industries. I see a lot more companies that already have strong engineering and innovation cultures investing in security engineering roles, ensuring that they have dedicated resources and specialists available to build or fix technical solutions.
One of the reasons this is so hard to track is that no one in the security industry can agree on what titles mean from the top of the org chart — CSO vs. CISO — to the bottom — application security engineer vs. product security engineer.
JR: — What technical side projects can someone start working on to increase their chances of obtaining an InfoSec internship?
SB: — It’s less important what your side project is and more important that you’re doing something. Personally I don’t care if it’s a project on Github, a work-study project you took too seriously and “over delivered” on by spending time at night and on weekends, contributing articles or writing blog posts, or how you debugged a really hard IT problem at work that you dug the extra mile on to find a crazy root cause. You’re demonstrating both skill and will.
These are more technical examples because of the question, but apply equally to the less technical aspects of security. Looking for an entry-level position in GRC? Great! Show me how you’re starting to pivot your career and how you grew inside your current profession. I’m more than happy to “geek out” over any topic in an interview.
JR: — Same question, but for a full-time position?
SB: — Same answer, just scaled according to the role’s seniority. For example, at this point I probably don’t want to hear about your home media server in the interview process.
JR: — Another common piece of advice for those interested in InfoSec is to become “the InfoSec person” at work, and build that out into your first real InfoSec job. Let’s say I’ve become that individual: What’s next? How do I start approaching this proactively instead of taking on InfoSec tasks as they come up? What are some easy wins? There must be a better way than cracking open NIST and OWASP papers, at least initially.
SB: — There are no easy wins.
NIST and OWASP are good sources, but don’t forget to learn about what and who you’re operating a security program for. Too many people chase security certifications and knowledge but forget to learn how software is built, how it’s operated, and how this changes if you’re shipping software vs. operating a SaaS model. In other words, before reading OWASP papers, you should probably know how a web server works, be able to understand HTTP, and have an appreciation for how state works in these applications.
Interested in industrial systems instead of software companies? Great. The same principle applies even though the topics are different — although you may be surprised at how much overlap there is between industries.
So to answer your question more directly, your next steps are to understand your operating environment more deeply, both as a business and technology stack. This will help regardless of your security function — drafting a change management process you want people to actually follow, implementing monitoring for your corporate or cloud environment, performing security reviews on code or vendors, etc.
JB: — Any final words of wisdom?
SB: — When it comes to career changes, have a bias for action and don’t be afraid to reach. See a job that you’d love but don’t think you’re qualified? Apply anyway. Two things could happen: You don’t get the job but learn what it takes to get the job you want so you have an action plan. Or you get the job you wanted.
After college, Kevin began his career as a Green Beret with deployments to the Philippines, Thailand, and Afghanistan (x2). Following medical retirement at the rank of Staff Sergeant, Kevin completed dual master’s degrees at the Harvard Kennedy School of Government (MPA) and the MIT Sloan School of Management (MBA) followed by a two year stint with Goldman Sachs.
Currently Kevin is Director of Strategic Projects for Threat Stack by day, a loving husband and father, and — in his “spare time” — a member of the Board of Directors for the Green Beret Foundation as well as a motivational speaker and blogger committed to inspiring and supporting others through stories about his military experiences, his recovery from near-fatal wounds, and his ongoing successes in the civilian world.
Jack Robertson is Operation Code’s Boston chapter leader, formerly an active duty Army Captain. He now works in the Boston technology sector, and has a passion for InfoSec. For Operation Code, Jack finds and builds connections between local veterans, active duty service members expecting to settle in the area, non-veteran volunteers, technology employers, and the many technology education programs here in Boston.
As the CSO at Threat Stack, Sam is responsible for leading the Company’s strategic technology roadmap for its continuous security monitoring service, purpose-built for cloud environments. Sam brings highly-relevant experience in distributed systems in public, private, and hybrid cloud environments, as well as proven success scaling SaaS startups. Sam was most recently the CXO at Cloudant (acquired by IBM in Feb. 2014), a leader in the Database-as-a-Service space, where he played a senior technical and product role.