南乐县2017年第二批农村公路及桥梁建设项目招标公告
Co-authored with Mara Pritchard
Technology risk is often seen by security teams as something that should be eliminated completely, not managed. We know how critical it is to avoid the financial losses caused by breaches and disruptions. We also know that avoidance drives top-down pronouncements about which risk can be accepted and which risk must be remediated — which is often viewed as a drain on productivity. But what if risk could help maintain progress, or even increase it? What if engineers had a framework to determine for themselves what risk was acceptable for their projects?
In early 2020, Carta’s security team decided to help the company manage risk by creating that framework. We wanted engineers to become “security owners” — to enable teams to better understand and manage their own risk and be accountable for their decisions, guided by limits assessed by the Carta security team.
The challenge of quantifying the risk
In my experience (and in that of many of my peers), many organizations have tried to move from qualitative risk assessment to quantitative but found it challenging to express risk as dollar values. Decisionmakers can be skeptical about the methodology or misunderstand annual losses. Either of those can lead to the belief that moderate amounts of loss are acceptable, not realizing that small, separate risks add up over time. But traditional qualitative methods eliminate the nuances between different levels of risk. Not all “low” risks are the same, and neither are all “high” risks. And it prevents companies from accounting for and perhaps benefiting from their market and technical strengths.
Carta needed a better way to quantify our risks as a way of communicating the scale of priority, something objective and intuitive. Many security risk quantification methods exist, but we were less concerned about which specific one we might use. Instead, we wanted something we could apply with consistency. Our method also needed to address three components of risk management: the risk a team has, the risk tolerance that leadership is comfortable with, and how proactive teams need to be with security.
Building the framework
We decided to base our risk model on something anyone can understand, something not specific to fintech: the credit card. The balance and credit limit of a person’s credit card and their overall credit score map well to the three risk management components we needed for our framework.
Card balance
The risk that a team currently holds can be thought of as the balance carried on a credit card. How much risk (debt) has the team taken on? The higher the risk, the higher the balance.
Credit limit
Risk tolerance is like a card’s credit limit. It sets how much total risk the organization’s upper management is willing to permit a team to have, like the total amount of money a bank is willing to lend the card holder.
Like that bank, the organization’s upper management is less concerned about what specific risks a team “buys’’ with their credit. The team decides how it “spends” its credit on the individual risks needed by its project. Comparing the two — understanding how much risk “debt” a team has and how much more risk “credit” is available — lets engineers determine for themselves how much flexibility they have in taking on some particular risks.
Credit score
The need for specific security measures is like a credit score. Changes to a team’s credit score show how well they are handling their risk over time and help them adjust their work as required.
Designing the pilot
To populate our initial framework, the security team selected 25 risks drawn from past events, older risk frameworks, and our knowledge of the organization. We placed each risk into one of three categories:
- Platform risk: a risk that is owned by the platform team or organization but applies to all or most teams.
- Platform risk opt-out: a platform risk that teams can “opt out” of by not using a service or component.
- Team risk: a risk that the team owns and must manage remediation themselves.
For the pilot, we ignored setting a “credit limit” so we could concentrate on building an accurate “card balance” to reflect each team’s debt. We easily quantified the risks using Netflix’s riskquant Python application. Its magnitude model (called SimpleModel) allowed us to give each item (or event) a dollar value based on upper and lower bounds of likelihood of occurrence paired with upper and lower bounds of cost to the organization.
Rather than using dollars to measure magnitude, we simply used a point scale, so that an $800,000 annual dollar loss from the quantification exercise became a more digestible 800 points. Teams needed to classify each of their debts with Yes/No/Not Applicable/Don’t Know, where “Yes” meant that they had no “debt” from that risk.
Working with the teams
After crunching the numbers, we generated an initial report for each team showing their “debt,” with a breakdown of points allocated to each risk and a recommended fix. These fixes could be adding a feature, implementing a policy or tool already provided by the security team, or improving employee administration methods. We also provided a point of contact for each item — either someone on the security team or another engineering team with whom they could get started on mitigating the risk.
Teams reacted very positively to their reports, and we adopted several improvements suggested by them, including more detailed information about risk and mitigation strategies and giving a value for each risk’s return on investment (calculated by combining person-time and budget and then comparing it to the point “debt”). The updated report enables teams to better identify and prioritize their big risks and quick wins and helps maximize impact across the organization.
Next steps
We’re now working on expanding our risk catalog and updating the “card balances” held by each team. After that, we will establish their “credit limits,” likely by adding 10% to everyone’s current “debt” and then adjusting as needed. We are also designing historical reports to show the changes to risk balances, and using that to help generate and re-evaluate each team’s “credit score.”
We will never be able to eliminate all risk, but applying this methodology has been a significant step in helping the organization understand risk and making everyone more comfortable with the risk they decide to take on.
About Carta’s security team
We support the entire organization. We seek to create more security owners and don’t capriciously block our people from shipping to customers. We are advisors, tool creators, and policy makers, giving teams the information they need to make informed decisions and quantify risk so that it can be understood at all levels of the organization.
We want our engineers to have the freedom to own and manage their risk. We want to give them objective facts about the risks they consider implementing, and have the resources to properly support them. At Carta, we think unconventionally about problems, and security is no different. Sound like something you’re interested in being a part of? We’re hiring!
