avatarDavid Matousek

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

2935

Abstract

se are the teams that support developers deploying code through your organization. They are the heart of your application development practice, pumping code through the organization to the customer. As a core cybersecurity team, we need to empower application teams to support security implementations throughout the enterprise. This means that enterprises are decentralizing application development. The general idea is to push out information and receive telemetry. Give your teams coaching through open communication dialogues. Then incorporate their learnings and examples back into the community of knowledge.</p><figure id="9fc8"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*vyidHL5rW9uCiWfX0o6Dlw.png"><figcaption></figcaption></figure><p id="372c">It is this cycle that keeps everything tied together. It is the soft skills that build a community. Listening and comprehending the issues of the developers writing application code is the most crucial feedback a security team needs to be able to provide processes and tools to developers. By building a community, you are laying the communication pathways to centralize security intelligence gathering and posture management.</p><h2 id="8421">“Shift Everywhere” in the application process</h2><p id="4097">Almost every CISO security forecast, it identifies that enterprises need to “shift left.” This is often misunderstood. Do not “just” shift security left. Instead, start security earlier, but “Shift Everywhere.” Ideally, the cost of finding a security vulnerability, misconfiguration, or issue earlier in the process lowers the mean time to remediation and overall exposure. However, issues can be uncovered anywhere and at any time with the changing threat landscape. It’s essential to understand the risk of an entire value stream, from code to runtime and everywhere in between. <b>“Shifting Everywhere” requires us to automate vulnerability detection and inject remediations into the continuous delivery process. </b>Thus closing the loop on each and every vulnerability.</p><figure id="8210"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*9L8aHwhNKv2vBNsprHncDg.png"><figcaption></figcaption></figure><p id="e64d">The security community must have a servant-leader mentality and recognize that we must give developers tools that don’t impede their development process. Security issues should provide off-ramps, not gates. Gates stops a process dead and sends the developer back to the start of the next sprint or, worse, to the backlog. Off-ramps redirect the issue and provide a way to get back on the highway, encouraging development to continue by providing information, examples, and suggestions as part of the feedback loop.</p><p id="3c16">Now, why am I advocating for “Shifting Everywhere.” Because the process is automated, it is now possible to create the appropriate events to report open vulnerabilities and calculate

Options

potential risks to the application. “Shifting Everywhere” gives security the telemetry it needs to calculate your application security posture.</p><h2 id="8c93">Aggregate Security Results into Key Risk Indicators</h2><p id="8d5b">We now have application teams consuming processes that produce security events. With this new data, we can do all sorts of things. But, before we go too deep down that path, for Level 2 maturity, I want to focus on key risk indicators(KRIs). <b>I define a KRI as a measurement tracked over time that tracks the probability of an exposure to a threat.</b> With the information collected in the deployment process, we can now identify the highest risk steps along the deployment journey and create a metric to measure risk over time.</p><blockquote id="3002"><p>“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.“ — “<a href="https://readmedium.com/6-key-risk-indicators-that-i-use-to-drive-healthy-behaviors-in-developers-to-secure-applications-14eff357dd0?sk=cbf04ecd43772bef66833dd641d59e20">6 Key Risk Indicators that I use to Drive Healthy Behaviors in Developers</a>.”</p></blockquote><p id="1273">And these KRIs give us the first glimpse into our Application Security Posture.</p><h1 id="d79d">Final notes on your Application Security Posture Foundation, Level 2</h1><p id="2e44">In Level 2, we have built upon the foundation set in <a href="https://readmedium.com/enterprise-application-security-posture-level-1-foundation-8aea9da85153?sk=35ee3d581890adac99ecf2bddbbcf383">Level 1</a>. First, we reinforced internal networking by building a community. Second, we utilized the development processes to “Shift Everywhere,” allowing security to get the telemetry it needs to calculate an application security posture. Finally, we started to organize the data collected into easily understandable key risk indicators. At this stage, we’re actually starting to monitor risk across the enterprise. But we are not done yet….</p><p id="a731"><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><p id="e065"><a href="https://readmedium.com/enterprise-application-security-posture-level-3-f33c87304155?sk=c2a959bdeaecf877222d4d1966503030"><i>Part 4</i></a><i> of the series <b>Application Security Posture as a Product Manager in Cybersecurity</b></i></p></article></body>

Enterprise Application Security Posture, Level 2

Three More Actionable Initiatives to Elevate Your Application Security Posture.

Image by Ryan McGuire from Pixabay

Part 3 of the series Application Security Posture as a Product Manager in Cybersecurity. Links to Part 1 & Part 2. Please support me by following me on Medium.

Building an Enterprise Application Security Posture does not work by mandating application development teams to use centralized processes and technologies. To measure your enterprise application security posture, you need to build partners, not minions. Application development teams are electric; they naturally look for the path of least resistance between code and operational environments. Security teams need to be grounding rods for developers and make the secure path the easiest path to take. It is imperative to support developers, not block paths. By impeding paths, security teams break the partner bond with development teams. Security processes and tools need to fit frictionlessly in where developers are: in the developer environments, in the source code repositories, in the build process, in the artifact repositories, in the deployment process, and in the operational environments. “Shift Left” means that you’re securing the pipeline further left. I think a better phrase is “Shift Everywhere!”

Three More Actionable Initiatives to Elevate Your Application Security Posture

  1. Elevate your Community
  2. “Shift Everywhere” in the application process
  3. Aggregate Security Results into Key Risk Indicators

Elevate your Community

Building on our foundation of an internal network from Level 1, we continue to use soft skills. Identifying the DevSecOps teams in different business units is the key. These are the teams that support developers deploying code through your organization. They are the heart of your application development practice, pumping code through the organization to the customer. As a core cybersecurity team, we need to empower application teams to support security implementations throughout the enterprise. This means that enterprises are decentralizing application development. The general idea is to push out information and receive telemetry. Give your teams coaching through open communication dialogues. Then incorporate their learnings and examples back into the community of knowledge.

It is this cycle that keeps everything tied together. It is the soft skills that build a community. Listening and comprehending the issues of the developers writing application code is the most crucial feedback a security team needs to be able to provide processes and tools to developers. By building a community, you are laying the communication pathways to centralize security intelligence gathering and posture management.

“Shift Everywhere” in the application process

Almost every CISO security forecast, it identifies that enterprises need to “shift left.” This is often misunderstood. Do not “just” shift security left. Instead, start security earlier, but “Shift Everywhere.” Ideally, the cost of finding a security vulnerability, misconfiguration, or issue earlier in the process lowers the mean time to remediation and overall exposure. However, issues can be uncovered anywhere and at any time with the changing threat landscape. It’s essential to understand the risk of an entire value stream, from code to runtime and everywhere in between. “Shifting Everywhere” requires us to automate vulnerability detection and inject remediations into the continuous delivery process. Thus closing the loop on each and every vulnerability.

The security community must have a servant-leader mentality and recognize that we must give developers tools that don’t impede their development process. Security issues should provide off-ramps, not gates. Gates stops a process dead and sends the developer back to the start of the next sprint or, worse, to the backlog. Off-ramps redirect the issue and provide a way to get back on the highway, encouraging development to continue by providing information, examples, and suggestions as part of the feedback loop.

Now, why am I advocating for “Shifting Everywhere.” Because the process is automated, it is now possible to create the appropriate events to report open vulnerabilities and calculate potential risks to the application. “Shifting Everywhere” gives security the telemetry it needs to calculate your application security posture.

Aggregate Security Results into Key Risk Indicators

We now have application teams consuming processes that produce security events. With this new data, we can do all sorts of things. But, before we go too deep down that path, for Level 2 maturity, I want to focus on key risk indicators(KRIs). I define a KRI as a measurement tracked over time that tracks the probability of an exposure to a threat. With the information collected in the deployment process, we can now identify the highest risk steps along the deployment journey and create a metric to measure risk over time.

“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.“ — “6 Key Risk Indicators that I use to Drive Healthy Behaviors in Developers.”

And these KRIs give us the first glimpse into our Application Security Posture.

Final notes on your Application Security Posture Foundation, Level 2

In Level 2, we have built upon the foundation set in Level 1. First, we reinforced internal networking by building a community. Second, we utilized the development processes to “Shift Everywhere,” allowing security to get the telemetry it needs to calculate an application security posture. Finally, we started to organize the data collected into easily understandable key risk indicators. At this stage, we’re actually starting to monitor risk across the enterprise. But we are not done yet….

As my daughter says, if you are interested in “what-ever-this-is,” then please consider following me on Medium.

Part 4 of the series Application Security Posture as a Product Manager in Cybersecurity

Cybersecurity
Product Security
Application Security
Security
Cloud Security
Recommended from ReadMedium