Tag: Security Debt

  • DevOps and the Dark Pools of Security Technical Debt

    DevOps and the Dark Pools of Security Technical Debt

    We live in a world of digital transformation where organizations across industries are embracing initiatives around automation, cloud deployments and containerization of applications—and for good reason. Enabling transformative technologies such as DevOps, for example, can deliver superior product differentiation, faster time to market for new applications and services and an improved overall customer experience. A win-win, right?

    Not so fast. Amidst the explosion of new technologies, tools and practices, many business leaders are jumping in head first without testing the security waters, so to speak.

    In their race to move fast, it’s all too common for organizations to quickly realize that they’ve landed in a deepening pool of security debt that hackers are eager to exploit. As evidenced by recent breaches resulting from misconfigured AWS security settings, leaked S3 buckets full of secrets, database security misconfigurations, ransomware and the growing interest in exploiting CI/CD tools for hijacking IT assets to mine cryptocurrency, attackers are increasingly targeting DevOps environments.

    Security and DevOps Teams Swimming in Different Pools

    When it comes to prioritizing efforts, devoting attention to the non-functional requirements of DevOps infrastructure security often takes a back seat to the more observable value that the output of these systems provide. This is where security technical debt is created.

    Often times it’s a shortcut in establishing a process around managing security configurations, which is the first step on the path to an “event.” Other times it’s aligning personal development processes to corporate IT security standards.

    No matter what the first step in the chain is, the accumulation of unaddressed issues, incomplete process and failure to attend and improve security posture is how companies and groups find themselves in security quicksand.

    How deep and how wide is the security debt pool for DevOps and digital transformation initiatives?  Numerous studies show that most organizations simply don’t know what their level of exposure is, but there is concern about the unmet need of consistent security posture. We know this because security and compliance consistently rank among the top three barriers for DevOps and cloud initiatives year over year as evidenced in Puppet’s “State of DevOps Report” and RightScale’s “State of Cloud Report.”

    According to the “CyberArk Global Advanced Threat Landscape Report 2018,” fewer than half of DevOps respondents said DevOps and security teams are well-integrated, and 41 percent said security teams are only brought in at the end of the development cycle. These two departments are clearly working in different silos.

    IT security professionals and developers often have different areas of responsibility and focus on the DevOps adoption path. Owing to variable technical capabilities and operational silos, roles and responsibilities can get confusing, and the resulting work may or may not get done—leaving technical debt.

    While DevOps teams typically take ownership over application testing, QA and remediation for security flaws in software, there remains a significant “gray area” that isn’t wholly within the DevOps pipeline flow. For example, managing the security “of the pipeline” and adherence to the corporate standards for login ins/2FA and privileged account management, management of access control to secrets and rotation for shared sensitive corporate assets such as databases can impact other teams. Who builds and maintains these core controls for which the business needs to attest regarding the security of these systems when service level responsibility or operational controls are outside the DevOps team’s controls?

    It’s around these gaps that security responsibilities and operational roles get murky, and the debt pools deepen while issues remain unaddressed. The security maturity of various DevOps tools and open source projects vary widely. Missing security features as well as misconfigurations are to blame for numerous security events at many organizations with new stack components at work.

    As Cyberark Labs research has shown, DevOps pipelines can be starting points for lateral movement to other IT systems, so designs of isolation and containment are often aspirational rather than the actual achieved outcome. And for DevOps teams under tight deadlines, there are only so many hours in the day, and only so many additional items that can be added to the burndown list before something has to push and isn’t addressed in any given release.

    Breaking Down the Silos to Stay Afloat

    When these issues hit a breaking point, we see one of two outcomes: security gets involved too late and “puts the brakes on,” or the team makes a premature push to production of a transformative initiative resulting in a security event when the security process simply isn’t ready.

    When integrated and working toward common KPIs and goals, security can provide the extra bandwidth, focus and expertise to avert issues when they are brought into the process in a consultative role early, so called “shifting left.” Security needs to be built into development pipeline processes, and as we’ve seen with breaches of late, security needs to be a “feature” of the pipeline itself, which is the new attack surface cited above.

    Likewise, security teams must embrace new ways of working in the “fast-flow” of modern software engineering. They need to leave behind alarmism and “all or nothing” mental models, which were the security modi operandi of prior eras.

    Business level visibility to KPIs of success in integrating DevSecOps across the organization is often the missing link.  Whether it is red teaming the DevOps pipeline to raise awareness of the latent issues, or measuring security feature delivery success, measurement creates shared values of burning down security tech debt. Whether it is the most common security events by incident (eg. github hardcoded passwords) or the lead time to security feature delivery by the team, accountability insure attention to security success.

    In the end, it’s critical that DevOps teams work with security to ensure that speed, velocity and resiliency aren’t sacrificed for security. Every company’s fortune rises with the new value being created by digital transformation, but it can also fall with the reputational damage of a breach. Organizations need consistently aligned security and risk postures across all these new tools and technologies to reduce the pernicious pools of technical security debt.

    — Elizabeth Lawler

  • The Cost to DevOps: 27 Mufflers

    The Cost to DevOps: 27 Mufflers

    Imagine

    Imagine that you are designing the 2016 Range Rover line of sport utility vehicles.  Like all gas powered vehicles, each one needs an exhaust muffler.  Range Rover likely has narrowed in on a preferred provider of mufflers. But imagine what would happen if the designers and factory line workers could pick from any one of 27 past versions of that muffler from their preferred provider for the new model year.  Yup, choose any one — even if it is outdated, lower performance, does not meet current emission standards, or  has a known defect.  Order it, place it on the vehicle, then ship it.

    We all realize this scenario would never happen.  No one would select a known defective part for the product they are manufacturing.  And who would knowingly choose the 10 year old version of a muffler without the latest advancements to support air quality? No organization would give a each of their designers and line workers free reign on procuring any one of 27 different mufflers for a single model year.  Imagine the operational cost of testing the different mufflers.  Imagine the maintenance cost of having different versions of the same part shipping.  Worse yet, imagine the liability of shipping parts with known defects.

    Land Rover is not taking this approach, but software development teams are.

    27 Versions

    My latest research report, the 2015 State of the Software Supply Chain, reveals that large software development organizations sourced an average of 27 different versions of open source components that they used in development last year.  To be more specific, out of the top 100 open source components these companies downloaded from the internet in 2014, they averaged 27 versions of each component.

     

    While auto manufacturers like Land Rover have preferred suppliers of vetted parts, the procurement of open source components is often more of a free-for-all.  If an organization has 300 developers, they effectively have a procurement department of 300 for sourcing externally developed software components. If you have 4,000 developers, you have 4,000 performing procurement.  Even as we all know only the latest version of a components is the most feature rich and of the highest quality and integrity.

    Not all organizations allow free-for-all sourcing practices for components.  Fifty-seven percent (57%) have open source policies in place as a method to guide developers toward higher quality parts with the fewest known defects or security vulnerabilities.  Organizations like Google mandate the use of no more than two versions of a given open source component across their development teams.

    Good Cost, Bad Cost

    What does this mean for a software development organization — especially one focused on improving it’s DevOps practices?  First the good news: developers are using open source components to speed time to release and improve innovation.  Both good things.

    The bad news: Organizations are building mountains of technical debt through poor software supply chain practices by sourcing an average of 27 versions of the same component, impacting quality, complexity, maintainability, supportability, etc.  They are doing this across the top 100 components being downloaded in a single year which equates to managing over 2700 different versions (when an optimized practice would only require the 100 best).

    Organizations are sourcing component “parts” for use in their applications that have up to 26 known better versions available (more features, fewer bugs, improved performance, etc.).

    Organizations are downloading and using parts that are sometimes 9 years old, or even older (simple math: open source projects release 3 – 4 new versions of their components each year).  They are electively using outdated parts.

    Organizations are also downloading some versions with known, documented security vulnerabilities.  They are electively using known vulnerable parts.

    Net Innovation Through Improved Sourcing

    While we often hear people tout a DevOps mantra of “even faster”, there is a consequence to pursuing speed at any cost: technical and security debt.

     

    Open source components are enablers of speed.  But free-for-all sourcing and use practices, add to technical and security debt that reduces “net innovation” and adds to the cost of operations.    As technical debt grows, net innovation and business value drops.

     

    Image source: http://joapen.com/blog/2014/06/17/how-to-monetize-application-technical-debt/

     

    If reducing the use 2,700 versions of 100 components was not motivating enough, consider this: the research also revealed that large development teams were consuming software components from over 7,600 external open source projects (suppliers).  Including all versions of those components, they average organization consumed nearly 19,000 unique components in 2014.

    Improved sourcing practices are just part of the overall story for improving net innovation and increasing business value.  Improved sourcing practices can also enable more efficient operations, reduce mean times to remediation, and eliminate unplanned work for many DevOps practices.  Improved sourcing practices have been employed across many industries resulting in sustained competitive advantages.  Improved sourcing practices are part of a broader software supply chain management strategy.

    Continuous Learning

    There are so many lessons we can learn from other industries who have automated and optimized their supply chains — like Land Rover and other auto manufacturers.   I’ll be sharing more of those lessons and perspectives from the 2015 State of the Software Supply Chain here this summer as well as expanding the discussion around “net innovation”.  Stay tuned.