@DanLebrero.

software, simply

Book notes: Investments Unlimited, a novel about devops, security, audit compliance, and thriving in the Digital Age

  • Wed, 31 Aug 2022

Book notes on "Investments Unlimited" by Helen Beal, Bill Bensing, Jason Cox, Michael Edenzon, Dr. Tapabrata "Topo" Pal, Caleb Queern, John Rzeszotarski, Andres Vega, and John Willis

These are my notes on Investments Unlimited by Helen Beal, Bill Bensing, Jason Cox, Michael Edenzon, Dr. Tapabrata “Topo” Pal, Caleb Queern, John Rzeszotarski, Andres Vega, and John Willis.

I thought that it was impossible for any book, but Investments Unlimited is as enjoyable and insightful as The Unicorn Project.

You can consider this book a sequel of what happens after adopting DevOps (and forgetting about Security/Audit/Compliance).

WARN: some dialogues will make you angry.

Key Insights

  • Governance is the process of identifying and making promises, and then checking that you keep those promises.
  • Promises:
    • Good way to market any change management.
    • Controls are very sterile but nobody wants to break a promise.
  • Normalization of deviance: exceptions to process becoming the norm.
  • Risk is increased by someone not familiar with the change putting the change in production:
    • Better is to enforce a peer review process.

  • One could look at compliance and security features as non-functional requirements: Product Manager responsibility.

    Software is not eating the world, it is infecting it Josh Corman, Continuous Acceleration
  • Their processes reflect how you incentive them.
  • DearAuditor.org
  • Devops Automated Governance Reference Architecture.
  • The change process rigor was based on what happened historically, not the system needs.
  • Subjectivity encourages lack of transparency and opinion-driven measures.
  • Three Lines Model.
  • Policy as code!
  • Diffusion of responsibility: as the number of bystanders increases, the personal responsibility that an individual bystander feels decreases.
    • Open Source: Everybody assumes that someone else has checked the source.
  • Change Advisor Board (CAB) as consulting partners, not approval authority.
  • Where does it say the word “automated”?
  • More important to have the evidence of what the team decided, than to be 100% compliant all the time.

TOC

Chapter 0 - Preface

  • Governance, either:
  • Anxiety, frustration, fear, anger.
  • Control, peace, order, safety.
  • Governance aims to safeguard what a company holds of value.

Chapter 1 - Tuesday March 29th

  • Chief Audit Executive and Chief Risk Officer role are highly interrelated and interdependent, so much that some orgs have merged into a single CRCO (Chief Risk and Compliance Officer).
  • Product release deadlines always a higher priority: (╯°□°）╯︵ ┻━┻
    • VP of Product: “We had no choice.”
  • She wasn’t pleased by the blame that was being tossed around the room.
  • VP Product: It takes forever to get features out. I don’t know what our dev teams do all day.
    • VP Eng: Tech debt + urgent new features.
    • Hire more engineers!
  • CEO: what I need are solutions.

Chapter 2 - Thursday, March 29th

  • It always falls to Engineering to fix everything. (ノಠ益ಠ)ノ彡┻━┻
  • Auditor role: compare what org says it should do to manage risk with what is actually done.
  • Inconsistent process, ineffective in ensuring security and compliance, resulting in unauthorized and vulnerable SW with significant number of defects in production. (╯’□’)╯︵ ┻━┻
  • Just mentioning the Governance, Risk and Compliance (GRC) system caused an audible groan in the room.
  • Our best security advice mostly comes from internet searches. (ノ-_-)ノ ミ ┴┴
  • Bits and pieces may work in silos, but it doesn’t work as a full system.
  • Backlogs were so back up that each backlog had a backlog item to review the backlog.
  • Promises:
    • Good way to market any change management.
    • Promises we are making to regulators and customers and to each other.
    • Controls are very sterile but nobody wants to break a promise.
  • People love to talk about themselves, especially when someone is listening to them moan about a problem:
    • Lead the conversation with empathy.
    • Elicit fact from the complaining.
  • Copious notes.

Chapter 3 - Tuesday, April 5th

  • It is amazing what happens when you can focus and finish a task.
  • Subjective nature of how we create evidence. (ノ ゜Д゜)ノ ︵ ┻━┻
  • Normalization of deviance: exceptions to process becoming the norm.
  • We have clear and published guidelines:
    • But people just ignore them.
  • We need segregation of duties: developers vs operations.
    • But in “DevOps-fied” teams everybody is a dev.
    • Does not work: as risk is increased by someone not familiar with the change putting the change in production.
    • Better is to enforce a peer review process.
  • One could look at compliance and security features as non-functional requirements:
    • Product Manager responsibility.
  • Build Trap:
    • Only focus on features and neglect experimentation and learning (including learning how to work better).
  • Change not only engineering but also business.

Chapter 4 - Wednesday, April 6th

  • Product Manager needs to manage upwards, sideways and downward.

  • The Three Economies.

    Software is not eating the world, it is infecting it Josh Corman, Continuous Acceleration

  • Chronic conflicts between dev, ops and sec.

  • Their processes reflect how you incentive them.
  • Shift left: smart people defining and codifying the security and compliance policies, instead of manually checking screenshots.
  • Compliance/Security as a product: how would you bring a product to market when you have no objective evidence the markets wants it but some qualitative evidence that it is desired?
    • Small, quick experiments, minimally viable products, to learn what and what doesn’t work.

Chapter 5 - Tuesday, April 19th

  • DearAuditor.org
  • Was never going to drag itself out of this mess without seeing Audit in a new light.
  • Devops Automated Governance Reference Architecture.
  • First design the business process of automated governance, then do a tool and tech selection.
  • Production Access Debt:
    • Every time a persistent production account is accessed, you add ten points. Each breakglass read account is one, each write account is five.
    • Reduce points by:
      1. Everything must be code:
        • Including infra and build/deploy pipelines.
      2. All logs must be streamed out.
      3. No system in production unless it has observability built in.
  • Governance in a DevOps environment.

Chapter 6 - Tuesday, April 28th

  • Subjective change approval policies and processes. (┛ಸ_ಸ)┛彡┻━┻
  • The change process rigor was based on what happened historically, not the system needs.
  • No standardization because engineering inability to agree on a converted set of operation approaches.
  • The Devops Automated Governance takes subjectivity and makes it objective.
  • Subjectivity encourages lack of transparency and opinion-driven measures.

Chapter 7 - Wednesday, May 18th

  • Shift left on security: let risk management being in the developer’s mind:
    • Seeking advice and input from Audit early in the process.

Chapter 8 - Monday, June 6th

  • Didn’t care about how it was done; they only cared about the number of applications that were migrated onto the cloud. ( °□°) ︵ ┻━┻
  • Governance is the process of identifying and making promises, and then checking that you keep those promises.
  • Three Lines Model:
    Three lines model
    1. First line (bank tellers, engineers):
      • Own and manage the risk associated with their responsibilities.
      • Provide input into designing controls, as they execute them in a daily basis and knows what works.
    2. Second line (Risk management and compliance, Security):
      • Structure risk management framework.
      • Decide on policies and controls.
      • Monitors first line for following the policies and controls.
    3. Third line (assurance mechanism, Audit):
      • Asses if risk management approach is effective.
  • Policy as code!

Chapter 9 - Thursday 1st

  • Diffusion of responsibility: as the number of bystanders increases, the personal responsibility that an individual bystander feels decreases.
    • Open Source:
      • Everybody assumes that someone else has checked the source.
      • Hence, OS is not more secure than closed source.

Chapter 10 - Wednesday, September 21st

  • Software bill of materials: all the components you use to build your software:

Chapter 11 - Thursday, October 1st

  • Publish non-compliant artefacts and break at deploy time:
    • This allows for break-glass scenarios where someone has to accept the risk of deploying a non-compliant deploy.
  • If a change is 100% compliant, lets eliminated CAB (change advisor board):
    • CAB as consulting partners, not approval authority.

Chapter 12 - December 13th

  • Where does it say the word “automated”?

Chapter 13 - February 7th

  • Guiding policies:
    1. If the rest of the policies are abided by, then you can bypass manual change approval process and go straight to production.
    2. Complete automation for capturing evidence of quality, risk mitigation, and compliance. Only manual process is peer-review.
    3. Security and compliance are as important as functional requirements. Security, Risk, Compliance and Audit must identify requires from day one.
    4. Software budget: to track deficit in quality, risk, compliance and audit. When budget is depleted, no more feature work is allowed.
  • Bring authority to information, not the other way around.
  • Security is responsibility of those building the SW.
  • More important to have the evidence of what the team decided, than to be 100% compliant all the time.

Epilogue

  • When done well, tech and security cannot be seen from the outside.
  • Every business was truly a technology business and every business leader was a technology leader.
  • DevSecOps.org
Did you enjoy it? or share!

Tagged in : book notes