Why your Application Security needs “Skin in the Game”

What is “Skin in the Game”?

“Skin in the game” is a phrase, commonly attributed to Warren Buffet. It refers to the scenario where the person making a recommendation/giving advice has some personal risk involved in making said recommendation/advice. Put simply, it can be encapsulated in expressions like “Practice what you preach” or “Eat your own dog food”.

Why “Skin in the game”?

I recently finished reading a book by Nassim Nicholas Taleb, entitled “Skin in the Game”. It was an insightful read. The author uses the aphorism to exemplify several scenarios, where lack of “skin in the game” has resulted in huge downsides and systemic disasters. He has especially focused on events and decisions taken by several “charlatans” (his words) in the financial industry, which has fetched them great returns personally, but led to massive downsides and collapses of the system, later, which these charlatans have dismssed with oft-cited remarks of “market conditions” or “unforseen circumstances”. A key point, among several others is that systems need to be designed with more skin in the game, so people can’t get away with bad decisions that have great upside for them, but little downside in the event of an adverse event.

As I read this book, I drew several parallels with the security industry, especially application security. Often bad decisions are taken by people within an organization, with littel regard for application security. But during a breach, organizations and many of the same people can literally “wash their hands off” any responsibility often resorting to blame-games and other bromides.

I realize that there are many small and large ways in which we can bring about better application security (if not overall security) with a keystone concept like “skin in the game”. I have tried to identify a few simple ways in which this can happen, in the form of examples, that can be certainly helped by, if not completely mitigated by more “skin in the game”

• When you get Business/Product Managers in the room for a facilitated Threat Model, in which they (are made to) understand multifarious threats to your application, you are ensuring their skin in the game. They appreciate, understand, respect and are made accountable for security
• When you tie security risks to product functionality/features, thereby breaking the mould of security being considered “non-functional requirements” (Words matter. Read: “nonfunctional” == “non-essential”), you are creating a systemic “skin in the game”. This becomes more powerful when you can physically link security risks to product features (abuser stories).
• When you train your developers with material more than a trite “todo security list” (adversarial simulations, breach examples) you create an elevated sense of awareness and responsibility. You create “skin in the game”
• When you include specific security elements in your Acceptance Criteria, visible for your entire Engineering Team to see, you create systemic “skin in the game”
• When you create bug tickets instead of gigantic PDF reports and mark developers or ops folks against these tickets, you are fostering individual “skin in the game”
• When you capture vulnerabilities (or fail builds) in your CI pipeline for security exceptions and violations, you are fostering systemic “skin in the game”
• When you create “security as code” where pentest/bugbounty results are converted into security regressions, you alleviate the “I can’t recreate this bug” or “I can’t figure out what it is” problems for developers. You are engendering “skin in the game”
• When you incentivize defense as well as offense to a reasonable extent, you create “skin in the game”.
• When your application security experts/pentesters work with your engineering teams to find solutions, rather than giving high-level “You have to do input validation” type solutions, you are building a culture of “skin in the game”.
• When your Product Design meetings have active participation from AppSec SMEs, you are creating “skin in the game”
• When you have security represented in every phase of your Software Development Lifecycle, you automatically create more “skin in the game”.
• When you (as a business manager or customer) tie security outcomes to overall application success outcomes, you ensure “skin in the game”. This should especially happen to customers procuring third party applications.

More initiative and innovation tends to happen with more “skin in the game”. While I have captured some steps you can take to enhance application security through skin in the game; This is by no means a comprehensive list. I would love to hear more from all of you on this front.