Security Budget Management

For the next step of evolution for security budget management in DevOps, the recommendations and overview remain the same as described in Chapter 2, Section 2.6. In particular, this includes those sections that discuss preparing and delivering the budget message and other things to consider when preparing the budget.

In DevOps, security is intertwined with every area of the organization, from basic tasks to driving strategic goals. Security budgeting cannot operate in a vacuum and should be a critical part of the DevOps process. It is imperative that there is agreement between the two sides. Security must be at the table with development and operations teams to ensure that security is built into DevOps initiatives. If security hasn’t been built into DevOps, the budget-allocation process will be problematic. A typical annual budgeting process, predicting and locking in funding and allocating resources 12 months in advance, is an antithesis to the DevOps process. As with everything that is migrating and transforming into the dynamic and responsive DevOps environment, budgeting must evolve and adapt its culture in this change.

Mustafka Kapadia provides three budgeting-process options for DevOps in a 2018 DevOps.com article “Transforming the Annual Budgeting Process for DevOps”':

1. Shorter Cycles and Frequent Reviews

Some organizations are moving to a shorter budgeting and review cycle. The traditional construct of annually funding projects remains, but plans and allocations are revisited quarterly or on a rolling basis. Both business and DevOps are continuously reprioritizing what features to fund and jointly collaborating on making go/no-go decisions. The benefit of such a system is that it allows teams to allocate funds dynamically within the project—it forces teams to think in terms of a minimum viable product, and mistakes in allocations can be quickly corrected. However, there are two major drawbacks. First, funds cannot be reallocated across projects, forcing executives to still wait for the annual cycle. And second, if the quarterly review process is not streamlined, it can create a climate of constant budgeting, where managers end up spending more time jockeying for funds instead of doing real work.

2. Product-Based Funding

In this approach, applications and the associated resources are grouped into product teams and are given a share of the total budget. This budget is primarily managed by the chief product owner, which then further distributes it to the product owners. Just like in the last model, the chief product owner collaborates with the business to decide on go/no-go activities. In addition, it also allows chief product owners to reallocate funds across both products and projects within their portfolio. And the product owners are responsible for executing on the minimum viable feature sets within their allocated funds. The benefit of this model is in its simplicity. Instead of making bets on projects, CFOs just have to decide on how the budgets are spread across various product groups. Chief product owners and product owners have freedom to allocate their share as they see fit. As a result, budget decisions are pushed as close to the front line as possible, allowing for greater flexibility and improved market response times. To get around this, some

Kapadia, M. (2018. June 16). “Transforming the Annual Budgeting Process for DevOps.” Retrieved from https:// devops.com/transforming-the-annual-budgeting-process-for-devops/ organizations force teams to reserve a piece of the budget for maintenance and paying down technical debt.

3. Venture-Based Funding

This is a model that mirrors Silicon Valley-style venture capitalists (VCs) in that an executive board will fund ideas for minimal viable products. Based on the effectiveness of the product, additional funding is granted to the teams. This model is to seed lots of ideas and fund only the ones that work. The benefit is greater transparency and reduced financial risk. The drawback is that most companies are not wired like VC firms.

Security Governance, Risk, and Compliance (GRC) Management

For the next step of evolution for security governance, risk, and compliance (GRC) management, the recommendations and overview remain the same as described in Chapter 2, Section 2.7. In particular, this includes those sections that discuss SDL Coverage of Relevant Regulations, Certifications, and Compliance Frameworks; Third-Party Reviews; Post-Release Certifications; Privacy; Privacy Impact Assessment (PIA) Plan Initiated; Privacy Implementation Assessment; Final Privacy Review; and Post- Release Privacy Response. Some further comments are compiled below from Anders Wailgren’s article “DevSecOps: 9 Ways DevOps and Automation Bolster Security, Compliance”:

You must always fix things quickly as possible, but in an DevOps environment this is more important. DevOps accelerates your lead time, so that you can develop, test, and deploy your patch/update more quickly. This will be particularly important if you have to resolve an issue such as Heartbleed.

The meticulous tracking provided by some DevOps platforms into the state of all your applications, environments, and pipeline stages greatly simplifies and accelerates your response when you need to release your update. When you know exactly which version of the application, and all components in its stack, is deployed on which environment, you can quickly pinpoint the component of the application that requires the update, identify the instances that require attention, and quickly roll out your updates in a faster, more consistent, and repeatable deployment process by triggering the appropriate workflow. Your DevOps tools and automation can be configured to enable developers to be self-sufficient and “'get things done, ” while automatically ensuring access controls and compliance. DevSecOps enables organizations to achieve speed without risking stability and governance. Security and compliance controls should be baked in as an integral part of DevOps processes that manage the code being developed all the way through to production. By implementing DevOps processes that incorporate security practices from the start, you create an effective and viable security layer for your applications and environments that will serve as a solid foundation to ensure security and compliance in the long run, in a more streamlined, efficient, and proactive way.'

In Chapter 3, we discussed A/В testing of updated components. To stay true to the DevOps way of thinking, our SDL accounts for this type of automated updating.

 
Source
< Prev   CONTENTS   Source   Next >