staging-devopsy.kinsta.cloud

Tag: secdevops

  • 7 Step Transformation Blueprint for SecDevOps

    7 Step Transformation Blueprint for SecDevOps

    The struggle for continuous software security is obvious, but the solutions are not.

    As I indicated in my prior blog, SecDevOps is the Solution to Cybersecurity, a security-first mindset, coupled with SecDevOps-specific practices, provides an opportunity to achieve true continuous security. But, in reality, how can an organization accomplish SecDevOps?

    This blog explains how to apply my 7 Step Transformation Blueprint to SecDevOps.

    Leadership and engineering solutions require the persistent, methodical application of skills and practices toward leading and designing solutions that achieve business and team goals, including continuous security. While driven by visionary ideals, engineering requires practical, disciplined, progressively refined implementations using carefully chosen dimensions of people, process and technology solutions. At any point in the engineering life cycle, the goal is to achieve a balanced solution while evolving practices towards maturity.

    The seven step transformation engineering blueprint prescribes seven steps for achieving and continuously refining digital transformation methodically, no matter what the goals or current level of maturity are. The seven steps are visioning, alignment, assessment, solution, realize, operationalize and expansion. Each step considers the people, process and technology aspects of the transformation.

    Step One – Visioning

    Top leaders define a strategic vision for the digital transformation for the organization including a motivating vision statement, measurable goals, team values, and major implementation tactics. Identify senior sponsors that will own the transformation at the strategic level. Include key partner organizations that need to be strategically aligned to the transformation. In a SecDevOps transformation, a vision for a security-first mindset and associated SecDevOps practices are called out as the highest priority for implementation tactics supporting the vision.

    Step Two – Alignment

    Leaders and key team members who are most important to the implementation of the transformation align specific measurable goals and tactics for selected “model” applications. Specific measurable goals around continuous security are set in this step.

    Step Three – Assessment

    For the current state of selected applications, capabilities are discovered and assessed, deep-dive assessments are conducted for specific topics, and a current state value stream map is created relative to the organization’s goals. My earlier blog, DevSecOps Practices Gap Assessment, explains my recommended approach for conducting an assessment for security.

    Step Four – Solution

    An expert team performs analysis of assessment data and formulates a future state value stream roadmap including themes, epics and user stories and obtains alignment with key stakeholders. My earlier blog, 9 Pillars of Continuous Security Best Practices, outlines a comprehensive set of practices to consider when building a roadmap for any continuous security solution.

    Step Five – Realize

    Proof of concept (POC) trials are conducted to validate solution choices. Trials of security tools and integrations of those tools into the SecDevOps platforms also would be conducted during this step. The solution is validated with selected applications and use cases. Training is conducted as the solution is deployed to production. Governance practices for the new solution are activated.

    Step Six – Operationalize

    Deployed improvements are monitored and controlled with metrics. Retrospectives are conducted to create actionable prioritized lessons learned for continuous improvement. Chris Tozzi’s article 6 DevSecOps Metrics for DevOps and Security Teams to Share suggested metrics that can be developed and leveraged, both for this step and to drive ongoing improvements as the use of SecDevOps practices expand.

    Step Seven – Expansion

    Once continuous flow (the first way of DevOps) is realized for a select set of applications, the organization can safely expand the solution(s) to other applications across the organization. Further transformation cycles will lead to realization of continuous feedback (the second way of DevOps) and continuous improvement (the third way of DevOps) and apply it to SecDevOps.

    What This Means

    SecDevOps strategies and solutions are complex. The seven step transformation blueprint described in this blog can help organizations build a strategy and implement SecDevOps as an important part of their digital transformation. To learn more about how to apply the blueprint to continuous security (and other key elements of digital transformation) refer to my book Engineering DevOps.

  • SecDevOps is the Solution to Cybersecurity

    SecDevOps is the Solution to Cybersecurity

    Anybody paying attention to world news will notice that the threats and risks perpetrated by cybercriminal actors, in many forms, is a serious problem on the rise, affecting individuals, organizations and nations daily. The cybersecurity threat space is indeed alarming and growing rapidly. The cybersecurity solution space is struggling to keep up. After all, there is no such thing as 100% security.

    What is the Solution to Cybersecurity’s Problem?

    In my opinion, the industry has long underestimated the problem of cybersecurity, which has resulted in solutions that do not sufficiently stand up to the cybersecurity threat space. What is clear is that solutions must come from rapid software changes that detect and plug security holes as fast as they are found, and continuously deploy innovative defensive solutions that keep bad actors off their guard. To do that requires Agile and DevOps continuous delivery practices coupled with a security-aware mindset.

    What is a Security Aware Mindset?

    To put things in perspective, it is useful to consider the mindsets of design, QA, operations and security.

    Design mindset – create a product or service that customers want, now. The Agile framework addresses this requirement.

    QA mindset – verify a product or service works the way customers expect it to, when it is released, for all production configurations available at the time of the release. The DevOps framework addresses this requirement.

    Ops mindset – ensure a product or service continues to work the way customers expect, for all production configurations, for the life of the product or service. The site reliability engineering (SRE) and ITIL frameworks address this requirement.

    Security mindset – defend valuables for organizations that create or use a product or service against unintended and malicious actions, by people and organizations, both inside and outside of the organizations, for all production and non-production configurations, for as long as there is something of value to protect. The DevSecOps framework was created to address this requirement; as we have seen, this does not yet offer sufficient safeguards for the growing cybersecurity threat problems.

    The security mindset has multiple additional vectors of thought required compared to the design, QA and ops mindset. This helps us to understand why the cybersecurity problem space is bigger and requires more comprehensive solutions.

    Not long ago I considered security assurance to be a subset of testing practices. In 2016, in my blog, “Seven Pillars of DevOps – Essential Foundations for Enterprise Success“, I did not break out security as a separate pillar. At that time, this type of thinking was typical of developers. Security was someone else’s job. Perimeter defenses were deemed sufficient.

    Soon after, I realized that way of thinking was naïve on my part. By the time that I co-authored a subsequent blog, “Nine Pillars of Continuous Security Best Practices,” I added a separate pillar for security specific practices, and also added security practices within each of the other pillars.

    In parallel, DevSecOps became a thing in the DevOps world. The idea of integrating security practices into DevOps makes a lot of sense, because DevOps is the answer to continuous delivery of software, and security needs continuous delivery of defensive solutions. However, simply adding security to DevOps is not a sufficient solution, because DevOps was conceived to address specific problems associated with design, QA and Ops – not security. Simply adding security as another metric for releases is not enough. What is needed is a re-think of how DevOps can be used to deliver continuous security, as indicated in my book, “Engineering DevOps.” This is the same idea behind what is referred to as SecDevOps.

    In my opinion, it is now time for SecDevOps to gain favor over DevSecOps when it comes to integrating security practices with DevOps practices. This represents a much more significant shift than simply putting security first in the name. With SecDevOps, security concerns within the entire development organization and at every stage in the DevOps value stream, are explicitly prioritized over other types of concerns. This makes sense, given the much wider blast radius of security events versus other quality concerns that DevOps was originally designed to address.

    With SecDevOps, security tools and resources are weighted at the highest priority level. SecDevOps and secure coding practices are required training for application developers. Threat modeling is part of the value stream. Security tasks that are required to mitigate security risks are given the highest priority in backlog planning. At each stage in the DevOps pipeline, security concerns rise to the top of the priority list. Release and deployment readiness are weighted at the highest level. In short, SecDevOps explicitly plugs some important security holes that are not covered by DevSecOps. With SecDevOps, security becomes continuous, not just an add-on to DevOps.

    What This Means

    By explicitly plugging some important security holes that are not covered by DevOps or DevSecOps practices alone, it makes sense for SecDevOps to now emerge as the preferred framework to close the gaps between the growing security problem space with the evolving security solution space. SecDevOps offers the required security-first mindset and solves the need for rapid software changes that detect and plug security holes as fast as they are found, and continuously deploys innovative defensive solutions to keep bad actors off their guard.

  • Are We Leaving Developers Out of DevOps Spinoffs?

    Are We Leaving Developers Out of DevOps Spinoffs?

    SecOps. DataOps. NetOps. Reading these terms, you get the sense that the key to IT efficiency is to make IT Ops work with everyone else. But that’s a mistake, because it leaves developers out of the picture.

    It’s no secret that the DevOps movement has generated a number of other *Ops initiatives, including those listed above. The driving idea behind all of them is that IT Ops teams should work more closely with security teams (in the case of SecOps), data analytics teams (in the case of DataOps) or networking teams (in the case of NetOps). These are only a sampling of *Ops movements; the list could go on.

    To be sure, there are advantages to gain by having IT Ops collaborate more closely with other parts of the organization. But there are an equal number of advantages in doing the same thing with developers.

    To optimize security operations, you need developers, IT Ops and the security team to work together. If Dev is left out of the picture, it’s much harder for the other two parts of this equation to make sure that the code the organization deploys and manages is secure.

    For similar reasons, DataOps, NetOps and almost all the other *Ops you can come up with work well only when Dev also participates. The people who actually design and write the applications are important.

    Rethinking Ops

    Why does this matter? My point is not merely that terms like SecOps and DataOps are misleading because they don’t mention developers.

    On the contrary, giving equal weight to developers is important because if you don’t, you risk isolating developers. Some are already complaining that DevOps is “killing” them. The trend of defining new *Ops practices that don’t mention developers is not helping.

    So, maybe we should start mentioning and thinking about developers more prominently when we are talking about ways to extend the DevOps philosophy to other parts of the IT organization. This is already being done somewhat in the case of SecOps, which you sometimes hear called SecDevOps. But Google lists nearly 13.5 times as many results for “SecOps” as for “SecDevOps.” The numbers are similar if you search for “NetOps” as compared to “NetDevOps.” And I’ve never heard anyone say “DataDevOps.”

    The takeaway is this: Developers are as important as IT Ops to DevOps. Don’t leave them out.

    — Chris Tozzi

  • Murphy’s DevOps: Is Security Causing Things to Go Wrong?

    Murphy’s DevOps: Is Security Causing Things to Go Wrong?

    “Rugged DevOps,” “DevSecOps”—am I missing any? About the only thing more abundant than the volume of terms emerging to describe different facets of how security supports DevOps are the number of vendors now claiming to provide products and services that “solve” related security problems.

    There have been some interesting offerings we’ve seen emerge at this point and most of them probably have merit, in that they likely can accomplish the job they claim to do. Regardless of whether that “job” is actually something that needs to be done to solve a DevOps-related security issue, that is something for the professionals in the developer, operations and security worlds to determine—and hopefully something they will be interested in discussing here.

    This new column’s point is to go looking for problems and solutions. Specifically, it’s focused on how and if DevOps is causing things to go wrong in security (and from time to time in other spots) and what DevOps-focused organizations are doing to correct course.

    Security Questions to Ponder

    Is it true that security can’t keep pace with “continuous?” Will “agile” and security always be oil and water? Will DevOps and security never achieve a harmonious “peanut butter and chocolate”-like relationship? Or, is the talk about how DevOps is the best thing that has ever happened to security and a great opportunity, actually the new reality?

    Another great question this column seeks to answer is whether any of the “so-called” security problems DevOps is creating are anything new, or if they are the same old challenges that have existed since the first bit of sensitive data was exposed to the Internet decades ago.

    There are times when I may mention specific vendor solutions in this column, but only if an actual end user or practitioner is attached to the reference. If that happens, I will always point out if any are clients of mine at my day job.

    It’s no coincidence that this column is being launched just ahead of RSA 2016, as DevOps Connect: Rugged DevOps @ RSA Conference is a major part of the big show, and, that is where the world will be talking DevOps and security after all. Here’s hoping the event will expose problems and provide solutions.

  • Flash Mob Inflection: Rugged DevOps Revolution

    Flash Mob Inflection: Rugged DevOps Revolution

    Truthfully, I was never a huge fan of the HBO series “The Sopranos.” It’s not that it wasn’t entertaining; I just didn’t agree with the “best ever” label that so many espoused during the show’s halcyon days.

    This had something to do with living in Hoboken, N.J., at the time and feeling the show was a heavily glamorized caricature of the real-life Mafioso I still perceived to be in my midst. More specifically, it’s hard for anything mob-related to stand up next to “Goodfellas” and “The Godfather”—among my favorite films, ever.

    Either way, I currently find myself identifying with the series’ defining sentiment (copped directly from The Godfather, but hammered home as The Sopranos main theme): “Just when I thought I was out … they pull me back in.”

    It wasn’t that I assumed that I’d never delve back into the domain of IT security after transitioning into the DevOps market last year; leveraging DevOps methodologies to improve security, policy compliance and related workflows stands as a core element of the overall movement.

    But, in recent months and weeks it has become increasingly obvious that the security facet of the larger DevOps revolution appears poised for explosion as the buzz around emerging best practices, business models and solutions providers grows from a low hum into a steady roar.

    After spending a few days talking DevOps security with Derek Weeks of Sonatype at CA World ’15 (we were booth neighbors and dinner mates) and giving more consideration to his company’s angle on securing the systems development life cycle (SDLC) supply chain, the internal gears really got spinning.

    Regardless of whether you buy into Sonatype’s security-heavy approach, the concept of aggressively and proactively addressing security across the DevOps spectrum makes infinite sense. The ultimate downfall of applications security has always been the challenge of securing all the underlying layers of code (and today, microservices), especially as applications are assembled using heavier doses of shared, open source componentry.

    As further evidence, nearly every major solutions vendor focused on the DevOps space—whether oriented toward the vibrant application performance management (APM), configuration management and continuous testing segments, among many others—seems to have launched some initiative aimed at integrating security into their products.

    The rise of security capabilities adjacent to—and supporting inclusion into—the DevOps world, such as container giant Docker’s Content Trust initiative, along with the advancement of related startups including Twistlock, Scalock and StackRoxs, offers more proof of this growing momentum. And that’s only the container security piece of the puzzle.

    Of course, there are also a number of emerging startups aimed at addressing the DevOps security opportunity, backed by well-known venture capitalists. A shortlist might include providers such as Immunio, Prevoty and UpGuard (formerly known as ScriptRock, which recently rebranded itself under the guise of a “DevOps security” provider), and we’re sure to see many more. And don’t forget the growing emphasis on DevOps security among established security industry stalwarts such as CyberArk, Snort and Tripwire, among others.

    For a comprehensive list of the various types of DevOps security best practices and tools that we should expect to see gain wider adoption, this October 2015 blog by noted security analyst Adrian Lane of Securosis serves as a basic framework. Each of the areas of focus that he cites clearly offers significant opportunity for both new and existing methodologies.

    Finally, one need look no further than this year’s RSA Security Conference, to be held in San Francisco at this end of this month, as tacit proof of the continued growth of what people now varyingly refer to as DevSecOps or Rugged DevOps (I prefer the latter as it just sounds cooler).

    In addition to multiple conference sessions, notably a “DevOps Throwdown” between security industry veterans Caleb Sima, Chris Wysopal and Gary McGraw, there’s also the 2nd Annual DevOps Connect: Rugged DevOps Edition. If last year’s event is any indication (standing room only, venue literally at max capacity), this daylong DevOps security track at RSA will be an even more high-profile element of the entire week.

    Further, if DevOps security—or, at the very least, the growing focus on adjacent segments such as container security—isn’t the unofficial theme of this year’s entire RSA show, I’d be extremely surprised.

    Meanwhile (self-serving), my employer CA Technologies absolutely has a lot going on that complements and contributes to this growing DevOps Security market momentum.

    For all of those reasons, here I find myself again, drawn closer back into the security space that I’ve called home for roughly the last decade. I guess that’s just how it goes, as DevOps and security are inarguably two of the most significant trends in IT these days and inextricably linked at their respective cores.

    There are definitely worse fates out there. But, just when you think you’re out …

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

  • It’s time security pros shake their DevOps fear, uncertainly, and doubt

    It’s time security pros shake their DevOps fear, uncertainly, and doubt

    There’s been considerable discussion recently about how to make certain good security practices remain integrated within DevOps-driven environments. To get the scoop from a security pro who is experienced working on delivering security programs in development environments, I turned to Andrew Storms for some insight. Storms has been leading IT, security and compliance teams for the past 20 years and his multidisciplinary background includes product management, quality assurance, and software engineering.

    Storms is also a CISSP, a member of Infragard, and a graduate of the FBI Citizens’ Academy. Currently, Storms is vice president of security services at New Context. Previously, he was the senior director of DevOps for CloudPassage and the director of security operations for nCircle (acquired by Tripwire). At nCircle, he was responsible for the definition and enforcement of the security programs, delivering EAL3 certification and SOC2 audits, and managed the company’s PCI ASV program.

    Storms recently gave a talk at the RSA Conference, How Security Can Be the Next Force Multiplier in DevOps, where he shared his thoughts on how security teams should integrate themselves as business enablers within fast-paced DevOps enterprises.

     

    staging-devopsy.kinsta.cloud: What’s your take on DevOps being a force multiplier and enhancing security?

    Storms: Much of it [the concern around DevOps] really is rooted in fear. People see that the organization has brought together the developer and the operations team and they fear that everything will become the Wild West. However, we’ve shown over and over through the years that bringing these teams together actually has huge positive impact.

    Unfortunately, too many people in security view it differently. They think that they’ve lost control of a situation that they barely had control over to begin with.

     

    staging-devopsy.kinsta.cloud: What are the best approaches for integrating security with DevOps?

    Storms: There are two approaches to this. One of the best ways to bring DevOps and security together is to utilize the tools and the processes that DevOps really excels at and apply them to security – things like automation, orchestration, and instrumentation. Let’s use those tools to build these closed-loop security systems where everything’s automated and everything’s predictable. That’s a way we actually can fulfill the security requirements in an automated fashion with fewer resources.

    Another is to treat security more as an enabler. Security has fallen into the pitfall that, instead of being an enabler to the organization, it is all about ‘No.’ There’s pushback on new initiatives for fear of falling out of regulatory compliance, or being breached. Instead, the organization needs to take a different approach. It should view security as a business enabler, just like IT and operations.

    In this way, it can secure new initiatives and actually enable people to focus on their core competencies and allow the company to take educated risks. At the end of the day, that helps to provide more of what the business needs to do, whether that is increase revenue or decrease time to market, or whatever it may be that the company needs.

     

    staging-devopsy.kinsta.cloud: Done right, people say that security needs to be integrated throughout all of the processes, but that’s seldom reality. What do you say to security teams about this?

    Storms: That’s the approach that I take here with the integration of DevOps and security. Really, if we think about it, the integration of Dev and Ops together in DevOps has actually opened the door for security to come in and do something very similar – to come in and work more collaboratively and integrate itself more closely with the rest of IT.

    What security professionals need to recognize here, but often don’t, is that DevOps is an opening. Take it. That is to say: Don’t fear DevOps; embrace it. Address the fear, and then learn about DevOps, and see where you can integrate security people, processes, and technology.

     

    staging-devopsy.kinsta.cloud: When integrating the people, processes, and technologies that help forward security interests in DevOps, I imagine it takes time and effort to go back and review a lot of those controls, to make sure that they’re up to speed with the way people actually work today.

    Storms: I think that’s one aspect. I think the other aspect is, if we look at the manifest of Agile, which is the ability to take and see change and adapt, all of those controls, to some degree, still make sense. They just need to be adapted to the modern way that code is developed.

    One of the great examples I like to share is a health care company I worked with. It is deep into continuous deployment but has all kinds of compliance requirements. So, it can’t just centrally deploy code at any time it wants without all the compliance check-offs that have to happen.

    It has to run application security and compliance checks. So, it automated them, to the point where the auditors are happy. When their code gets pulled in to master, it runs it through many types of integration and security tests.

     

    staging-devopsy.kinsta.cloud: What happens if there is an issue; how is it resolved?

    Storms: The company has put in automated checks. Think of it as kind of a speed bump; for example, when an event happens, there’s a message that is sent to the chat room [See: ChatOps, Communicating at the Speed of DevOps], and there’s a Hubot that watches the messages. The Hubot has logic that says, right before they’re ready to go, you need to stop and alert the chat room that this event needs to happen, and it needs N number of people to approve it.

    For example, it may require that there be a product manager, there must be a security manager, there must be an ops manager, and so on. And they’ve got logic in there that says if the right number of people in the chat room all respond with a keyword – let’s just call it “yes” – then let’s actually capture all of that, enter a log message to go ahead and approve the release, and push it out automatically.

    If an issue is found in the tests or in the approval processes, then it has to be resolved, and is then moved forward along the pipeline.

    With this continuous pipeline, the company actually has all of the steps, all the compliance requirements, and the audit log. Thus, it still can maintain compliance requirements, and security. That’s what DevOps and security should be all about.

  • DevOps Security Talks At RSA USA 2015 Conference

    DevOps Security Talks At RSA USA 2015 Conference

    DevOps and security. Its a muddled mix of waters made even more confusing by the wet ink still on the concept of DevOps. There is no denying the popularity of DevOps and there is a lot of talk on how the DevOps movement functions alongside security teams.

    The annual USA RSA conference is just around the corner and its worth noting a handful of DevOps focused talks deserving of your attention.

    I am anticipating a lot of common themes around integrating DevOps and Security regarding tools, processes and culture. Given the history of these speakers, you can probably anticipate many of them to be on the bandwagon of security and DevOps folks better learn to work together and learn from each other or be prepared to find a new job.

    If I missed a talk that specifically covers the nexus of DevOps and Security at RSA USA this year, please leave a comment and I’ll be sure to get it included.

     

  • Complete speakers & schedule for DevOps Connect: SecDevOps @RSAC

    Complete speakers & schedule for DevOps Connect: SecDevOps @RSAC

    The line up for DevOps Connect: SecDevOps @ RSAC is complete.  What a great job Gene Kim and Josh Corman did lining up a power-packed schedule.  Here is what the day is shaping up to be include:

    8:50 to 9:00am     Alan Shimel and Mark Miller – Opening remarks and welcome
    9:00 to 9:50am Gene Kim/Josh Corman – Rugged DevOps: Going Even Faster With Software Supply Chains
    9:50 to 10:30am David Mortman – DevOps Myths Versus Real World Realities

    10:30 to 10:45am Bio and email break

    10:45 to 11:20am Julie Tsai – Windfall Wins: DevOps Empowers Agile Security and Compliance
    11:20 to 11:55am Jez Humble – Continuous Delivery

    noon to 1:30pm lunch break


    AFTERNOON SESSIONS (ROOM 1)
    1:30 to 2:00pm Constantine Cois – DevOpsSecFail: DevOps Security Anti Patterns
    2:10 to 2:40pm Terri Potts – Leading a Horse to Water and Enticing Him to Drink
    2:50 to 3:20pm Nick Galbreath – BYOD: Bring Your Own Dependencies
    3:30 to 4:00pm Jessica Devita – No White Boards Allowed
    4:10 to 4:50pm Rich Mogull – Building Your SecDevOps Toolkit

    AFTERNOON SESSIONS (ROOM 2)

    1:30 to 2:00pm Dan Cornell and Chris Curlyo – Blending the Automated and the Manual: Making Application Vulnerability Management Your Ally
    2:10 to 2:40pm Damon Edwards and Alex Honor – Coaches and Toolsmiths
    2:50 to 3:20pm Dan Cundiff – Why DevOps != the Wild West and How Embracing it Can Improve Security
    3:30 to 4:00pm Chris Corriere – Automating Enterprise Security
    4:10 to 4:50pm Chris Walsh – I’m the New Security lead, and I’m Here to Help

    Pre-registration for the event is already sold out, but seating is on a first come, first serve basis and open to all RSA badge holders.  So Monday of RSA Conference week, April 20th, Moscone Center West, room 2018. Come be part of a great day of DevOps and Security!