staging-devopsy.kinsta.cloud

Tag: devsecops

  • Bridging the gap between DevOps and Security

    Bridging the gap between DevOps and Security

    Security should be baked into the DevOps process, from tools to skills to collaboration. DevOps and security are not mutually exclusive.

    The problem with digital innovation is that considerations for compliance come later, after the product or service is on the market. From public cloud infrastructure to Internet of Things to mobile apps and even to DevOps, tough requirements like security aren’t built into innovators’ plans. Entrepreneurs are thinking primarily about shiny, new, fast and disruptive. Yet for the CIO and other chief executives accountable to customers, laws and financial markets, managing risk around sensitive data is top priority.

    DevOps processes are at the heart of business innovation: think Netflix, Facebook, Etsy and Nordstrom, all leaders in their sectors. Yet many of the popular DevOps tools and methodologies, whether commercial or open source, haven’t been optimized for the needs of enterprise security. An application running in a container, for instance, will still require attention around configuration to ensure application security.

    As well, many security professionals haven’t yet made the leap to understanding the changing best practices for security in this new world of cloud/agile/mobile IT. Some security experts have imposed barriers to DevOps, by resisting the switch to faster, more iterative development along with the public cloud.

    On the surface, the speed at which DevOps teams are approving and releasing code would suggest an increase in security risks to end users by eliminating rigorous security review phases. Yet managing security, as with testing, is in fact optimal when performed side-by-side with developers as code is being written. By integrating security, people and processes tightly within the continuous delivery cycle, DevOps can do a better job of eliminating loopholes and gaps in the code before production. DevOps tools emphasize the use of frequent and automated processes to improve software quality: also an ideal model for handling security testing and fixes. Determining the best way to merge security with DevOps is a work in progress. The following concepts can provide a framework for getting started:

    1. Use the best of DevOps for security: DevOps, with its focus on automation and continuous integration, provides a more holistic framework for security management. Start by considering security through every step of the development and production cycle. Security professionals can help developers root out design problems in the beginning – such as ensuring all data transport is encrypted. Integrate automated security checks into development, testing and deployment phases, and educate all team members about the importance of incorporating security thinking in their specific job roles. Security should no longer be the last process before committing the code to production.
    2. Investigate new DevOps and Cloud security tools: Fortunately, the security technology industry is ramping up quickly to the needs of DevOps security. Static Application Security (SAS) tools test for security when code is being written while Dynamic Application Security (DAS) tools test for interface risks. A few of the reputable systems include Checkmarx, Veracode and Parasoft. The third area of security automation tools covers penetration vulnerability testing, such as Nessus, developed by Tenable. Other contenders in this area include Qualys and OpenVAS. These tools can integrate smoothly into the software development lifecycle, such as by plugging into Jenkins. By adding automation, security is not only built-in, but doesn’t slow down the DevOps process.
    3. Getting buy-in from security teams: This might just be the hardest part. While developers are incentivized to go faster and do more, security professionals are incentivized to control, monitor and reduce risk. Meeting in the middle is definitely possible – but it will require some opinion shifting on both sides. Developers and product managers will need to understand the importance of working collaboratively with the security team, and in an accountable way. Security people can benefit from a more comprehensive understanding of security in the cloud. This should include continuous education on the new tools and services available today to manage risk and to deliver even higher levels of security than in the past – from better reporting, to API-based security and easier encryption at rest.
    1. Manage tool sprawl: The concept of self-organization is an important one in DevOps, because it fosters a spirit of flexibility and rapid collaboration. Yet this same principle can also lead to environments of dozens or even hundreds of different tools in use to manage deployment, configuration, QA and orchestration. That creates risks for visibility and monitoring as well as standardizing around security controls and access. Engineering leads should help strike a balance between too much and too little governance when it comes to tools and workflows by providing guidelines for tool selection. The DevOps automation infrastructure itself can introduce risks. If a hacker gains access to a tool like Puppet or Chef, he can modify any number of configurations and add new user accounts. Configuration and change management tools must be adequately secured and governed, lest they become a new attack plane.

    With the advent of DevOps, there’s an opportunity at last for security to become an integral and seamless aspect of innovation. We think it’s not only possible but critical to give security the attention it demands in the world of fast IT.

    About the Author/Kris Bliesner

    Kris BliesnerKris Bliesner is CTO and co-founder of 2nd Watch, where he oversees strategic and technical development of 2nd Watch’s cloud-based products and solutions. Prior to co-founding 2nd Watch in 2010, Kris held many top IT positions with companies including Microsoft and Ambassadors Group.

    Connect with Kris: LinkedIn, Twitter, 2nd Watch Blog.

     

  • What approach to application hardening is right for your organization?

    What approach to application hardening is right for your organization?

    There’s no shortage of readily available hacker tools and techniques and stories in the news about mobile app hacks for both the iOS and Android platforms.

    Fortunately, security solutions providers have responded swiftly and there are many approaches that one can leverage to harden an app that is “out in the wild.”

    For those of you who may not be familiar with the term, hardening is a key step at the end of any secure software development lifecycle process which:

    • Confirms that the app is running as designed at runtime
    • Thwarts hackers’ efforts to reverse engineer the app back to source code

    Which hardening approach is right for your app? To the uninformed purchaser, simple obfuscators are attractive because they are low in cost, require little training and are quick to implement. However, given the sophistication of today’s hackers, it is important for app developers to look beyond the surface and take a more strategic approach to choosing an application hardening solution.

    Below are four key factors that IT Security professionals should consider when evaluating application hardening solutions:

    #1: Value of your applications

    A key factor to consider is the level of investment your company is making in an app in terms of R&D and maintenance costs.

    • If valuable proprietary intellectual property such as algorithms or monetizable content is embedded within the app, you should consider the potential revenue loss to your company if the app is successfully hacked.
    • If the app processes sensitive information such as financial transactions, account information or authorization credentials, you should consider the potential loss of revenue through fraud and potential collateral damage that could occur if the app is hacked or Trojanized. Collateral damage may include penalties for non-compliance with regulations, expenditures on security upgrades, and even costs associated with crisis management communication campaigns to manage adverse publicity and restore brand value.

    There is a prevalent belief that encryption and basic obfuscation techniques in and of themselves are adequate measures to protect apps against hacking. String encryption and variable renaming form a beneficial security layer, but they are inadequate when used in isolation.

    Also, it is important to understand that not all obfuscation and encryption tools are created equal. Obfuscation is often confused with simple method renaming techniques and basic string obfuscation technologies, which can be quickly broken and easily reversed. Further, any encryption wrapper that applies the same measures of protection across all the apps it secures can be easily broken by determined hackers. Remember that once a wrapper technology is broken, every application secured by that vendor will be compromised.

    See chart 1 below for recommended protection techniques for Low and High Value apps

    Chart 1: Recommended Protection Techniques

    chart1

    #2: Scale and Sophistication of Attacks Your Apps Will Likely Face
    Minimal protections against counterfeiting and repackaging are built into the app distribution ecosystem — including measures such as:

    • Detection of jailbreak or root conditions that enable side-loading of applications, many of which are Trojanized.
    • Monetization libraries to confirm that only legitimate applications are downloaded through an app store and that they are correctly purchased or licensed. However, these libraries can and are often breached by cybercriminals.
    • Audit processes to validate that only legitimate and harmless apps are placed in the app store. Audit mechanisms to block illegitimate apps from distribution to users are far from perfect, as seen by recent iOS malware, including XcodeGhost.

    Consequently, it is important to determine the scale and sophistication of attacks that you anticipate for your applications, and validate that the security solution you rely on is capable of meeting the challenge. For small-scale developers with free- or ad-supported apps, typically basic application protection will suffice, even though ad revenue may be subverted through Trojanization.

    In contrast, for business-critical enterprise applications, it is safe to assume that an organized army of hackers will be actively looking for ways to subvert your app as quickly and as comprehensively as possible. Since such attacks are designed to be covert, it can take weeks or even months until evidence of a successful hack surfaces. For that reason, measures of defense against attacks have to be complemented by measures of detection and reaction. For example, deeply instrumenting an app to detect attempted attacks and react with functions such as “phone home” can provide long-lasting and durable protection.

    Consider the recent benchmarking study that analyzed an Android Java mobile payment application that was hardened with a comprehensive protection solution against the same application with a Basic Java protection solution. Key findings from the study appear in the chart below:

    Chart 2: Strength of Protection of Basic and Comprehensive Hardening Techniques

    chart2

    Attacks that systemically compromise the underlying libraries an app relies on are the fastest growing class of attacks – and presently the most dangerous. This makes it imperative that high value apps are able to verify the pristine nature of their entire execution environment before unlocking sensitive functionality. Obfuscation solutions that focus solely on variable renaming or string encryption can deter static reverse engineering but are not able to protect against the full spectrum of high-intensity attempts to compromise the app.

    #3: Agility and Portability

    The portable device ecosystem, spanning smartphones and tablets and wearable devices, is among the fastest growing and fastest evolving. In stark contrast to the PC ecosystem — which is dominated by only a few chipset and operating system combinations, the portable ecosystem is a combinatorial nightmare of chipsets, OSs, programming technologies and hardware functionality.

    Because it is likely that mobile platforms will continue to evolve at their current breakneck and unpredictable pace, choosing a solid security partner with a history of innovation- that can keep pace with evolving ecosystems- is crucial. Additionally, selecting a security tool that is designed for cross-platform portability and extensibility will go a long way in helping you adapt to new platforms that become available.

    #4: Overhead and Performance Impact

    Memory footprint, power consumption and performance are important considerations in portable devices, where resources are limited and battery life is precious. All security technology will impose an additional memory footprint in storage and at run-time. It will also impose process overhead in terms of programming effort, compilation complexity and run-time execution characteristics.

    That said, more sophisticated application hardening solutions can offer a stronger trade-off between performance impact and protection strength relative to free- or low-cost solutions. For example, brute-force simple obfuscation can quickly cause memory bloat and diminish execution speed, while basic check summing can adversely impact run-time performance while retaining single points of protection failure.

    When apps are deployed to millions or billions of users, and/or where transaction volumes are expected to be high, it is crucial that the security solution chosen be as robust and reliable as your own app code. Obfuscating sections of the code that are sensitive to performance degradation, such as computation-intensive functions or graphics rendering routines, has an impact on runtime performance. It’s paramount to choose a protection solution that offers tunable performance vs. security tradeoff measures, and provides developers better control on size and performance of their code.

    The rise of mobile computing and soaring app usage has companies of every size and caliber scrambling to keep up. With customer loyalty and revenues at stake, developers are scrambling to release cutting-edge apps with little thought for long-term security considerations. In these conditions, it is tempting to treat code hardening as a checkbox and select the cheapest, most readily downloadable tool to do the job – but let the buyer beware. If you take the time to assess the value of your applications and the available options, you’ll realize that if you have a high value app and focus solely on cost, you are likely to be “penny wise and pound foolish.”

    About the Author/Patrick Kehoe

    PatrickPatrick joined Arxan in January 2014 as Chief Marketing Officer. Mr. Kehoe has over twenty years of experience building and managing sales and marketing capabilities for software, hardware, and service providers in the High Tech industry. Over the past three years, he held leadership positions at Siemens Enterprise Communications (SEN) – a global provider of communications software and services. Most recently he was responsible for North American marketing and partner business, where he oversaw the development of the strategic plan and drove Market Awareness, Pipeline Generation, and Sales results. Previously, he managed SEN’s Global Marketing Strategy, Intelligence, and Operations. Prior to SEN, Mr. Kehoe held positions at Booz Allen Hamilton and MarketBridge, a Sales and Marketing Professional Services Firm, where his clients included: IBM, SAP, Symantec, and VeriSign. Among other areas of focus, he was responsible for market expansion, new product marketing, digital marketing, and social media. Mr. Kehoe has a track record of success in North America, Europe, South America, and Asia, and has spoken at conferences and corporate events on a variety of sales and marketing topics. He holds a degree in Computer Science from Vanderbilt University and a MBA from the Darden Graduate School of Business, University of Virginia.

  • Combining SecOps and DevOps

    Combining SecOps and DevOps

    Security has to be top of mind for most any company that is moving, or has moved, to the cloud. And, businesses know they need to act swiftly to ensure that any new products or services they’re dreaming up do not expose them to risk.

    How can they do that when the fast-moving nature of the cloud is leaving proper security practices in the dust? The problem today is that today’s security solutions are proprietary, too slow and take too many resources.

    Bottom line, the security model that has served most businesses well was never built for speed, and is simply unsustainable for opportunities in today’s cloud-centric world. Today, security solutions must be agile, lightweight, loosely coupled and extensible.

    On the front lines at various companies you’ll see a new type of cooperation –  where two teams most directly involved in a potential solution, development and security – are breaking down the traditional (and often opposing) silos and collaborating more openly to drive secure innovation from the start.

    We’re seeing a new “marriage” of SecOps and DevOps that creates a whole new mentality for driving innovation inside and outside of organizations. This new mentality allows security and DevOps to find common ground to make it easier for organizations to align their security goals with the delivery of their products at today’s rapid speed of business.

    While businesses are changing internal structures to address cloud security, there are also a number of new solutions that can be deployed against a company’s clouds and deliver security intelligence back to the DevOps teams.

    These kinds of tools are especially important for start-ups and SMBs that face unique challenges securing their businesses from cyber attacks and preventing data breaches.

    By encouraging greater collaboration between security and DevOps, and relying on outside solutions to assess and identify potential threats as new products and services are developed, businesses of all sizes can feel a higher level of confidence that they’re addressing security concerns by enforcing industry-leading security practices every step of the way.

    About the Author:/Tim Prendergast

    tim p Tim Prendergast co-founded Evident.io to help others avoid the pain he endured when helping Adobe adopt the cloud at a massive level. After years of building, operating, and securing services in AWS, he set out to make security approachable and repeatable for companies of all sizes. Tim led technology teams at Adobe, Ingenuity, Ticketmaster, and McAfee.

  • DevOpsSec – Creating the Full Triangle

    DevOpsSec – Creating the Full Triangle

    Introduction

    As a discipline, DevOps emphasizes uniting development and IT operations teams through modernized culture, integrated tooling and processes in order to increase the frequency, quality and business alignment of software roll-outs. But while developers and IT Ops teams need to be in lockstep, security cannot be an afterthought.  Rather, DevOps teams need to adapt to include security as an integral part of the agile triangle.

    The challenge facing DevOps teams today however is that incorporating security into their day-to-day work is not always easy or intuitive. Security often runs one step behind or out of sync with lean DevOps teams. In addition, the besieged security professional or team often faces a never-ending barrage of breaches, designed by a large, amorphous and highly motivated hacker ecosystem and resulting in a continually escalating threat environment. In an effort to save time, agile developers may leverage existing code in rapid iterations and quickly deploy them to production through continuous delivery pipelines, without considering existing architectural defects or knowing its defect profile and potential for security vulnerabilities. This can expose organizations to huge risks if left unassessed and mitigated.

    Fortunately, “security at the speed of agile” is entirely possible, allowing organizations to bring new software products and services to the market, while staying in control. Here are some best practices for better aligning security with DevOps objectives, evolving beyond just DevOps to DevOpsSec:

    Shifting security “left” in the DevOps chain

    Like functional quality testing (making sure an application works as it’s supposed to), security testing needs to happen in the earliest possible stages of the development process. Traditionally, the application lifecycle has followed a sequential model – ideation, development, testing and finally, production. Functional testing used to occur only during the testing phase. But now, developers are taking on more responsibility, which helps prevent defective code from getting “baked in” further down the application lifecycle, where it becomes much more time-consuming and costly to undo. However, security is also an extremely important part of the quality equation, and if a security defect isn’t detected early on, a very unpleasant surprise is likely in store as the application gets closer to production. Building in and continuously integrating static code analysis and dynamic security testing into the Agile application lifecycle is a key success factor to delivering a high quality, secure application experience in production.

    Automating security testing, for both developers and testers

    In agile environments, DevOps teams are under constant time pressures. As noted above, developers are expected to develop more and more code, all while assuming greater responsibility for functional quality. Testers, too, are under increased pressure as more frequent application roll-outs mean more testing, in less time. For these reasons, if security testing is going to take place earlier on in the application lifecycle, basic security tests need to be automated. Since security threats are constantly evolving, this kind of automation will not completely rule out all security flaws in production. But it will allow developers and testers to spend more time on their core functions – namely development and functional testing – while lowering the attack surface, once an application does reach production.

    Leveraging Big Data analytics 

    Data generated from DevOps processes and operations, particularly related to automated security tests, often hold a wealth of insights which can be used to step up security validation efforts throughout the application development lifecycle. For example, what code types show the most vulnerabilities and therefore may need more rigorous testing? Which groups of developers are discovering the most security holes in automated tests – such that their development processes may need to be refined — and which groups may not be testing enough? How long are basic security tests taking on average, and how does this need to be factored into roll-out timelines? This type of data can help DevOps teams prioritize and optimize their security testing, and better reconcile security testing requirements with velocity and resources to hit anticipated delivery dates. Also, while using Big Data analytics in production will always be useful (particularly when it comes to detecting new security threats, and determining new automated testing needs), applying Big Data analytics earlier on, to DevOps pre-production data, can prevent more security flaws from making it into production in the first place.

    Fostering a shared vision and objectives

    To date, real progress has been made uniting developers and IT operations teams together in DevOps organizations. Traditional roles and responsibilities within DevOps teams continue to evolve and coalesce, and that’s a good thing. Developers are contributing to testing and taking more responsibility for overall quality. IT ops teams are thinking like developers, analyzing and feeding production data back to developers and testers so they can fine-tune and modify their offerings. Data flows left-to-right, and right-to-left are becoming more automatic and continuous.

    But increasingly, security professionals need to be included in this mix. Developers need to think with security considerations in mind – for instance, will a new feature they want to add to an application bring increased security risk, and if so, how can this risk be minimized? Conversely, security professionals need to think like IT ops teams; for example, making sure a new mobile app doesn’t potentially create a hole for hackers to penetrate back-end systems, and if a hack were to happen, how to contain it and minimize the impact. Only by capturing the right data, communicating and committing to working together can everyone in the DevOpsSec chain make the best, most well-rounded decisions that factor in all concerns, with business success being the top priority.

    Conclusion

    Often, DevOps teams may view security teams as potential logjams preventing them from doing what they want to do – deliver working software quickly to delight users and create competitive edge. But if security in the software supply chain is not addressed, the results may do the exact opposite, frustrating users, freezing business processes or worse, causing massive financial liability and loss of brand goodwill.

    Security is a key ingredient of application quality. By addressing security earlier in the development process; increasing security testing automation; leveraging Big Data analytics and incorporating security in the DevOps mission, organizations can achieve true DevOpsSec and deliver applications that are high-quality, through and through.

    About the Author/ Kelly Emo

    Kelly-Emo- Director-Lifecycle-and-Quality-HP.jpgProduct MarketingKelly Emo, Director, Lifecycle and Quality Product Marketing, HP, Kelly has been involved in all things IT for few decades, including engineering, product management, and product marketing across application development, SOA and middleware, enterprise architecture, IT operations, quality and testing. She now focuses on application lifecycle management, quality, agile development and DevOps. She has worked in other organizations at HP, BEA Software, and Jamcracker Inc .Kelly has a BS in Computer Science from Cal Poly, San Luis Obispo and an MBA from Santa Clara University.
  • 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.

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