avatarDavid Matousek

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

2698

Abstract

urse, we all know that we have to support security, but forcing security upon your partners is like telling your kids to eat their dinner before dessert. Security needs to be an enabler to your partners so that they can integrate frictionlessly, operate faster, and deliver value to your customers.</p><figure id="4139"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*culODyxLxjOTY-MUii4-eA.png"><figcaption></figcaption></figure><h2 id="68a0">Initiative 2: Discovering the Application Lifecycle Journey Map</h2><p id="bf86">Using your new relationships with people in your organization, it’s time to map out the application journey lifecycle. To be clear, this is not your CI/CD pipeline. The application journey lifecycle shows the path an application takes from its birth, its evolution, and eventually ends with its deprecation. Your organization may only have one application, a few, or maybe thousands. Each organization will be different.</p><p id="2847">Along this discovery, it will be essential to identify development cadences, uncover how releases happen and ask how applications get promoted through environments. There should be no shortage of questions to ask. Some additional common questions I ask are: What security processes are happening here? Are they automated or gates? What security control are they covering?</p><p id="945c">When you start to map out all the processes you have been discovering, you will have a starting point for an application deployment threat model. Looking at how an application goes from developer environment -> source code repository -> build process -> artifact repository -> operational environment. This map is a collection of processes used in your organization overlayed with security interactions.</p><figure id="ebe1"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*U7QVG65WozNnvWsyqRgNzg.png"><figcaption></figcaption></figure><p id="6ae0">In addition, this map should give you insight into the engineering journey. Each step is a point where security could be a bottleneck. Most of an application’s lifecycle is progressed by developers making decisions to move the code along the process. It makes sense that, in many cases, it’s the developers doing the actual implementation of a security tool. In the case of monitors, any correction item that comes from them has to be inserted into the product backlog. The development team is again involved with scoping, prioritizing, and scheduling the story to close the security issue.</p><h2 id="045e">Initiative 3: Identifying your Application Asset Library</h2><p id="ada4">Now that you have your partners identified and the application lifecyc

Options

le journey mapped, it’s time to take inventory of the applications your organization protects. Knowing your assets is always foundational in almost every security endeavor you go on. Your application estate also provides the scope of what you need to protect. For each and every one of these applications, the challenge is to know they exist, know when they change, and know when they are removed. Your application asset library will be your best friend.</p><p id="eeb9">But before you think that just knowing you have an application asset library exists is enough to support your application security posture, consider asking some questions. Is the catalog complete? Does it tell me enough information about each application? If I found a security issue in an application, would I be able to find the owner of the application in less than 5 mins? Do I know what other applications depend on this application?</p><p id="a502">Your application asset library is your foundational tool for determining the application assets you will be measuring their risk posture. To be able to know your risks, it’s imperative to really know your applications.</p><h2 id="6d2d">Final notes on your Application Security Posture Foundation</h2><p id="3a26">Application Security posture is about continuously monitoring your application portfolio’s risk so that executives can make data-driven decisions. The foundation of monitoring your application security posture is built on people, processes, and technologies. A product manager of cybersecurity needs to have a working relationship with your application teams, security teams, and value stream owners in order for them to help you deliver customer value securely. In addition, you must know the processes an application has to go through to be created, evolve, and be deprecated. Finally, once you know your people and processes, you must know the applications you protect. In a modern enterprise, most of these tools exist for you to build your foundation, just make sure to discover any cracks in the foundation and fill them in before you attempt to continuously monitor your application security posture. I find it nearly impossible to measure risk if every variable is unknown.</p><p id="fb5f"><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="1aa1"><i>Continue with <a href="https://readmedium.com/enterprise-application-security-posture-level-2-f6119c742f54?sk=d82281aea557998e603ba7724d9b6da8">Part 3</a> of the series <b>Application Security Posture as a Product Manager in Cybersecurity</b></i></p></article></body>

Enterprise Application Security Posture, Level 1

The Foundation — Three Actionable Initiatives to Build an Application Security Posture Foundation.

Part 2 of the series Application Security Posture as a Product Manager in Cybersecurity. Part 1 can be found here. Please support me by following me on Medium.

Photo courtesy of Gratisography

When I first looked at our enterprise through the lens of a cybersecurity product manager, I questioned what I would be able to influence. The situation was grim, with multiple business units doing their own thing, building their own controls, and engineers deploying code across the organization with inconsistent security controls. Most of the teams I interviewed focused on delivering value for their business unit; security was often an afterthought or taken on as tech debt.

Independently, any one team was doing everything in its power to protect its application. But who was protecting the enterprise? How was security information making it to business leaders so that they could make data-driven decisions?

With a large number of people, processes, and technology unknowns, the first step is to investigate the situation.

Initiative 1: Build Your Internal Network

“..forcing security upon your partners is like telling your kids to eat their dinner before dessert.”

The most important resource you have when building an application security posture is the people developing, operating, and paying for the applications you are protecting. These partners that you work with are the first part of the foundation for your application security posture. For a product manager, it’s imperative to learn about their problems, concerns, desires, and experiences. As you grow your application security posture practice, these partners will provide input into your overall vision and strategy. Building an application security posture or buying a tool first acts as a de-motivator to change. Acknowledging concerns, addressing problems, and providing vision to your partners brings kindles communication and builds a relationship between you and your partners. Of course, we all know that we have to support security, but forcing security upon your partners is like telling your kids to eat their dinner before dessert. Security needs to be an enabler to your partners so that they can integrate frictionlessly, operate faster, and deliver value to your customers.

Initiative 2: Discovering the Application Lifecycle Journey Map

Using your new relationships with people in your organization, it’s time to map out the application journey lifecycle. To be clear, this is not your CI/CD pipeline. The application journey lifecycle shows the path an application takes from its birth, its evolution, and eventually ends with its deprecation. Your organization may only have one application, a few, or maybe thousands. Each organization will be different.

Along this discovery, it will be essential to identify development cadences, uncover how releases happen and ask how applications get promoted through environments. There should be no shortage of questions to ask. Some additional common questions I ask are: What security processes are happening here? Are they automated or gates? What security control are they covering?

When you start to map out all the processes you have been discovering, you will have a starting point for an application deployment threat model. Looking at how an application goes from developer environment -> source code repository -> build process -> artifact repository -> operational environment. This map is a collection of processes used in your organization overlayed with security interactions.

In addition, this map should give you insight into the engineering journey. Each step is a point where security could be a bottleneck. Most of an application’s lifecycle is progressed by developers making decisions to move the code along the process. It makes sense that, in many cases, it’s the developers doing the actual implementation of a security tool. In the case of monitors, any correction item that comes from them has to be inserted into the product backlog. The development team is again involved with scoping, prioritizing, and scheduling the story to close the security issue.

Initiative 3: Identifying your Application Asset Library

Now that you have your partners identified and the application lifecycle journey mapped, it’s time to take inventory of the applications your organization protects. Knowing your assets is always foundational in almost every security endeavor you go on. Your application estate also provides the scope of what you need to protect. For each and every one of these applications, the challenge is to know they exist, know when they change, and know when they are removed. Your application asset library will be your best friend.

But before you think that just knowing you have an application asset library exists is enough to support your application security posture, consider asking some questions. Is the catalog complete? Does it tell me enough information about each application? If I found a security issue in an application, would I be able to find the owner of the application in less than 5 mins? Do I know what other applications depend on this application?

Your application asset library is your foundational tool for determining the application assets you will be measuring their risk posture. To be able to know your risks, it’s imperative to really know your applications.

Final notes on your Application Security Posture Foundation

Application Security posture is about continuously monitoring your application portfolio’s risk so that executives can make data-driven decisions. The foundation of monitoring your application security posture is built on people, processes, and technologies. A product manager of cybersecurity needs to have a working relationship with your application teams, security teams, and value stream owners in order for them to help you deliver customer value securely. In addition, you must know the processes an application has to go through to be created, evolve, and be deprecated. Finally, once you know your people and processes, you must know the applications you protect. In a modern enterprise, most of these tools exist for you to build your foundation, just make sure to discover any cracks in the foundation and fill them in before you attempt to continuously monitor your application security posture. I find it nearly impossible to measure risk if every variable is unknown.

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

Continue with Part 3 of the series Application Security Posture as a Product Manager in Cybersecurity

Cybersecurity
Application Security
Devsecops
Product Management
Product Security
Recommended from ReadMedium