Tag: rugged devops

  • Security at the Speed of Innovation

    Security at the Speed of Innovation

    With the advent of the cloud and platform as a service (PaaS) offerings, developers are innovating faster than ever.  But with this rapid pace comes risk. Companies quickly implement new apps to meet their business demands, but the increasing complexity of the infrastructure being used – both in the cloud, on premise, or a hybrid combination – makes it difficult to ensure vulnerabilities are not introduced or vital corporate information is not exposed. In the quest to ensure that policy and governance are in place and security risks are negated, IT often brings innovation to a screeching halt.

    Is there a happy medium that enables developers to continue accelerating innovation, but makes IT confident there’s adequate security? In this article, we’ll look at the importance of governance and policy, and outline the five fundamental security requirements that will help enterprises bridge that chasm that currently separates development and IT.

    Policy Debt – The Downside of Faster Innovation

    Security flaws are not new. Enterprises have faced serious security problems for decades. As today’s computing landscape becomes increasingly diverse and complex with increasing use of the cloud, new vulnerabilities are introduced, which exacerbate problems with existing security methods, such as simple usernames and passwords and an over-reliance on network perimeter security models.

    The rapid introduction of new developer technologies far outpaces an enterprise’s ability to vet them. As a result, enterprise IT faces a tradeoff: rapidly adopt new technologies to satiate business demands thereby accepting more risk, or slow down new technology adoption with the hope of mitigating risk. Tension between enterprise IT and the rest of the business is the inevitable outcome. More importantly, because new apps have so many dependencies, as soon as one is put into production, an enterprise almost immediately incurs policy debt.

    Policy should enable enterprises to track these dependencies, but in today’s IT environments, each piece of infrastructure or cloud resource has its own unique policy model, operational mode and lifecycle.  As a result, enterprises end up with a layered cake of dependencies, which is difficult to keep track of and ensure no security holes are left unpatched.

    Most of today’s security technologies – like gateways and firewalls – are either point-based or palliative solutions. They treat symptoms rather than root causes. And, they only work for traffic that’s routed through them, which precludes most of the server-to-server interactions that happen within the datacenter. Reliance on gateways is akin to locking the deadbolt on the front door of your house but leaving the back door open.

    These simply are not enough to address the proliferation of attacks that have paralyzed companies and exposed customer and consumer data. Consider the three major security Linux exploits – Ghost, Shellshock and Heartbleed – that came to light in the past year.  To patch their systems against these problems, companies needed to find the vulnerabilities and reset servers to activate the fix, which resulted in a cascading failure of servers, downtime and a host of other performance-related issues – simply because there’s no centralized way to apply policy and determine whether a resource in use is vulnerable.

    The Fundamental Five Security Requirements in the Brave New IT World

    To fully protect their increasingly complex IT environments, there are five fundamental security requirements no enterprise should be without:

    1. Resource Naming and Identity – To secure access of a workload or process, it needs to be named so that it can referenced as logic is applied. There is no notion of identity for the applications running today. They’re simply workloads running on a CPU.  If enterprises want to apply policy, they will need an overlay operating system that gives identity to that workload, so it can be organized into a manageable, policy-driven hierarchy.  This type of naming scheme is being done for Internet domains, but there is nothing comparable for the data center that enables IT to find, maintain and operate workloads residing there, regardless of where they are physically run.
    2. Chain of Trust – In today’s data center topologies, no actual proof is needed to ensure that a holder of a token is exactly who it claims to be.  To guarantee a high level of proof of identity and actual trust of components, enterprises require a central signing authority that issues tokens to all clients and internal components. This ensures that the management backplane is resilient to token and credential theft, and the system offers a high degree of trust.
    3. Context Aware Policy – Most systems rely solely on role membership to make authorization decisions, such as  “who” can do “what” to “what.” But enterprises need to go further than that, with the use of a dynamic scripting language for authorization decisions. Every authorization decision will require information over and above simple role membership (date and time, authentication strength, targeted resource and more). The result is a system that adapts more easily to enterprise authorization requirements.
    4. Control of the Network – The network is a vital part of any enterprise system, and controlling access to network nodes is key for enterprise IT governance. Today, network access control is a hodge-podge combination of network perimeters, firewalls, VLANs, VXLans, proxies and security appliances. Workloads exist in network segments and workload connectivity is a function of network segment configuration. Over time, these configurations become rigid, brittle and difficult to maintain. To prevent this, enterprises need to control the network within the cluster so that any workload running must be given explicit access to the network and other workloads (via policy) in real time and regardless of physical properties of the infrastructure.
    5. Ephemeral Service Credentials – Applications and services require connectivity and sometimes credentials to talk to one another. Once an application gets a credential for a service, the application becomes responsible for safeguarding that credential. However, credentials sometimes leak — they can appear in log files or configuration files, and can even be scraped from memory. What enterprises need is a new approach to service access that binds a credential to an individual network path. This ensures that even if a credential were to leak, it couldn’t be used from another location on the network. Moreover, with this method credentials live only as long as an individual workload in the system, rotating every time the application stops and starts again. By taking this approach, the burden on applications for handling credentials is reduced, strains of NetOps and network perimeter security models at scale decreases, and weak links in the trust chain are removed. The result is a more secure system that you can trust without changing your existing investments.

    About the Author/Derek Collison

    derek-collison

    Derek Collison is founder and CEO of Apcera. An industry veteran and pioneer in large-scale distributed systems and enterprise computing, Derek has held executive positions at VMware, Google and TIBCO Software.  As CTO and chief architect of cloud application platforms at VMware, he co-founded the cloud computing group and designed and architected Cloud Foundry,the industry’s first open PaaS. During his time at Google, he co-founded the AJAX APIs group.

  • Security Breaks DevOps – Here’s How to Fix It

    Security Breaks DevOps – Here’s How to Fix It

    The concepts of communication, collaboration, abstraction, automation and orchestration are cornerstones of the rapidly growing DevOps movement. At the same time reliance on virtualized infrastructure and Infrastructure-as-a-Service has exploded, making manual provisioning and management simply not feasible anymore; it takes too long and locks up too many resources. Modern DevOps methods and tools have emerged, allowing IT organizations to move faster and with higher quality, thus giving them the ability to respond to the business with more agility.

    Now security teams have an opportunity to learn from the DevOps experience. Manual policy provisioning and security operations in highly dynamic IaaS environments simply doesn’t work, for the same reason it doesn’t work for DevOps teams – the pace of change is simply too to fast to handle manually.

    Applying security policies based on static parameters and making manual rule changes just before production leaves little time for provisioning the policies. This impacts release quality, increases risk of errors and slows down the DevOps cycle.

    Trying to use DevOps orchestration tools to provision security can leave companies exposed since these tools lack critical controls and don’t integrate with the rest of the security infrastructure.

    To solve these challenges, IT and security teams need to adopt platforms and processes that match the speed and agility of their DevOps brethren.

    Here are the key ingredients you should look for in security solutions that can move at the speed of DevOps:

    • Built-in Automation – Security automation means that any control (e.g. firewall policies, configuration vulnerability scans, intrusion detection, multi-factor authentication) can be deployed and managed without human intervention. Most desirable is full-lifecycle automation, in which policies are set once and tied to some context, after which underlying controls are 100% automated at each stage of the control’s lifecycle, from deployment to de-provisioning. Automated collection of audit and operational data is also critical, especially in environments where infrastructure components are only operational for short periods of time. Even though short-lived, these ephemeral resources are still in scope for auditor inspection, even if not running at audit time. Well-implemented automation enables security organizations to keep up with the scale and rate of change associated with dynamic infrastructure models. Security accuracy and effectiveness are both improved by automation, and potential for human error is removed—especially if API instrumentation enables cooperation of otherwise disparate technologies.
    • Security Orchestration – Platforms that enable security orchestration centrally manage the composition, deployment, and management of individual control components into more complex, service-oriented security systems. By composing many individual controls into a larger system, security orchestration is considered to be a higher order function than simple control automation. In many implementations, orchestration also addresses licensing, metering, chargeback, and other security resource consumption issues that are important in service-oriented cloud computing and software-defined infrastructure environments. 
    • Instant Visibility & Continuous Enforcement at the Workload – Public clouds have no natural perimeter and network segmentation, which leaves individual servers exposed. In private clouds, malicious East-West traffic inside the network is undetected by perimeter tools and can become a serious threat. So choose a security platform that extends your investments in network security directly to the workload itself. The solution should be on-demand and easy to deploy. Many of these platforms have an agent-based model, so make sure the agent is ultra lightweight to eliminate drag on the virtual server, is non-intrusive to the workload and is easy to integrate into DevOps continuous deployment model. The agents should be deployable through orchestration tools, with scripts or manually, even on live systems without reboot, to speed up the process even further.
    • Flexible Policy Definition – A modern security platform should allow security policies to be defined by logical application groupings instead of static network parameters, which protects new workloads automatically and overcomes natural limitations of traditional network security tools.
    • Security at Every Stage – The DevOps model has multiple stages, many of which are conducted on various cloud services and on other virtualized architectures. This leaves assets vulnerable to attackers, so baking in security at each stage prevents this issue. Just as importantly, development teams need to know how security will impact the application being developed, so incorporating security early in the process makes a ton of sense.
    • Layered Approach – Having a platform that provides layered security (not just a firewall) in the DevOps model, is key. Integrating multiple functions from different vendors would prove enormously daunting from an orchestration perspective. So make sure layered security functions like file integrity monitoring, security configuration monitoring, strong access control and vulnerability management are baked into a single platform and included on every system throughout the lifecycle.
    • Seamless Integration with Orchestration Tools – Make sure your security platform integrates seamlessly with the orchestration tools you’re already using. Jumping back and forth between tools can slow things down, introduce errors and lower your overall security posture.

    By implementing a security solution that incorporates all of these attributes, IT can bring security into the high speed, high quality DevOps model that is now required to provision and manage modern infrastructure.

    About the Author/Amrit Williams

    amritAmrit Williams is the CTO for CloudPassage. Previously Amrit was the Director of Emerging Security Technologies and CTO for mobile computing at IBM. Prior to IBM, Amrit was a research director in the Information Security and Risk Research Practice at Gartner, Inc. where he covered vulnerability and threat management, network security, security information and event management, risk management, and secure application development. Previously, Amrit was a director of engineering for nCircle Network Security, and undertook leadership positions at Consilient Inc., Network Associates, and McAfee Associates.

  • Rework is Choking Software

    Rework is Choking Software

     

    Rework is Hell

    “Software may be eating the world, but rework is choking software”, tweeted John Jeremiah (@j_jeremiah).  To shed more light on what is choking software, new data was released last week in the 2015 State of the Software Supply Chain Report.

    In its discussion of application quality and integrity, the report revealed that the average application includes 106 open source components.  It is clear that the use of these components has benefited development tremendously in helping to speed time to market and improve innovation.  While the benefits are undeniable, development teams are also delivering applications that are “insecure by design”.  Of the 106 components per application, the report’s analysis revealed an average of 24 (i.e., 23%) have known critical or severe security vulnerabilities.  Those same apps also showed an average of 9 restrictive license types (e.g., GPL, AGPL, LGPL).

    Screen Shot 2015-06-22 at 9.50.20 AM
    By electively sourcing components with known vulnerabilities and potential license risks, software development teams are building up higher levels of technical and security debt. And in order to reduce some of that debt, unplanned and unscheduled rework is often required.

    No Developer Intentionally Uses Bad Parts

    I have never met a developer that intentionally wanted to use “bad” components in their applications.  That said, I have also never met a developer that wanted to spend four hours researching the latest versions, open source licenses and known security vulnerabilities for components (including dependencies) they wanted to use in their applications.  While 57% of development organizations have internal policies in place that direct “thou shall not use components with poor quality and integrity”, many have stated that the policies are not followed or are simply not enforced.
    Screen Shot 2015-06-22 at 3.02.42 PM

    The problem is one of volume and velocity, while people clutch to old processes that simply can’t keep pace.  The analysis in the 2015 State of the Software Supply Chain report revealed that billions of open source downloads occurred in 2014, of which 6.2% had known vulnerabilities (1 in 16 downloads).  For some large companies, the volume of downloads exceeded 240,000 — where 15,000 (7.5%) had known security vulnerabilities.  At these volumes, manual processes and paper-based policies to prevent poor quality or risky components from getting into your software have no possibility of keeping pace.  While software development practices aim for higher velocity, through component-based development as well as Agile, continuous and DevOps practices, the processes to keep up with it have not changed enough.

    The only way to keep pace with this velocity is through automation.  And if we want to avoid unplanned rework associated with remediating known security vulnerabilities or selecting alternative components with approved license types, automation has to become the norm rather than the exception within development.

    At Speed

    “If I look at the mass, I will never act. If I look at the one, I will.” — Mother Teresa

    Looking at the massive volume and velocity of open source and other artifact consumption can be discouraging and overwhelming. However, the volume and velocity within our software supply chains will not diminish—and without a new approach, the volume of unchecked quality and integrity of parts being consumed will continue to build up as technical debt.

    Automation in areas of testing, build, and deployment has provided significant performance benefits. Likewise, investments in software supply chain automation have shown markedly improved efficiency and controlled risk, as the best practices in the 2015 Report illustrate.  Automation can unleash the potential of an organization’s development capacity. Rarely is there such an opportunity to simultaneously increase speed, efficiency, and quality.

    In order to improve the quality and integrity of components used in our applications, we need to release our clutch on old practices.  We can further embrace automation across our software supply chains — and improve the quality of our applications — by considering these three steps:

    1. Start with creating a software bill of materials for one application.  Visibility into one application can help you better understand your current component usage. A number of free and paid services are available to help you create a software bill of materials within a few minutes. The bill of materials will help you to identify the unique component parts used within your application and the suppliers who contributed them. These reports list all components used, and several services also identify component age, popularity, version numbers, licenses, and known vulnerabilities.

    2. Design approval processes to be frictionless, scalable, and automated.  Manual reviews of components and suppliers cannot keep pace with the current volume and velocity of consumption. Your organization must not only define your policies for supplier and part selection but also find practical ways to enforce them without slowing down development or inadvertently encouraging workarounds. Policies must be agile enough to keep pace with modern development. Strive to automate policy enforcement and minimize drag on developers.

    3. Enable developer decision support.  Developers are primary consumers of components in software supply chains. They initiate every component request. Help developers by automating the availability of information on component versions, age, popularity, licenses, and known vulnerabilities within their existing development tools so it is easy to pick the best components from the start. By selecting the highest-quality components from the highest-quality suppliers early, you will improve developer productivity and reduce costs.

    Here is the complete 2015 State of the Software Supply Chain Report.  I will also be discussing more of the Report findings and best practices on a webinar scheduled for Wednesday, June 24, 12pm ET (register or view it on-demand).

    The previous blog in this series was, Fewer and Better Suppliers.  Next up, I will be reviewing Visibility and Traceability practices across the software supply chain with more commentary from the 2015 State of the Software Supply Chain Report.

  • 7,600 Open Source Projects Per Company (and how it impacts DevOps)

    7,600 Open Source Projects Per Company (and how it impacts DevOps)

    That Supplier is Better For You

    Since releasing the 2015 State of the Software Supply Chain Report, there has been a lot of great discussion across the industry on best practices for managing the complexity introduced by the volume and velocity of the components used across your software supply chain.

    Today I want to focus on the huge ecosystem of open source projects (“suppliers”) that feed a steady stream of innovative components into our software supply chains.  In the Java ecosystem alone, there are now over 108,000 suppliers of open source components.  Across all component types available to developers (e.g., RubyGems, NuGet, npm, Bower, PyPI, etc.), estimates now reach over 650,000 suppliers of open source projects.

    Screen Shot 2015-06-17 at 3.24.39 PM
    Source: ModuleCounts.com

    However, like in traditional manufacturing, not all suppliers deliver parts of comparable quality and integrity. My latest research, the 2015 State of the Software Supply Chain Report, shows that some open source projects use restrictive licenses and vulnerable sub-components, while other projects are far more diligent at updating the overall quality of their components. Choosing the best and fewest suppliers can improve the quality and integrity of the applications we deliver  to our customers.

    While I am hosting a webinar next week to share many of the detailed report findings, I wanted to share a few of the more meaningful stats here.

    Your 7,600 Suppliers

    My research for the report revealed many new perspectives on “suppliers” across the software supply chains.  First of all, I saw that the average large development organization consumed over 240,000 open source components last year — sourced from over 7,600 open source projects.

    Screen Shot 2015-06-17 at 10.29.08 AM
    Average number of open source component downloads per organization in calendar 2014

    On the surface, the huge reliance on open source projects is a great thing.  Development teams have chosen to not write those pieces themselves, but have sourced the needed components from outside suppliers.  This practice speeds development, enables more innovation, and ensures time-to-release goals are  achieved.  The use of open source is so prolific today, few of us could ever imagine reducing the use of those  components and their suppliers in the future.

    At the same time that we benefit from open source, our high paced, high volume consumption practices don’t allow us the time needed to do the due diligence on the suppliers or open source projects where we source our component parts from.

    Screen Shot 2015-06-17 at 10.29.31 AM
    Average number of known vulnerabilities downloaded by organization in calendar 2014.

    For example, of the 240,000 average component downloads in 2014, the same businesses sourced an average of 15,000 components that included known security vulnerabilities.  In many cases, developers were downloading vulnerable component versions, when safer versions of those same components were available from the open source projects. While no one intends to download components with known vulnerabilities, the problem is exacerbated due to the lack the visibility into a better recommended version.

    Fewer Suppliers, Less Context Switching

    Choosing an open source project supplier should be considered an important strategic decision in organizations because changing a supplier (“open source project”) used  is far more effort than swapping out a specific component. Like traditional suppliers, open source projects have good and bad practices impacting the overall quality of their component parts.

    Traditional manufacturing supply chains intentionally select specific parts from approved suppliers.  They also rely on formalized sourcing and procurement practices.  This practice also focuses the organization on using the best and fewest suppliers — an effort that improves quality, reduces context switching, and also accelerates mean time to repair when defects are discovered.  One industry example from the report describes how Toyota manages 125 suppliers for their Prius to help sustain competitive advantages over GM who manages over 800 suppliers for the Chevy Volt.

    By contrast, development teams working with software supply chains often rely on an unchecked variety of supply, where each developer or development team can make their own sourcing and procurement decisions.  The effort of managing over 7,600 suppliers introduces a drag on development and is contrary to their need to develop faster as part of agile, continuous delivery and devops practices.

    Coming to Terms

    When you come to terms with the volume of consumption and the massive ecosystem of suppliers you can source your components from, you quickly realize it is impossible to address this issue with a manual review process.  Any organizations clutching to these outdated manual practices are will continue to be outgunned by the velocity by their software supply chains.

    Just as traditional manufacturing supply chains have turned to automation, software development teams need to take the same approach by further automating their software supply chains.  Information about suppliers and the quality of their projects needs to be made available to developers at the time they are selecting components.  Information about the latest versions, features, licenses, known vulnerabilities, popularity of versions being used, and the cadence of new releases should be  made available to developers in an automated way.  Automating the availability of this information about suppliers can lead to better and fewer suppliers being used.

    Be sure to read the full 2015 State of the Software Supply Chain Report for more information about open source suppliers and organizations sourcing practices.  The report also highlights current and best practices being used in organizations that are managing their use of suppliers that feed their software supply chains.

    To hear more about the overall report findings and industry best practices, please join me on Wednesday, June 24th (1pm ET) for our webinar.

     

  • 2015 State of the Software Supply Chain Report

    2015 State of the Software Supply Chain Report

    In April of this year, I embarked on a six-week journey diving deep into an analysis of the world’s software supply chains.  I evaluated the practices of 106,000 organizations, the 100,000+ suppliers they relied on, and the billions of software components that fueled their agile, continuous delivery and DevOps practices.

    The facts I discovered and share in the 2015 State of the Software Supply Chain Report: Hidden Speed Bumps on the Road to Continuous, (pre-register for the full release: Tuesday, June 16th) fundamentally changed the way I thought about software (and about DevOps).

    The volume and velocity of consumption, the variety of parts and suppliers, and the impact on innovation and quality astounded me.  Early reviewers of the report including Gene Kim (co-author of the Phoenix project), Gareth Rushgrove (Puppet Labs and DevOps Weekly newsletter), Nick Galbreath (Signal Sciences), and Nigel Simpson (Fortune 100 Entertainment and Media company) agreed.

     

    Screen Shot 2015-06-03 at 10.28.51 AM

     

    My aim for this research is not simply to present facts about the global software ecosystem.  I’m aiming to point a spotlight on software supply chain best practices within across a variety of industries that could be used as new benchmarks for software supply chain automation.  Similar to manufacturing of auto, pharmaceutical, healthcare, or defense systems, the effective management of supply chains will create winners and losers.  I’ll share evidence that the best, high-performance software development organizations are benefiting from:

    • Working with fewer and better suppliers
    • Relying on the highest quality supplies from those suppliers
    • Maintaining  traceability and visibility throughout the software supply chain for prompt and agile recall

    Key Points from the Study

    In the best organizations, the research revealed developer net productivity increasing by up to 40%. Just imagine applying that time to more innovation, rather than to rework and maintenance efforts.

    At the same time, the report touches on inefficiencies and complexities that are creating a huge drag on the velocity software development teams are aiming to achieve.  A lack of discipline, focus, and visibility around the software supply chain has resulted in mountains of technical debt, unnecessarily context switching, and outdated sourcing methods that wasted over 3.3 million build days last year alone.

    Hightlight: Automation Across the Software Supply Chain

    The other key insight from this research is the clear need for further automation across software supply chains.  With individual organizations consuming hundreds of thousands and sometimes millions of software components annually, it became obvious that waterfall-centric approaches to identifying the most functional parts, checking quality, validating appropriate licenses, or evaluating security vulnerabilities could not keep pace.  Sourcing practices that regularly go unchecked have also resulted in the use of severely outdated software components, even numerous versions of the same component part.

    Download the Full Report

    Over the next few weeks, I will publish excerpts of findings and best practices identified in the 2015 State of the Software Supply Chain Report and invite you to read along.  Or you can access the full report now through this link.

  • The devOpsSec Dilemma: Effective Strategies for Social Networking

    The devOpsSec Dilemma: Effective Strategies for Social Networking

    I was sad to hear of the passing of John Nash and his wife Alicia this weekend. May they rest in peace. As a game theorist I am familiar with his work and it just so happens that Nash Equilibriums have been in the center of what I’ve been working with lately. It’s an honor to be in a position to build on his ideas and hopefully pass his legacy on to a larger audience at the time of his death. I’ve done my best to pay him my respect by carefully studying his work over the past year, given Velocity starts this week.

    devOps believes in intelligent actors. Security assumes the worst of intentions. Both risk an imbalance of trust. The Prisoner’s Dilemma and the devOpsSec Dilemma, defined here as a lack of cooperation that stems from a lack of trust in an hyper competitive environment, have the same flaw: There’s not a game position that’s safe for everyone because of obliviousness or malicious intent. What I believe is emerging is a low trust cooperative game state. In a devOps world everyone means Everyone both internally and externally. This includes the unique identities of you, your co-workers, the company you all work for, the customers that keep you in business, and even the people who you perceive as your competition.

    The oblivious trampling and opportunistic predation of other people  and organizations are really complementary set operations that mitigate any risk associated with a perceived threat, which is what security is ultimately about. Staying in the lowest risk, highest paying game state is a decent definition of a secure bet for the short game but may not be a safe one over time. If the strategy is damaging others you will eventually compete yourself out of existence.

    We have harassment problems in our industry. I want people to come to events and interact in an effort to network with folks because we grow faster when we share ideas. It would seem we have some of the wrong people showing up given the problems stemming from this type of interaction. If you’re passionate about technology and can respect other people and their skill sets you’re welcome in our community. If not, Keep Out. This applies to everyone, including pushy recruiters and vendors.

    The problem with amensalistic behavior is you’re not aware that your offending someone when it happens. I’ve talked with a lot of people about this and there’s definitely room for a misunderstandings and they’re often cultural. When it turns into harassing behavior and you start looking like a parasite is when it’s characteristically repetitive. The key here is to pay attention to people. Watch for non-verbal queues when people are trying to politely excuse themselves. If you don’t catch the hints people will tell you they don’t have time or the energy to talk and you really need to take No for an answer.

    I’d like to make it particularly clear that if you’re looking for a date you should go look somewhere else. Given the gender ratio issues at events your time would be best spent elsewhere. There are appropriate times and places for it but a professional environment is not one of them. Most conferences and events are in big cities. You can take your name tag off at any time and find plenty of trouble to get into outside of an event if that’s your thing.  That means no one should have to ask you twice, Period. If someone has to tell you three times expect a less than friendly visit from event organizers. Let’s be clear that there’s also zero tolerance for unwanted physical contact in our community. No one should have to explain that to anyone and there is no good excuse.

    With the exception of physical contact and other overtly offensive behavior, we also have to trust that people can make a mistake instead of automatically assuming the worst intentions. An intelligent agent will correct a poor behavior if they’re politely made aware of it. Again, if there’s a characteristic repetition in spite of someone asking them to stop their plausible deniability goes out the door with them. I noticed someone handing out business cards to a strip club in front of a conference recently. I told him that while it was mostly guys here it wasn’t the time and place to be handing those out and he’d have a problem on his hands if he didn’t leave. He apologized and left. Peer moderation can be effective and doesn’t have to hurt anyone. I feel confident this is a fair approach given the explanation of Blameless Problem Solving found on Etsy’s 2014 Progress Report:

    “Making mistakes is an inevitable by-product of doing innovative work. Accidents can actually be valuable and rich sources of learning. We strive to create a blameless culture, in which it is safe to make mistakes and to speak up about them. This allows us to gain as much knowledge as possible from our experiences.”

    We need to move out of no trust interference and do a better job of working together. This is a shift from no trust security towards high trust safety. This is also the split between devOps and security. DevOps believes in intelligent actors. Security assumes the worst of intentions. I covered this material at DevOpsDaysNYC. The video goes into more detail and has some ecological examples of the relationships on the chart, which I’ve added to since the talk.

    [youtube http://www.youtube.com/watch?v=O9hgYtNlo3o]
    The Prisoner’s dilemma is a Pareto inefficient Nash equilibrium because there’s no honor among thieves. Not defecting on the other prisoner leaves an opportunity for them to defect on you, walk out of jail, and leave you incarcerated for the longest period of time. Both prisoners defect and they both end up serving a longer sentence than if they had taken the risk of cooperating.

    Prisoner B stays silent (cooperates) Prisoner B betrays (defects)
    Prisoner A stays silent (cooperates) Each serves 1 year Prisoner A: 3 years
    Prisoner B: goes free
    Prisoner A betrays (defects) Prisoner A: goes free
    Prisoner B: 3 years
    Each serves 2 years

     

    A significant change in a system replaces the original with a different, adapted system. A minimal number of local changes can be accommodated without inherently changing a system but enough local change in a short period of time is equivalent to a global shift. The devOpsSec Dilemma is the type of systemic failure that demands a systemic change. So I came up with a new game board.

    Here we move from no trust competitive environment where everyone gets hurt towards a Pareto improved equilibrium. By attempting to move out of competition we risk being stepped on or preyed upon if our counterparts don’t make the shift to a higher trust relationship with us. The good news for our game board is that I don’t think anyone has to die or go to jail. While there is some risk here it’s most often a blow to one’s ego, which is a risk I can entertain for something I care about. The solution here is more diplomatic peer moderation and the ability to take constructive feedback even if it’s uncomfortable. We need to move out of safety and danger towards cooperative learning. When you move out of learning and into danger we end up hurt, but it isn’t always competitive.

     

    adaptiveTrust

    Cooperation is at the heart of John Nash’s work. Trust is fundamental to our survival and is built by showing what you can contribute, not haggling and spit-balling in the bike shed. The more we trust the more we learn and the less we get hurt but it takes a combined effort. If your patterns as an individual or an organization don’t demonstrate these qualities over time then you’re done. As Deming put it, “Survival is not mandatory.”

  • DevOps Connect: Rugged DevOps @Infosecurity Europe

    DevOps Connect: Rugged DevOps @Infosecurity Europe

    We have assembled another top flight list of speakers for our DevOps Connect event @Infosecurity Europe.  While pre-registration is sold out, if you are one of the 15,000+ attendees of Infosecurity Europe, you can still come to DevOps Connect on a first come, first serve basis.  Details and schedule are below:

    When: Thursday 4th June, Olympia London
    Time: 9.00 – 17.00

    Agenda for DevOps Connect:Rugged DevOps

    • 8:30am to 9:00am
      Meet and Greet
    • 9:00am to 9:10am
      Introductions – Alan Shimel and Wai Man Yau

    • 9:10am to 9:50am
      Joshua Corman, CTO, Sonatype and Rugged (Keynote)
      Dr. StrangeOps: How I Came to Embrace Rugged DevOps & SW Supply Chains

    • 9:50am to 10:30am
      Gareth Rushgrove, Puppet Labs
      Maintaining Control While Letting Go

    • 10:30am to 11:00am
      Florin Coada, Technical Specialist Graduate in Application Security at IBM
      Security at Speed; Best Practices for a Secure DevOps Implementation

    • 11:00am to 11:30am
      Helen Beal, Head of DevOps at Ranger4 Limited
      The DevOps Toolkit

    • 11:30am to 12:00pm
      Justin Arbuckle, Vice President, EMEA & Chief Enterprise Architect at Chef (formerly Opscode)
      A Manifesto for high velocity compliance

    • 12:00pm to 1:00pm
      Lunch Break

    • 1:00pm to 1:30pm
      Wai Man Yau, Sonatype EMEA
      Real World Customer Stories from the Software Supply Chain

    • 1:30pm to 2:00pm
      Stephen de Vries, CTO Continuum Security
      Automating Security Tests for Continuous Integration

    • 2:00pm to 2:30pm
      Elizabeth Lawler, CEO and CoFounder , Co-Founder Conjur Inc
      SecDevOps 2.0- Managing your Robot Army

    • 2:30pm to 3:00pm
      Marc Hornbeek, Senior Solutions Architect at Spirent Communications
      Case study – DevOps Cost-Effectively Secured Quality and Time-to-Market for a Complex Hardware/Software Network Product

    • 3:00pm to 3:30pm
      Jonathan Fletcher, Enterprise Architect – Technology & Platform (DevOps) Lead
      DevOps:  How the Industrial Revolution Got Us Here

    • 3:30pm to 4:00pm
      Benjamin Wootten, Co-Founder at Contino
      Transforming to Devops in the Enterprise

    • 4:00pm to 4:10pm
      Thank you and closing – Alan Shimel and Wai Man Yau

    If you are in London during these dates you can still register for Infosecurity Europe for free and attend DevOps Connect. Hope to see you there.

  • The #1 trick DevOps shops use to reduce vulnerabilities

    The #1 trick DevOps shops use to reduce vulnerabilities

    A new report out this week highlights how important it is to find ways to fold in vulnerability assessment information into the software development lifecycle. Released by WhiteHat Security, the Website Statistics Report 2015 offers a smorgasboard of interesting data around web application security. Amid all of the statistics, though, DevOps shops should perhaps home in on one major takeaway—statistical evidence that points to a single practice that could make a huge difference in reducing vulnerabilities in the long run. The trick in question? Tying vulnerability data into the bug tracking system.

    “When it’s all said and done, there are three metrics that matter in application security. It’s the number of vulnerabilities you have, the speed at which you fix them and the percentage of which are fixed,” says Jeremiah Grossman, founder of WhiteHat. “And what we’ve found is that when you wire into the apparatus  whatever vulnerability  assessment data that you get into the bug  tracking system, which is very important  for DevOps, that actually is what achieves the best results.”

    As he explains, simply providing vulnerability assessment data in a raw format—for example, a PDF document listing flaws—this does nothing to fit within an automated pipeline and vulnerabilities will remain unfixed. In the report released this week, Grossman reports that organizations that made the connection between the vulnerability feed and the development process’ bug tracking system exhibited 40 percent fewer vulnerabilities, fixed issues a month faster on average and increased their remediation rate by 15 percent compared to the rest of the pack.

    While Grossman admits that it is difficult to know exactly what percentage of customers ascribe to different development methodologies, his rough guess is that about half at this point are instituting some kinds of DevOps principles in order to release at least every two to three weeks. He recommends that security professionals hoping to get more involved in the spirit of cooperation that drives DevOps transformations should start with metrics.

    “Create a metrics program, just like the DevOps guys do, to measure the security of that environment,” he says, explaining that the three metrics mentioned above are good ones to start with. “Then you can track the performance of the DevOps groups in terms of security and deliver that data back to the group. Then when you want to get strategic about what processes and improvements in the DevOps environment that need work, you can be very laser focused. App sec programs should be tailor-made to the internal processes of the organization around the metrics they want to improve.”

  • DevOps Leadership Series: Security at Velocity

    DevOps Leadership Series: Security at Velocity

    If it does not fit, it does not get done.  For many DevOps practices, application security falls into the “does not get done” bucket.  That’s because for many DevOps-centric organizations, application security has historically been done somewhere else, by someone else, who is slow.

    Go faster.  Shift left.  Remove complexity. Reduce rework.  All mantras of DevOps practices.  And while DevOps practices have changed dramatically in recent years, many experts will tell you that application security has not changed enough.

    In this installment of the DevOps Leadership Series, you will hear Chris Corriere (DevOps Engineer, Autotrader) and Mitchell Ashley (VP Information Technology, CableLabs) share perspectives on the state of DevOps and security. It is about security at velocity.

    But is going faster and automating resulting in better security? There are still security pros who are uncomfortable with that premise. Nevertheless, that is where this is headed. The security community has to come to the mountain, otherwise the mountain is coming to them.

    First, listen to Chris’ Corriere of Autotrader tell us his perspective that security can move at DevOps speed, as long as you take a diversified approach:

    https://youtu.be/8DdfHkAK1Fk

     

    Then hear from Mitchell Ashley, VP of IT at CableLabs as he remarks on the evolution of security from a validation role (at the right) to an integrated, ingrained role that has shifted left:

    https://www.youtube.com/watch?v=pg_m7dYqUPU

    This is the third in our series of interviews from this event. Stay tuned as the actual sessions from DevOps Connect will be posted shortly.

    NOTE: If you have missed any of the other videos from this series, you can find them here.  (We’re up to 15 so far).

  • DevOps Leadership Series: Software Supply Chains

    DevOps Leadership Series: Software Supply Chains

    We kicked off this series on Monday with Gene Kim (@RealGeneKim) sharing his views on the big theme for DevOps in 2015: proving that DevOps is applicable for large organizations.

    Another theme that arose often during our recent “DevOps: Wine-ing, Not Whining” event was the importance of software supply chains.  Every software development organization has a software supply chain, and DevOps leaders are now applying principles from lean manufacturing, Deming, and Toyota supply chain management to improve their operations.

    They are applying software supply chain management principles help:

    • choose higher quality parts (e.g., software binaries, containers, microservices)
    • select higher quality suppliers (e.g., fewer defects, faster MTTR records),  and
    • improve traceability (e.g.., identifying defects or known vulnerabilities to expedite break/fix)

    Today, we will hear from Jez Humble (Chef), Julie Tsai (Retail Giant) and Nick Galbreath (Signal Sciences) as they discuss on importance of software supply chains and DevOps.  Then after watching the videos, you can learn more about the sea change in software supply chain automation in these two blogs from Mike Hansen (Software Supply Chain Automation) and Ericka Chickowski (Security, DevOps and the shift to a software supply chain).

    Here are today’s short videos from our 2015 DevOps Leadership Series:

     

    [youtube http://www.youtube.com/watch?v=4L4nrNpdTM4]

     

    [youtube http://www.youtube.com/watch?v=UEkVYJ1T2NY]
    [youtube http://www.youtube.com/watch?v=nTv8Yx0CpfY]

    NOTE: If you have missed any of the other videos from this series, you can find them here.  (We’re up to 15 so far).