Category: DevSecOps

  • 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.

  • Bring Your Own Exploit

    Bring Your Own Exploit

    Here’s a simple question: for each tool that your organization uses, have you (or someone else on your DevOps team) changed the default passwords? That should be a no-brainer, shouldn’t it? Of course you changed them! Or at least you changed them for the tools that looked like they would have default passwords. Well, OK, at least the ones that looked like they might present an obvious security risk — and where you noticed that there was a default password. Would those other tools even provide an intruder with a useable exploit?

    (more…)

  • 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.

  • Stop whining about shadow IT and do something about it

    Stop whining about shadow IT and do something about it

    Much has been written about shadow IT at the business unit and employee level where the proliferation of cloud applications has all but eliminated IT’s control over what applications are used in their organization. The explosion of public cloud technologies has caused an identical revolt amongst development teams who no longer want to—or need to—wait for IT to spin up the IT infrastructure needed to fuel their development efforts. The reality is public cloud has drastically changed the expectations of developers – even if they aren’t using it.

    Gone are the days where development teams are satisfied with putting in a help desk request for a new server and waiting to access it. Developers now expect IT to provide services similar to what they can get from a public cloud provider. And if you can’t provide it? Then you risk them pulling out a credit card and bypassing everything you’ve built. But just as shadow IT can wreak havoc on data security and IT budgets, there’s a whole new set of problems that can arise when shadow IT hits the infrastructure level. So now that the developers’ expectations for immediate resources have been changed irrevocably by public cloud, what can IT do to bridge the gap?

    Calling a truce: provide self-service provisioning and management

    First and foremost, the obvious one—give developers the immediate access to IT resources that they need to do their jobs. IT needs to leverage its existing investment in virtualization technologies by providing self-service provisioning and virtual machine management capabilities to developers. In other words, get out of the way and give them what they want.

    At the minimum, IT should be looking to setup an internal cloud management system which provides IT an on-premises solution with:

    •     Integration to existing authentication/authorization systems (e.g. Active Directory)
    •     Quotas to control usage by employee/group
    •     Chargeback/showback to provide usage tracking and accounting

    Giving back control is the best way to ease what can be a tenuous relationship between IT and developers. Developers will be happier because they will be provisioning new servers in minutes rather than days and IT can focus on more interesting challenges.

    Abstract away the complexity

    Self-service provisioning is only step one. IT needs to get out of the business of provisioning servers and let developers manage their virtual machines themselves. However, that doesn’t mean that IT should leave developers to manage every aspect of their cloud usage on their own. On the contrary, IT’s job should be to create the tools and infrastructure to ensure best practices within your organization and track IT infrastructure resources to avoid unnecessary infrastructure costs.

    But how? The first step is using a centralized automation and orchestration technology. I won’t get into the religious battle between the various flavors—Puppet, Chef and Ansible are the three most common that we see and they all have their strengths and weaknesses. However, they all provide the type of framework IT needs to empower self-service provisioning capabilities.

    IT should own the base OS images which developers can use for their virtual machines and use an automation framework to provide the means so that developers can easily set up a common set of framework applications (e.g. web servers, databases, monitoring tools, etc.).

    IT can also use cloud management tools to effectively track resources. We’ve seen many instances where customers have discovered numerous unused VMs. By tracking resources and enforcing expiration dates on certain resources, IT can deliver infrastructure more cost effectively.

    Give users choice

    Frankly not all clouds are created equal. And certainly not for all tasks. An internal VMWare virtualization may provide a great cloud—once IT has provided the services mentioned above—for most developer’s needs—but don’t stop there. For example, public clouds, like AWS, Azure, Google, have servers located all around the world.  That makes them ideal for web applications which are going to have geographically dispersed users. Most IT shops certainly shouldn’t be trying to duplicate that capability or prevent its usage. Embrace it instead, where appropriate!

    That doesn’t mean that IT shouldn’t have visibility and control into that usage. IT should strive to create a system which supports a collection of private and public clouds, has unified chargeback/showback and quotas across ALL of the private and public clouds that IT wants to support.

    Abstract Away the Complexity to Support Teams Beyond Developers

    These best practices shouldn’t be limited to developers! One of my favorite use cases that I have seen was an IT shop which provided their sales team with the capability to spin up VMs for product demos. They encapsulated the complexity of 10+ product variations and multiple operating system varieties into a single dialog box.  When the sales manager wanted to do a demo, they checked a couple of boxes in a dialog box, hit submit and a VM was spun up on their internal VMWare cloud which automatically expired 8 hours later. This was a perfect example of allowing a non-technical user to control of their own virtual machines while IT maintained complete control of the underlying technologies.

    Maintain flexibility!

    One final word of caution: the world of private and hybrid cloud is changing very rapidly. IT needs to be able to utilize their existing virtualization infrastructure, typically VMware, today while exploring new private cloud options like OpenStack and preparing for the future of containerization and micro-services.  It’s important to avoid solutions which are locked into a particular technology—which may leave IT behind in this rapidly changing environment.

    There is no doubt that public cloud has led developers to have drastically increased expectations for private IT. By putting in place a cloud management platform backed by DevOps server automation, IT can meet these expectations and stop the growth of shadow IT at the infrastructure level.

    About the Author/Jon Mittelhauser

    Jon Mittelhauser is the CEO of CloudBolt Software. A 20-year Silicon Valley veteran, Jon Mittelhauser has a proven track record of building highly regarded technology organizations from the ground up and helping to architect pioneering technologies. He is considered one of the founding fathers of the World Wide Web. He was co-author of the first widely-used Web browser, NCSA Mosaic, and was a founding engineer of Netscape Communications Corporation.  Mittelhauser was an early investor in Tesla Motors and one of the first Tesla Roadster owner.

  • Managing Open source software components

    Managing Open source software components

    Building any software need lots of efforts including resources, time, money, etc. It is really a great pleasure when it goes live or gets released. In parallel, there is always a chance that bugs may put the release in a difficult condition even after multiple rounds of testing. Teams can fix bugs related to software features or functionality, but the ones which can hit badly are

    • Security vulnerability.
    • Licensing risk of open source component.
    • Outdated open source component.

    The world is moving towards open source in a very fast pace and its growing use in software as components inside the application. Open source components are available free for us, however there could be more risk while using them. A product which is paid and commercial is bound to fix issues and provide adequate support for any vulnerability or security issue and Licensing, But open source software may have a little more of a high risk and its very important to be updated about new releases and available bug fixes.

    If open source components are not monitored properly and keep up to date, that may lead the software to become vulnerable.

    Above checks needs to be done during the development phase and ruled out any discrepancy related to security or legal. This check can be included as part of build process to make sure it does not pass the fist barrier and caught even before hitting the testing phase. Eventual this can save development and testing effort and their time.

    There are tools available which can take care of some/all of verification of open source components in various phases.

    Artifactory

    This tool can verify the license of the open source component and check its compatibility with various definitions. You can even add your own license definition as per your requirement.

    Sonatype Nexus and WhiteSource

    These tools will verify the license and keep the component information up to date. They will check for any updates,  bug fixes for any vulnerability issues and notify the user. These tools can do component security vulnerability and license analysis with the latest available information.

    Security issues would be the last thing any software developer wants. Even small legal or security problems can put your system/software in a dangerous situation. Better to secure software first then fixing it later.

    Reference ->

    http://www.scmtechblog.net/2015/06/managing-open-source-component.html

    http://www.scmtechblog.net/2015/03/maven-repository-tools-comparison.html 

  • 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.

  • Sleep easy: release automation reduces DevOps security threats

    Sleep easy: release automation reduces DevOps security threats

    Sleep easy: release automation reduces DevOps security threats

    “Devops reigns”. “DevOps redefines the way services are launched and managed”. Just two of the recent headlines from the sea of coverage on DevOps. It’s a reasonable argument. The software development methodology emphasizes communication and collaboration between software developers and other IT professionals, and is quickly gaining ground as organizations see a way to launch services faster and improve operations performance. The current DevOps talent shortage also points to Fortune 1000 companies waking up to the difference DevOps can make.

    Here’s the catch. While DevOps appears the master and commander of faster feature releases, it also has the potential to expose software vulnerabilities and security threats in your production environments. We all know that assembling existing code is more efficient than rewriting it from scratch, for example. And when assembling applications from libraries, developers typically use the latest version of that code, assuming it is likely to have less bugs.

    However, new releases can open up new security vulnerabilities. Take the Spring Framework, for instance, a Java platform that provides comprehensive infrastructure support for developing Java applications. According to Joshua Corman, CTO of Sonatype, 81 of the 85 versions of the Spring Framework have known vulnerabilities.

    Software and security vulnerabilities can also rise to the surface unless there is an audit of the production software for security defects. Developers can easily pick up any code they choose without identifying the source or what they did with it. Speaking at the RSA Security Conference, David Mortman, chief security architect at Dell Software, explained that when he began software audits at the company, 198 known execution flaws were found in the code base—putting the company and its applications at risk. And this risk is set to do more harm as DevOps is used to develop physical ‘Internet of Things’ products and services.

    Here’s another fact to put the issue of security into context. Organizations collectively spend $20 billion every year on network security, $10 billion on host security and $5 billion on data security. And you know how much is invested in software supply chain security by all companies? Just half a billion dollars.

    It’s not all bad news though. During the RSA Security Conference, Mortman commented, “A good DevOps process should be implemented using automation tools that can help to track and document updates. DevOps is about change management, process flow and documenting those processes.”

    And automation really is the answer here. It enables you to bring your new products and services to market faster, whilst remaining in control. By automating your application release process, you package the release from your continuous integration tool and securely promote it to the next environment via a reusable work flow. You maintain complete visibility throughout—and there’s no disruption to the business.

    Any software vulnerabilities are quickly identified using role-based access controls: only authorized staff get to promote packages, and only approved packages can move through the lifecycle. Moreover, the automated deployment model ensures you keep track of the code goes on each server and with what configuration settings. And if you are not happy with any aspect of the release, automation enables you to roll back the deployment to its previous state. Finally, comprehensive audit reports help you see who did what and when throughout the entire release process.

    Automation delivers other unique attributes to reduce security risks:

    • Packages and promotion paths so you can be confident that what is deployed is correct
    • Workflows so you have a standard and quality-assured way to consistently           deploy new changes
    • Deployment models to ensure the correct setting and configurations are applied to each environment.

     

    Your development squad is under more pressure than ever to deliver more functionality, faster without disrupting current applications. By automating your application release process, you not only embrace DevOps in full strength, you also gain back control.

    About the Author/ Dr. Chris Boorman

    chris-boormanAs Chief Marketing Officer, Dr Chris Boorman is responsible for Automic’s worldwide marketing.
    Prior to joining Automic, Dr. Boorman served as Chief Marketing Officer for cloud collaboration vendor Huddle, and data integration leader Informatica.  He has over 20 years of experience leading international teams at enterprise companies including SDL, salesforce.com, VERITAS and Oracle. Reach him on Twitter: @CHBoorman

  • 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.

  • What is Adaptive Security?

    What is Adaptive Security?

    72 days after the fact AdultFriendFinder.com, a “very mature” dating site, realized they had been hacked. The VERY personal information of 3 million registrants has been held hostage. By now, it should be clear that in the modern software development world, old-style static security just won’t work. Of course, there are times when the static security model still applies  —  for example, on a relatively stable, hardware-based system with traditional, non-continuous deployment and a limited traffic volume. Such environments can easily be routed through a checkpoint with no significant loss in performance.

    (more…)