6 Key Risk Indicators that I use to Drive Healthy Behaviors in Developers

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

2680

Abstract

tant risks along the application development journey from when code is typed in the IDE through when the code is running in a container in an operations environment. KRI’s are best when formulated as a ratio of 2 variables to show trends over time. Typically, the numerator reflects a measurement of the actual state and the denominator is the total number of items being measured. We use a ratio, often in the form of percent, to provide directionality of risk over time. From this knowledge we can create boundaries that we know we can tolerate risk at. When the measurement goes past these boundaries, we have an indicator that there ‘might’ be a problem. KRI’s don’t guarantee safety, however they are eerily prescient.</p><h1 id="ead3">Enterprise KRI’s, from the bottom to the top</h1><p id="6df9">In the modern digital enterprise, most organizations are dependent on developers. Developers build applications for the customer, enterprise partners, and internal services. Not all applications are treated equally inside organizations. Fancy customer facing applications have squads of developers continuously scanning and deploying code to production. As we progress inward in an organization, the software development practices often become somewhat more overlooked. Internal services and API’s for third party partners are built….and then forgotten. I can’t even tell you how many times a zero day vulnerability has been detected and the application owner tells me that the team has been disbanded or moved on. What happens to the poor little chargeback applications, an application that doesn’t have a scrum team maintaining it anymore, or even a JIRA backlog. These little applications that we’ve left behind are sitting time bombs. Business units are not able to show how maintaining currency of non customer facing application provides value. Adding a security story to clean up a vulnerability often has the lowest priority and falls to the backlog in order for a customer facing release to go forward. And when the code is scanned, if a vulnerability is detected, it’s deemed too late to stop the release. We tell ourselves, “Just add a tech debt story”.</p><h1 id="7443">Some common problems developers face in using security tools in their daily lives:</h1><ul><li>Developers aren’t always told about the security requirements. Believe it or not, when we onboard new developers into a squad to begin committing code, we ‘forget’ to educate them in the standards provided from security. Often the focus is to get new employees to contribute code, we forget that we need them to contribute secure code.</li><li>Developers don’t know to fix the vulnerability. Not all

Options

vulnerabilities are fixed by upgrading to the latest dependancies. Sometimes the there are changes in the dependancies that require rework and in extreme cases a different dependency or approach is needed.</li><li>Developers want to release on time. The pressure of releasing new feature functionality can be real. In some cases it’s a mad dash to the finish line, and just before crossing, teams run a scan…Should the issue have been found earlier, yes, but here we are now with the business asking when the new release is live. So to facilitate thew business, we get an exception to deploy from our risk manager, create a tech debt item for the ‘next sprint’, and push a vulnerability we hope isn’t exploited until we fix it sometime in the future.</li><li>Developers might have to break working code. The last thing a developer wants to do is rewrite their own code while it works just fine. Why introduce an issue when it already works, so what if you’re accessing that graphQL API in plain text.</li></ul><h1 id="bbd9">Making KRI’s Transparent helps developers, application owners, and organizational executives</h1><p id="66a4">Specifically in application security, making risks transparent to the enterprise accomplishes many things:</p><ul><li>It brings attention to executives to the true security posture, not just their perception that everything is OK because there has not been an issue.</li><li>It brings attention to product managers who are responsible to provide value to their customers by protecting their identity and assets.</li><li>It brings attention to the engineering managers that need to ensure their development teams are following best practices and meeting security requirements and standards</li><li>It brings attention to risk, compliance, and security teams so that they can allocate advice, education, and resources to the teams that need it most.</li><li>It brings attention to the architects so that they can ensure the patterns they built are implemented securely, and when they are out of alignment with reality, make appropriate changes.</li></ul><h1 id="1c25">Six Application Security KRI’s to make Transparent today</h1><p id="032e">Six KRI’s that I make transparent across the organization to drive healthy behaviors in developers and secure our enterprise application assets are:</p><figure id="2902"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*2ZTy7roYhflQbHXwB2IKWQ.png"><figcaption></figcaption></figure><p id="591d"><i>As my daughter says, if you are interested in “what-ever-this-is,” then please consider <a href="https://davidmatousek.medium.com/subscribe">following me on Medium</a>.</i></p></article></body>

6 Key Risk Indicators that I use to Drive Healthy Behaviors in Developers

According to the “2021 Cost of a Data Breach Report” by IBM Security, the average data breach cost enterprises an average of 4.24 million dollars per incident. Executives in large enterprises are responsible to protect their customers, shareholder’s, and employees from risks on the behalf of the organization. Each of these three groups are potentially exposed financially to security risks that your company is responsible to protect them from. How is it possible that an executive can have visibility into all of the various risks throughout their organization? Even if they did have this information, what can they do with it? In this article, I will walk through

How enterprises use KRI’s (Key Risk Indicator’s) to measure potential risk to their application assets from the bottom of their organization to the top

How transparent KRI’s drive healthy application security behaviors.

Six concrete examples of KRI’s used to protect your application assets and how each of them can be used to drive healthy development patterns in your organization.

Cybersecurity professionals are losing sleep with all of the vulnerabilities being discovered in their application estates. In order to get some of that rest we have heard so much about, we need to drive healthy behaviors in developers to secure our application estate. Application risk is NOT a measure of what happen, but how likely and how severe a security event is in the future. Information bias makes us assume that because we’ve been able to be secure in the past, we can use that historical information only to predict the future.

What is an Application Security KRI

Application security key risk indicator’s are measurements of the most important risks along the application development journey from when code is typed in the IDE through when the code is running in a container in an operations environment. KRI’s are best when formulated as a ratio of 2 variables to show trends over time. Typically, the numerator reflects a measurement of the actual state and the denominator is the total number of items being measured. We use a ratio, often in the form of percent, to provide directionality of risk over time. From this knowledge we can create boundaries that we know we can tolerate risk at. When the measurement goes past these boundaries, we have an indicator that there ‘might’ be a problem. KRI’s don’t guarantee safety, however they are eerily prescient.

Enterprise KRI’s, from the bottom to the top

In the modern digital enterprise, most organizations are dependent on developers. Developers build applications for the customer, enterprise partners, and internal services. Not all applications are treated equally inside organizations. Fancy customer facing applications have squads of developers continuously scanning and deploying code to production. As we progress inward in an organization, the software development practices often become somewhat more overlooked. Internal services and API’s for third party partners are built….and then forgotten. I can’t even tell you how many times a zero day vulnerability has been detected and the application owner tells me that the team has been disbanded or moved on. What happens to the poor little chargeback applications, an application that doesn’t have a scrum team maintaining it anymore, or even a JIRA backlog. These little applications that we’ve left behind are sitting time bombs. Business units are not able to show how maintaining currency of non customer facing application provides value. Adding a security story to clean up a vulnerability often has the lowest priority and falls to the backlog in order for a customer facing release to go forward. And when the code is scanned, if a vulnerability is detected, it’s deemed too late to stop the release. We tell ourselves, “Just add a tech debt story”.

Some common problems developers face in using security tools in their daily lives:

Developers aren’t always told about the security requirements. Believe it or not, when we onboard new developers into a squad to begin committing code, we ‘forget’ to educate them in the standards provided from security. Often the focus is to get new employees to contribute code, we forget that we need them to contribute secure code.

Developers don’t know to fix the vulnerability. Not all vulnerabilities are fixed by upgrading to the latest dependancies. Sometimes the there are changes in the dependancies that require rework and in extreme cases a different dependency or approach is needed.

Developers want to release on time. The pressure of releasing new feature functionality can be real. In some cases it’s a mad dash to the finish line, and just before crossing, teams run a scan…Should the issue have been found earlier, yes, but here we are now with the business asking when the new release is live. So to facilitate thew business, we get an exception to deploy from our risk manager, create a tech debt item for the ‘next sprint’, and push a vulnerability we hope isn’t exploited until we fix it sometime in the future.

Developers might have to break working code. The last thing a developer wants to do is rewrite their own code while it works just fine. Why introduce an issue when it already works, so what if you’re accessing that graphQL API in plain text.

Making KRI’s Transparent helps developers, application owners, and organizational executives

Specifically in application security, making risks transparent to the enterprise accomplishes many things:

It brings attention to executives to the true security posture, not just their perception that everything is OK because there has not been an issue.

It brings attention to product managers who are responsible to provide value to their customers by protecting their identity and assets.

It brings attention to the engineering managers that need to ensure their development teams are following best practices and meeting security requirements and standards

It brings attention to risk, compliance, and security teams so that they can allocate advice, education, and resources to the teams that need it most.

It brings attention to the architects so that they can ensure the patterns they built are implemented securely, and when they are out of alignment with reality, make appropriate changes.