A Seat at the Table

Adam Shostack, President, Shostack & Associates  twitter, linkedin
abstract slides video

By having a “seat at the table” during the early phases of software development, the security team can more effectively influence its design. Adam describes how security can earn its seat at the table by using the right tools, adapting to what’s needed by the current project, and the soft skills that will increase your likelihood of success.

At a high level, there are two phases in software development.

First, there is fluid dialogue about an idea, where things are fluid, not fixed. Here we’re building prototypes and doing experiments, exploring approach ideas and their consequence, asking questions like “What if…” and “How about…”

As things get hammered out we move to discussion, where we’ve decided on many of the details so things are more fixed than fluid, we’ve committed to an idea, and are working towards production code.

A common challenge is that the security team is only involved in the discussion phase, after many important decisions have already been made, like the technologies in use, how the system will be architected, and how everything will fit together. At this point, any suggestions (or demands) from the security team to make significant changes to the tech used or overall architecture will be met with resistance, as these decisions have already been made and will set the project back.

Security needs a seat at the table, so we can provide input during the design phase.

But seating is limited at the table. There are already a number of parties there, like the QA team, IT, users, engineering, etc. Everyone wants a seat. However, studies have shown that as team sizes grow larger it becomes more difficult to build consensus and thus make progress, so there’s motivation to keep the table small.

Today, security often doesn’t get a place at the table. If all you ever say at planning meetings regardless of what is proposed, “That would be insecure” or “We’ll run a vuln scan / SAST / fuzzing,” then developers will think, “OK great, I know what security is going to say, so we don’t need them here in this meeting.”

What’s Needed For A Seat At The Table?

• Tools that work in dialogue - Tools need to work when things are fluid not fixed.

• Consistency - The same problems or challenges should get the same solution recommendations. Too often developers will get different advice from different security people, which is confusing and makes it hard foir them to do their jobs effectively.

• Soft skills! - At a small table, if someone doesn’t play well with others, they don’t get invited back.

Threat Modeling as a Design Toolkit

Structure Allows Consistency

Threat modeling can help us get a seat at the table, and aving a consistent structure and approach can make threat modeling much more successful.

• The threat model can be created in some design software or done informally on a whiteboard.

• When discussing what can go wrong, frameworks like STRIDE and kill chains provide structure to the brainstorming so we’ll be able to answer the question in a consistent, repeatable way, and come to similar conclusions.

• By discussing what we’re going to do about these threats, we can start planning the security controls, arcchitecture decisions, etc. before a single line of code is written, rather than trying to use duct tape later.

• Reflect on the threat modeling process afterwards. Did we get value out of this? What do we keep doing? What should we do differently next time? Like your development processes, how your company threat models will evolve over time to best fit your company’s unique environment.

Threat Modeling Is A Big Tent

Like developing software, the process of threat modeling can vary significantly: it can be lightweight, agile, fast, and low effort, or big, complicated, and slow. Which one makes sense depends on the project you’re on. Similarly, there are also different tools and deliverables that can be involved.

Think of threat modeling as being composed of building blocks, like how a software service can be composed of many microservices. If you think that threat modeling can only be done one way, like it’s a big monolith that cannot be decomposed into smaller parts, then you’ll lose the value of being able to take advantage of the building blocks that fit with your team’s needs.

Soft Skills

Soft skills are crucial in security.

You might feel like soft skills feel “unnatural.” That’s OK, everything we do starts that way! When you first started programming, did writing code feel natural? Probably not. Soft skills, like anything, are skills we need to learn and practice, by doing them.

Here are a few critical soft skills.

Respect

Pay attention to the person speaking In meetings and informally during discussions. Don’t interrupt, read your email, or have side conversations. This conveys that you don’t value what the person is saying.

Pay attention to the people not speaking Are we giving everyone the opportunity to speak? Oftentimes there are people who are very vocal and loud who can drown out other people. Everyone has something to add, let their voice be heard.

Active Listening

Pay attention, and show that you’re listening with your body language and gestures. Let people finish what they’re saying, don’t just hear the first 10 words and then interrupt, telling them how their idea won’t work. One effective structure, that will feel unnatural at first is:

Assume Good Intent

No one is paid to make your life harder. Everyone is just trying to get their job done, whether it’s shipping new features, designing the product, marketing it, etc. Instead of thinking they’re dumb or uninformed, instead ask yourself:

Everyone’s behavior makes sense within the context of their beliefs.

Diversity

Adam believes diversity has intrinsic value, as it allows you to take advantage of all of the skills, aptitudes, knowledge, and backgrounds that can make your company successful.

However he’s found that you tend to make better progress with executives by making the business case for diversity. Rather than promoting diversity for its intrinsic value, instead make the argument that it will help the business, for example, by referencing studies that show that diverse teams are more effective, by having a more broadly representative team you can better connect with your diverse user base, and the types of behaviors and environments that support diversity (e.g. being welcoming and supportive), also make your team or company a more attractive place to work, making it easier to hire and retain top talent. Conversely, having a culture that drives non traditional candidates away is probably not an environment that people want to be in and will likely cause challenges when you need to interface with other teams in the company.

Questions

This is a great opportunity to train developers how to threat model so they can start to stand their own, looping in the security team in harder cases as needed.

There’s basically two types of metrics, mechanical and qualitative. For mechanical, you can ask measurable questions like, “Do we have a diagram? Did we find threats against this service? Did we file user stories or acceptance tests for each of the things we found?”

On the qualitative side, during retrospectives, you can ask questions like, “Are we happy with the time we spent on threat modeling? Do we feel it paid off well?”

Without secure coding training, developers are more likely to introduce vulnerabilities into the software they write. Once this code has been tested, delivered, and is in production, potentially with other components that rely on it, it’s very expensive to go back and fix it.

By having developers write secure software in the first place, you can limit the amount of rework that has to be done, which improves the predictability of shipping new features. You’re reducing the likelihood that you’ll discover new problems days, weeks, or months later and have to interrupt what you’re currently working on to fix them, at which time the developer who introduced the issue may have forgotten most of the relevant context.

Metrics can also be really valuable here. Track the number and types of vulnerabilities you’re discovering in various code bases so you can show that after the training, your SAST / DAST tools or pen tests are finding fewer issues, which is allowing you to spend more time building new features and less time fixing issues. See Data-Driven Bug Bounty for more ideas on leveraging vulnerability data to drive AppSec programs.