Operation Code and Sam Bisbee Talk About Getting Started in Security

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.

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.

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.