staging-devopsy.kinsta.cloud

Tag: rugged devops

  • 9 Pillars of Continuous Security Best Practices

    9 Pillars of Continuous Security Best Practices

    Without proper consideration given to security best practices, the continuous delivery of software changes facilitated by DevOps is risky. On the other hand, DevOps provides an opportunity to reduce security risks if security is integrated into the continuous delivery pipeline according to best practices.

    This blog enumerates best practices for security across nine pillars of DevOps: Leadership, Collaborative Culture, Design for DevOps, Continuous Integration, Continuous Testing, Continuous Monitoring, Elastic Infrastructure, Continuous Delivery/Deployment and Continuous Security. Examples of best practices for each pillar are listed. These practices can be used to assess an organization’s maturity within the journey to Continuous Security, often referred to as DevSecOps.

    Leadership

    Leaders need to understand and sponsor a clear vision for security.

    • Leadership demonstrates a vision for organizational direction, team direction and three-year horizon including security practices.
    • Leaders intellectually stimulate the team status quo by encouraging asking new questions and question the basic assumptions about the work including security practices.
    • Leaders promote personal recognition by commending teams for better-than-average work, acknowledging improvements in the quality of work and personally compliment individuals’ outstanding work including security practices.

    Collaborative Culture

    Culture in organizations that work well with DevOps have a collaborative continuous security mindset.

    • The culture encourages cross-functional collaboration, shared responsibilities and avoids silos between developers, operations, project management, quality assurance and security.
    • The DevOps system (toolchain) is created by an expert team and reviewed by a coalition of stakeholders including security.
    • Changes to end-to-end DevOps workflows are led by an expert team and reviewed by a coalition of stakeholders including security.
    • DevOps culture empowers and trains team members to take personal responsibility for security, compliance and privacy obligations.
    • Security engineers/architects are involved in the design for modular components, and also consulted when security patterns change within modules.

    Design for DevOps

    Designing software for DevOps at speed requires application designers to master the best practices for continuous security.

    • Software source code changes are pre-checked with static analysis tools, prior to commit to the integration branch. This assures that the modified source code does not introduce critical software faults and security vulnerabilities such as memory leaks, uninitialized variables, array-boundary problems and SQL injection.
    • Software component analysis scans third-party components for known security vulnerabilities and identifies risk during the build process.
    • Security frameworks for technology stacks that are used (such as Apache Shiro or Spring Security) are documented and shared with developers for their respective technology stacks.
    • Software code changes peer code reviews include checks for defensive coding and security vulnerabilities prior to committing code to the integration/trunk branch.
    • Common security components such as identity, authorization, key management, audit/log, cryptography, protocols, etc. are maintained, published, readily available and used within module development.

    Continuous Integration

    Continuous integration (CI) within organizations that have multiple teams working concurrently on a project and different code bases is challenging. During the integration stage it is critical to assess the application and understand the impact of code changes from a security point of view.

    • A software version management system is used to manage versions of all changes to source code, executable images and tools used to create and test the software.
    • Incremental static analysis pre-commit and commit checks are wired into CI to catch common mistakes and anti-patterns quickly by only scanning the code that was changed. These checks identify security vulnerabilities through control flow and data flow analysis, pattern analysis and other techniques. These techniques find security-related issues such as mistakes in using crypto functions, configuration errors and potential injection vulnerabilities.
    • Binary artifacts are digitally signed and stored in secure repositories.
    • Changes to security patterns used within software source such as session management, authentication, authorization and encryption code trigger a notification or pull request to security engineers.

    Continuous Testing

    Continuous testing (CT) with DevOps has significant advantages for continuous security when best practices are followed.

    • New security tests that are necessary to test a software change are created together with the code and integrated into the trunk branch at the same time the code is. The new tests are then used to test the code after integration.
    • Security tests for each DevOps pipeline stage are automated and may be selected automatically according predefined criteria.
    • Release regression tests include security tests. At least 85 percent of the security regression tests are fully automated and the remaining are auto-assisted if portions must be performed manually.
    • Test results that indicate possible security concerns are tagged for security analysis.
    • Dynamic or interactive application security tests exercise the application for security vulnerabilities. Results of these tests are delivered to developers through tools and feedback loops native to their organization.
    • If containers are used, image repositories are scanned for images with known vulnerabilities, hash checks for image drifts and run-time checks for vulnerabilities during image deploys.
    • Attack patterns, abuse cases and tests are built for application module profiles.
    • Unit, functional and integration tests around—and especially outside—boundary conditions are run during CT. Tests include error handling, exception handling logic and negative tests.
    • Automated security attack testing to include the OWASP Top 10 in integrated into automated testing.

    Continuous Monitoring

    Continuous monitoring (CM) of security considers the dynamic nature of artifacts and infrastructure and a proliferation of objects and services to secure.

    • Metrics and thresholds are automatically gathered, calculated and made visible to anyone on the team that subscribes to them. Example security metrics include:
      • Number of security defects identified pre-production
      • Percent of code coverage from security testing
      • Number of failed builds due to security checks
      • Mean time to detection
      • Mean time to resolution
    • Vulnerability information in consolidated to provide a comprehensive view into vulnerability risks and remediation across tools, pipelines and apps—and over time.
    • Metrics and events from production security controls such as WAF, RASP, etc., are used to improve security testing.
    • Insight into security threats and events are shared and visible across DevOps teams to enable “attack-driven defense” methodologies.

    Continuous Security

    Continuous security (CS) is itself a distinct pillar with standalone best practices that cross all of the other pillars.

    • All information security platforms that are in use expose full functionality via APIs.
    • Immutable infrastructure mindsets are adopted to ensure production systems are locked down.
    • Security controls are automated so as not to impede DevOps agility.
    • Security tools are integrated into the CI/CD pipeline.
    • Source code for key intellectual property on build or test machines are only accessible by trusted users with credentials. Build and test scripts do not contain credentials to any system that has intellectual property.
    • External penetration tests (done out of band) are scheduled either periodically or on a regular cadence are used to perform deep-dive analysis.
    • Telemetry from production security controls such as WAF and RASP are delivered back to development teams to inform application updates.
    • Accurate inventory of all software packages and version information is documented via infrastructure as code. Automated detection is used to identify whether any of the packages have known CVEs associated and define specific remediation actions.

    Elastic Infrastructure

    Elastic infrastructure environments offer advantages compared to legacy or traditional static infrastructure. However, elastic infrastructures need to follow best practices for continuous security because flexible infrastructures offer a broader range of attack surfaces.

    • Configuration code includes automated checks including:
      • Ensuring unnecessary services are disabled and only ports that need to be open are.
      • Permissions on files, audit and logging policies are enforced.
      • Development tools are not installed on production.
    • Security-approved OS, software versions and frameworks are used to compose required infrastructure. Security-related controls such as ACLs and FIM are defined as a part of infrastructure where applicable.
    • A least-privilege model is enforced for processes running on shared infrastructure.
    • Smaller clusters are used to reduce complexity between teams.
    • Service provider partners security controls are validated to ensure they meet business requirements in their domains of the shared security model.
    • IaaS or PaaS service provider security controls are validated to ensure that they meet business requirements in their domains of the shared security model.

    Continuous Delivery/Deployment

    While DevOps enables new feature deliveries to users quickly, to minimize risk during deployment the following best practices are important:

    • Release-to-production decisions are determined according to predetermined metrics, which include security metrics.
    • A whitelist policy for application segmentation is enforced during deployment for each environment, especially production.
    • Continuous deployment processes trigger run-time security and compliance checks including:
      • Ensuring unnecessary services are disabled and only ports that need to be open are.
      • Permissions on files, audit and logging policies are enforced.
      • Verify development tools are not installed on production.
    • All secrets used for deployment are vaulted and retrieved programmatically during run-time or initialization of the continuous delivery process.

    In this article we detailed best practices for nine pillars of continuous security, otherwise known as DevSecOps. While is it clear that DevOps offers immense value for software deployment, the adherence to best practices is essential to reduce risk and assure security. Each organization is different and has different security postures. The specific practices, security tools and metrics that are appropriate may vary according to a risk assessment for each organization.

    Aggregation of end-to-end security metrics, from planning through to operations, is important but beyond the scope of this blog. End-to-end security monitoring tools, such as value stream management applied to DevSecOps and enterprise security dashboards, is a topic that we intend to cover in a subsequent blog.

    This article was co-authored by Imran Chaudhari. Imran is a principal security consultant at Trace3, where he assists clients in assessing and designing cybersecurity initiatives from a strategic, organizational, and technical perspective. His experience covers expertise in secure software development, application and cloud security, as well as identity and access management and DevSecOps assessments.

    — Marc Hornbeek

  • Integrating Security into DevOps: The Benefits and Drawbacks

    Integrating Security into DevOps: The Benefits and Drawbacks

    The efficiency of DevOps for your enterprise will depend on the level of security you integrate in it. The integration of security into DevOps is new to many enterprises, but is highly important because the speed of DevOps can make the apps in development vulnerable to malicious attacks. This can be prevented with the help of right security controls.

    Security and development teams must understand each other’s requirements and goals. Some might view security professionals as the ones who tap the brakes as the DevOps team moves forward. However, the job of security is to manage the risk effectively. To accomplish this, the security team must be integrated into the DevOps process.

    In many companies, this is a completely new methodology, and different structures are needed for different companies. The global security function is a component of the program management ecosystem by one security model. Security is integrated as an essential member of the development organization by another security model.

    Blockchain is the underlying technology behind cryptocurrencies such as Bitcoin and is used to secure the bitcoin wallet. The implementation of blockchain in a company’s DevOps process increases its agility and delivery efficiency, while the integration of security benefits an organization’s DevOps process in multiple ways. However, along with these benefits, few drawbacks do exist. Let’s dig deeper into both of them.

    The Benefits and Drawbacks of Integrating Security into the Program Management Ecosystem

    The program management function has a significant role to play in this model. It ensures that security is in place, and confirms that all the required specifications are documented and met. Security then carries out evaluations and determines what critical issues need to be addressed. In this security model, the security office can address the condition of a wide range of products that the organization delivers in a uniform manner.

    The drawback is that the issues related to security often are listed on a slide for review by executives and noted by the most important person in the development organization. Consequently, the list becomes a road map for “what we must fix” more than a prescription for “what we must make sure the product sticks to before it gets shipped.”

    The Benefits and Drawbacks of Integrating Security into the Dev Organization

    If the security team is a component of the development organization, they must maintain close contact with the global security office. But they can be much closer to the product development. This means they are closely working with feature teams and determining stories that should be planned into the sprints.

    These assessments cannot wait until the end—they must be planned into the first sprint that makes sense. Then, the resulting group of issues becomes technical backlog to prioritize into the following sprints. The goal is to produce applications that are safe for customers and have assessments that are known and can hold up to customer audit.

    However, the local security team must connect strongly to the global security office. Every security team that is a component of the development organization must rise to act as a single brain across all the products; companies cannot have any variance with respect to adherence to mandates, assessments, tools and standards.

    Where to Incorporate Security?

    To enable a continuous security mindset, security must be covered by automated test cases related to security in the continuous deployment/continuous integration process over the following phases:

    • Regular operations – near-real-time automated enforcement and utilization of continuous monitoring.
    • Integration phase – full sanity checks for external/internal endpoints, and make sure any new workloads do not break any of the security policies.
    • Infrastructure creation phase – test utilizing tooling such as serverspec/rspec.
    • Image creation and hardening – as part of the delivery pipeline, automate this phase.
    • Build phase – utilize code analysis.

    Securing QE and Dev Labs

    The final dimension is quality engineering (QE) and development, though they might be forgotten. Both of them have labs in which they make sure all the functionality performs, scales and works. These labs are good targets for intrusion, and security has a major role in the remediation and evaluation of the lab environment.

    Conclusion

    Adopting a DevOps methodology can instigate security vulnerabilities and new blind spots introduced by new systems. But fewer workplace silos and improved communication can help address issues much quicker. Today, security also can be integrated into DevOps using various technologies. It is highly essential to have security integrated into the process, no matter what method works best for your company.

    — savaramravindra

  • Barracuda Networks Advances DevSecOps Agenda

    Barracuda Networks Advances DevSecOps Agenda

    Thanks to the rise of DevOps, a fundamental shift is now underway in terms of the amount of influence developers exercise across the enterprise. Rather than simply dumping code on IT operations teams, developers increasingly are being held accountable for applications end to end. As such, developers now often exercise a lot more influence over which software-defined infrastructure and security platforms will be employed as part of what is referred to as the “shift to the left.” These platforms all have in common a well-defined set of application programming interfaces (APIs) that makes them accessible to developers.

    Against that backdrop, Barracuda Networks announced its Barracuda NextGen Firewall can be configured via the IT automation framework developed by Puppet Labs. Previously, only the company’s Web Application Firewall was integrated with the Puppet framework.

    In addition, the Barracuda NextGen Firewall is now available as a metered billing service in the Amazon Web Services (AWS) Marketplace. That marks the company’s second metered billing service on AWS, after making a similar move with the Barracuda Web Application Firewall last year.

    Tim Jefferson, vice president of public cloud, says an increased focus on application security is driving an expansion of DevOps processes to now include DevSecOps driven by APIs rather than traditional user interfaces, which are not well-received.

    Jefferson says those REST APIs are critical for any security company that wants to stay relevant as organizations start to manage multiple development pipelines that are tied into a common continuous integration/continuous development (CI/CD) pipeline. In that context, Jefferson says it’s no longer sufficient for IT security companies to make their offerings available as a virtual appliance. Security tools such as firewalls need to be just another cloud-native application that can be orchestrated as part of a CI/CD process, he says.

    What’s more, DevOps teams have made it clear they want to be able to consume anything deployed on a public cloud in the same manner they consume compute and storage resources. That requirement is driving companies such as Barracuda Networks to add a metered billing option because many organizations in the age of the cloud don’t want to pay for a firewall unless it’s actually in use, says Jefferson.

    It’s too early to say precisely how DevOps and DevSecOps are transforming the way IT products and services are acquired and invoked. In the case of Barracuda Networks, for example, the company is taking the rise of DevOps as opportunity to expand its portfolio of products first to include data protection by acquiring Intronis and then, more recently, compliance and archiving tools by acquiring Sonian.

    Naturally, not every IT organization is equally far down the DevOps and DevSecOps path. But the various walls that have isolated various segments of IT are finally starting to come down at an increasingly rapid pace across the enterprise.

    — Mike Vizard

  • DevOps, Security, AI Convergence on Horizon

    DevOps, Security, AI Convergence on Horizon

    DevOps is regarded as practice that can drive performance advantages. Artificial intelligence is showing very real promise across the security market. Most public and private-sector organizations know that they must explore new and different ways of defending their networks against modern threats. These three factors make it clear that DevOps, AI and security are ripe for convergence.

    Defining AI

    Anyone reading this post doesn’t need me to explain to them what DevOps and security are; both of these categories are well-defined. However, AI is really in an emergent stage, with different types in use and many definitions floating around. Because of this, I think it is important to let readers know that in this post, AI refers to a class of technology that can:

    • Consume data, learn and get smarter on its own
    • Automatically identify and solve problems
    • Operate independently, without human supervision
    • Scale massively
    • Move at near real-time speed
    • Achieve levels of accuracy that are beyond human capabilities

    DevOps and Security are United

    DevOps and security have merged. For several years now, organizations have been leveraging automation technologies and DevOps practices to continuously deliver security and compliance policies across data centers and clouds.

    Further legitimizing the union is the fact that leading DevOps and automation players such as Puppet, Chef and Ansible have formed numerous partnerships that deliver effective security capabilities to their customers.

    There are, of course, other signs that show how successful the DevOps and security marriage has been. One of which is the emergence of the term “rugged DevOps.” It is now so widely recognized that it commands its own section on this site and is often the subject of discussion at several notable security conferences.  

    DevOps and AI are Dating

    The relationship between DevOps and AI is in the early stages, with the courtship between the two well underway. Examples of its progress are found in numerous blogs and articles, several of which include:

    DevOps and AI have certainly not yet intertwined as deeply as DevOps and security have. These examples (and others out there) do show they the two will continue to integrate beyond what we are currently witnessing.

    DevOps, Security and AI

    DevOps and security are wed. DevOps and AI are moving closer toward each other. It’s only a matter of time until all three get together.

    Because several DevOps leaders are already in the business of security, it’s logical to assume that a partnership between one of them and an AI-driven security provider will be what ultimately leads to a marketable solution.

    DevOps provider candidates with the potential to move on a partnership that can combine DevOps, security and AI have a raft of new and established security providers available to work with. Several of the startups in this class are recognized in the CB Insights AI 100 2017 infographic. Companies such as Cloudera (NYSE: CLDR), which is using AI and machine learning to solve security problems, are among the more established providers that may make for a perfect partner. 

    How quickly will the market see such a partnership? That remains to be seen. However, with DevOps now fully accepted as a methodology that can positively impact bottom lines, AI coming into its own, and the need for new and different ways of defending organizations against attacks at a critical stage, it seems almost certain that the convergence will be upon us sooner rather than later.

    — Joe Franscella

  • Study: Half of Enterprises Have Achieved DevSecOps

    Study: Half of Enterprises Have Achieved DevSecOps

    The inclusion of IT security into DevOps processes, also known as DevSecOps, appears to be occurring at an accelerated rate. A new survey of 300 enterprise IT organizations published this week by DigCert, a provider of identity management and encryption software, finds that almost half (49 percent) of the respondents says they have completed DevSecOps, while another 49 percent say they are already working on it.

    In terms of overall impact, however, only 22 percent say they are doing well in terms of achieving and maintaining higher levels of security.

    In addition, those that have achieved DevSecOps say it took them anywhere from 12 to 14 months to make the transition. Those that have not completed the transition are estimating it will take them seven to 11 months. Based on the experience of the organizations that have completed the transition, there would appear to be a natural tendency to underestimate how much the cultural difference between developers and IT security teams can negatively impact integration objectives.

    Jason Sabin, chief security officer (CSO) for DigiCert, says that while many organizations may have brought IT security professionals into the process, an increase in the overall security of applications being built requires more time and patience, says Sabin.

    DigiCert recommends IT organizations identify an IT security champion within a DevOps process and automate the implementation of IT security controls as much as possible. Those moves can help lower developer cultural resistance to having to spend time on what often are considered mundane programming issues.

    It’s worth noting that most IT security professionals don’t have much in the way of programming skills. They can secure an application using any number of platforms that have a management console. But understanding how to employ APIs to help plug security holes before an application gets deployed is beyond the capabilities of most IT security professionals. IT security professionals can make developers aware of issues, but in general there’s not much they can do to fix the application itself.

    Also, IT security professionals typically don’t understand the amount of coding that might be required to fix an issue, and they are not always able to access the true risk associated with a specific vulnerability. All vulnerabilities tend to be treated as equal threats regardless of number of instances a vulnerability has been exploited.

    The good news is a full 88 percent of respondents saying it is somewhat to extremely important to integrate security into DevOps. Failure to do so will lead to issues such as increased costs (78 percent), slower application delivery (73 percent) and increased security risks (71 percent). Awareness of these issues should eventually lead to the development and deployment of more secure applications.

    The issue, of course, is that not every development team is equally along the DevSecOps maturity code. Because of that issue, it unfortunately may be years before the preponderance of applications running in a production environment are able to defend themselves from even the most rudimentary cybersecurity attacks.

    — Mike Vizard

  • DevOps Chat: Developers and Security with Pete Chestna, Veracode

    DevOps Chat: Developers and Security with Pete Chestna, Veracode

    In this DevOps Chat we speak with Pete Chestna of Veracode about the roles and opinions of both developers and security pros about how and who should be working on security in the enterprise. Much of the discussion centers on a survey Veracode conducted with consulting firm Enterprise Strategy Group (ESG).

    Pete is always a great interview with a common-sense approach to DevSecOps borne from being both a developer and security pro. I am sure you will enjoy this discussion. As usual, the streaming audio of our discussion is immediately below and the transcript of our discussion is below that.

    Audio

     

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel of staging-devopsy.kinsta.cloud here for another DevOps Chat. Today’s guest on the chat is Pete Chestna, Veracode, a CA company, director of developer engagement. And that’s a fancy way of saying Pete’s out there talking to developers about bringing security, shifting it left, bringing it into the developer universe and making all of our apps more secure. Pete, welcome to DevOps Chat.

    Pete Chestna: Thanks, Alan. Pleasure to be here.

    Shimel: Yep. So, Pete, you and I have, of course, crossed paths before and I’ve seen you present and you’re a knowledgeable, knowledgeable person, in terms of how security is continually kind of making inroads into the developer community and kinda convincing them that security’s everyone’s responsibility, right? That security isn’t just the purview of the security team; it’s everyone’s job. And you’re doing a heck of a job with it, which has, I think, attested to Veracode’s value in the market and its place in the market, so great job there.

    Chestna: Thanks.

    Here are some other DevOps Chats you may want to listen to:

    Node.js Becoming More DevOps-Friendly
    DevOps Chat: State of DevOps Report 2017, Nigel Kersten, Puppet
    DevOps Chat: Why Real Transformation Starts with Culture, Bryson Koehler and Shelbee Smith-Eigenbrode, IBM

    Shimel: Pete, what we’re gonna talk a little bit about today is that Veracode recently conducted a survey of developers and security folks, talking about this very subject. And I wanted to share it with our audience a little bit, if you can. Why don’t we start with what you consider sort of the headline of this survey?

    Chestna: Thanks. So this was done with the enterprise strategy group and the key takeaway for this is, really, again, it’s reinforcing the messages we already bring out to the market, so we need increased accountability. The reason that developers don’t take security more seriously is because they’re held to account for their functionality and not necessarily their security, so, if we bring in metrics and goals into the equation, for developers, we’re gonna see an increased uptick in the way they think about security. It’s about building relationships with your security team, so security and developers need to work together to build that relationship, so, that way, they feel like there are people on each side and not just a function.

    And, really, it’s what I call the “three-legged barstool of application security.” It’s about training, making sure developers are trained—a lot of the times that they don’t wanna develop these tools is because they don’t know what to do with the results. Second is integrate and automate—if you bring it into their toolchain and make it easy for them to use, then they’re more likely to use it. And, lastly, it’s about helping them fix what they find—again, this knowledge gap of, “What is across-site scripting? What is OS command injection?” Help them understand how to fix these and prevent them makes them more likely to adopt these tools and make security a better part of their work.

    Shimel: Got it. And you know what, Pete? So I’m up here in Boston, recording this, and we just finished a DevOps Connect. I had an interesting question from the audience yesterday, and a gentleman said, “Well, our developers kinda get paid or judged on how much code they commit. And to go back and tell them that the code they committed, you know, it had vulnerabilities and they gotta fix it, it really upsets them.” I’m sorry for them, right, Pete? But –

    Chestna: Right.

    Shimel: – to me, it’s kind of—you know, I used to see this problem with running sales teams and stuff like that. You’ve mismatched incentives here. Right?

    Chestna: Oh, absolutely.

    Shimel: You know, and that has to be—and that’s not the developer’s or the security guy’s fault; that’s management’s fault.

    Chestna: Yeah, if we don’t take accountability for what we’re doing, if we don’t hold the developers—so, you know, I always look at the security team. They are responsible for security but the developers need to feel accountable for security. And you’re right; it’s management that needs to say, “We’re gonna measure you on this and it’s gonna be part of how we evaluate you at the end of the year.” That will drive the right behaviors. They’re gonna do what they get paid to do. And if they get paid to produce functionality faster, that’s exactly what they end up doing.

    Shimel: Yep. And so this is apparently something, I think, we need to solve. You know, we’re gonna see real progress in the area. But, look, let’s save that for another day. Pete, can you share some more of the findings on the survey with us?

    Chestna: Yeah, absolutely. So a couple of things that stood out to me, as I read through it, was there’s a increased maturity as far as adoption of Agile and DevOps. There’s only 5 percent of respondents that said they have no Agile in their shop at all, where 18 percent say that most or all of their products are using a Agile methodology. And then it goes on from there—28 percent is more than half. So we’re seeing a really good adoption, at least of Agile. And then if you think of DevOps usually being run on an Agile methodology, only 6 percent of respondents says they haven’t adopted DevOps at all and 17 percent are reporting that they have extensively adopted it, so great numbers, as far as people coming up to speed in doing this. And, as far as making things easier, 45 percent of respondents said that DevOps makes it easier for them to developer software, including security, which is a great finding.

    Shimel: That is—what was the number? 45? Just about half?

    Chestna: Yeah.

    Shimel: Excellent.

    Chestna: So those must be shops that are doing it well because they’re seeing the benefits that you get from experiencing DevOps.

    Shimel: Well, I mean, you know, Pete, you take this, I think, in conjunction with the recent release—I was out in London last week for DOES and the folks at DORA and Puppet released the State of DevOps for this year’s survey and results, and it dovetails nicely here, where DevOps-enabled organizations deal with something—I forget what the number was—15 percent less vulnerabilities or 15 –

    Chestna: Right.

    Shimel: It was some –

    Chestna: It was from the Puppet report.

    Shimel: – eye-popping number of the improvement in the quality of code, vis á vis security. So it seems to make sense, but you know what, Pete? I’m amazed that something that seems so, you know, simple, so elementary, if you will, is still—we’re still talking about only half of organizations, a little less than half organizations doing it. What do you think is holding back the other half?

    Chestna: It’s the culture. You know, people wanna maintain their silos. I see it all the time where the management—again, we’re going back to management, as a problem here—they wanna hold on to their silos and their power. And if you look at where DevOps takes a company typically, if you do it whole-hog and embrace everything, you’re reorganizing, so someone that has a large quality staff reporting to them is now gonna have that broken up and disseminated into other teams, and now they’re gonna be responsible for other functions or they’re gonna have to go find another job. So there’s this big unknown and fear for them of, “What does the future hold if I just don’t do quality and I have to actually produce product?” So this cross-accountability is just—is scaring the hell out of them.

    Shimel: Yeah. Yeah. But you know what? Let’s not put it all on the dev side of things; let’s talk a little bit about the security folks, too. And, Pete, you and I both come from the security world. There are a lot of security people who get very territorial, you know, to say the least, around running scans, being the ultimate deciders of what’s secure and not secure, and they’re just as resistant to change, from a cultural point of view, as dev teams are sometimes. I mean, do you agree or –

    Chestna: Yeah, and they white-knuckle the release, so –

    Shimel: Yeah. [Laughs]

    Chestna: – I’ve talked to a lot of people that say, “Hey, it’s gotta be pen-tested. I have to pen-test everything.” If you’re talking about releasing multiple times a day, there’s no way in heck that you’re gonna be able to do that. So you have to pick your battles and say, “This is important. It touches crypto or this touches authentication or authorization. It has to be pen-tested,” versus, “I can use the easy, least expensive way of SAST and DAST to go and find vulnerabilities and I can trust that those tools will find things.” So it’s that back-and-forth of how much security needs to be in there and how assured do they need to feel before they can sleep at night.

    Shimel: Mm-hmm. And they’re ultimately, Pete—you know, I think, when we look at surveys like this and we talk about the view of the security team versus the view of the dev team, view of management, really, the way to kinda bridge these gaps and bring this all together is really a lot of the kinds of things that you do. Right? You’re out there, talking to the different constituencies around the world, almost constantly—we were talking off-mic about how much both of us have been traveling—but there’s a mission there to bring these tribes together, if you will, and forge a common path and a common way of working together. And I think, if we take surveys like this and we look at the results and we share those results with the two teams, again, it becomes sort of like, “Duh. What are we fighting about?”

    Chestna: Oh, exactly. So, I mean, if I go back to the survey for a second here and look at how people are being measured, 33 percent of respondents say, “I’m being measured on functionality that I released,” versus only 18 percent that are saying, “I’m being judged on security.” So, if you look at that number and say, “Well, what are they doing? Their actions reflect how they’re being measured, so let’s change how they’re being measured and see if that changes what they think about their jobs.” The people that responded and looked at “Does DevOps help me with security, the ability to automate and integrate?” 58 percent of respondents said, “Hey, it allows me to do this integration and automation,” which is one step toward getting them to actually pay attention to those results.

    Shimel: Yeah. And 58 percent is a sizable majority.

    Chestna: Yes.

    Shimel: That is Pete, I don’t know if you have the insight on this, but these were large enterprises, primarily, that were surveyed here?

    Chestna: Yes, most of them were—98 percent were 1,000 or more employees.

    Shimel: Okay. Now were there any particular verticals that were highlighted or anything?

    Chestna: The biggest ones were IT at 23 percent and the finance industry at 21 percent.

    Shimel: Oh, okay, there you go. And those are both pretty DevOps-savvy, if you will, or maybe early—no, I don’t wanna use the term “early adopters,” ’cause finance is very rarely an early adopter, but, I mean, certainly, DevOps has taken a strong foothold within the financial and financial services industry, so.

    Chestna: Yeah, and the thing is driving them is really the regulatory compliance, so 53 percent of respondents said that, “We’re doing app-sec because of regulatory.” Forty percent are saying it’s because of corporate governance. And an interesting stat here was 34 percent said it was because of customers or partners, so the great news is people are starting to pay attention to their software supply chain, to say, “Am I getting secure software to install in my environment?” and they’re asking customers to prove that they are. And, hopefully, that also means that outside customers, like individuals, are also looking at security as an important decision in where they go and where they spend their money.

    Shimel: Yep. I agree. I mean, it is interesting stuff, Pete. So, Pete, where do we go from here with this now?

    Chestna: So I think the next step is to continue the journey that you and I are on, of helping security understand development, help development understand security, tell them that they need to build in accountability. It’s built by relationships, so they have to work together. If security starts to teach developers how to do secure development and explains to them how to fix the things that they’re finding, developers are more likely to engage because it’s not this great unknown of “Hey, I don’t wanna go in and fail. I don’t wanna go in and look like an idiot,” or, “I don’t wanna go in and not understand what I’m doing.”

    So security needs to take their part and companies need to understand that training and development and education around security is a carrying cost of having developers. They were never trained to do it and they have to pick that cost up; it’s not like they can just throw them all away and bring in new developers because the developers that they bring in are gonna have the same problem. So getting that education done leads to better engagement, leads to better results.

    Shimel: Agreed. And you know what, Pete? Just a shameless plug on that note: I’m gonna be out in Singapore at the end of July, at the RSA APJ show, putting on another DevSecOps event at RSA, and we’re working with both the local—so it’s interesting. In Singapore, there’s almost a 900-person-strong DevSecOps MeetUp group, which is huge for that area of the world, and there’s an equally-as-big DevOps MeetUp group. And we’re working with both of these MeetUp groups, as part of this event, and we’re really—I’m hoping to really kinda bring these tribes together and make it happen. Of course, I’d –

    Chestna: Sounds great.

    Shimel: – you to come out. You’re in Black Hat at that time.

    Chestna: Yes.

    Shimel: Are you speaking at Black Hat, Peter?

    Chestna: I’m not. I’m doing customer stuff, customer-facing.

    Shimel: Ah, very good. So you’ll be in hot Vegas and I hear Singapore’s pretty warm now that time of year as well. Well, we continue along our mission of spreading the good word, right?

    Chestna: Yes, sir.

    Shimel: as they say. Anyway, so, Pete, we’re about out of time. I know you don’t have the URLs off the top of your head right now, but we will include them in the show notes for people to download the results of the survey and the report, maybe find out a little bit more, but I wanted to thank you for sharing and giving us a little bit of insight into the results. And then keep up the great work, Pete. You do good stuff.

    Chestna: Thanks. I appreciate your time, Alan.

    Shimel: All right, Peter. This is Alan Shimel for staging-devopsy.kinsta.cloud’s DevOps Chat and we’ll see you on the next chat.

    — Alan Shimel

  • DevOps and Database Security

    DevOps and Database Security

    Osterman Research recently released a survey-based report on database security. The results don’t exactly instill confidence where username breaches are concerned: While more than 50 percent of respondents felt that a breach of the database would be a serious problem for their organization, 44 percent responded that it would take more than a day to detect compromised credentials and a breach of data. Considering that attackers are going to get in and get out as fast as possible, more than 24 hours is plenty of time for those compromised credentials to result in copies of tables making their way to the dark web. Some of our biggest hacks—Yahoo! springs to mind—take much, much longer to be detected.

    There are tools available to monitor database logins and activity, from free (and sometimes onerous) logging for databases including MariaDB, MongoDB and MySQL to review and analysis through things such as Splunk plugins for most database systems. Once you are tracking logins and source IPs and possibly watching for spikes in query volumes, the power of DevOps can help you manage monitoring.

    The key here is to collect the data, even if temporarily. A great first step is building a process that turns on login-attempt logging for a set period of time, then processes the resulting file to send the user a list of when they logged in and from where.

    Next, capture summary information about number of queries and response sizes. That can show abuse of credentials, by either internal or external bad actors. The issue is not the availability of tools to do these jobs; the issue is making it a priority.

    While not exposing your database to the internet is a good policy, monitoring database credentials provides in-depth defense against external attackers and a defense against internal attackers. Utilizing the tools available plus some work from DevOps (to automate the process, then to work out a way to add new application and user logins to the monitoring system) will improve your ability to detect credential issues, and the process—as so often happens when DevOps is involved—will force you to review which applications are hitting the database from where, possibly opening eyes to ideas for improvement in database usage and location.

    These are the areas of security where DevOps really can help; it is rare for any one team to control security for logins/queries on the database. Is it the DBA’s responsibility? The security team? Operations (which generally creates the accounts)? Utilizing the tools available, and sitting down to discuss which makes the most sense for your organization, you can generate a simple report to be reviewed on a regular basis and settle the responsibility question. That means there is no huge loss of time pawing through logs and no waiting weeks to find out your database has been exfiltrated. It just makes sense, and it bridges the gap where security gets direct benefit out of DevOps, instead of the indirect benefit offered by standardized processes.

    — Don Macvittie

  • DevOps Security: Stop Discussing, Start Implementing

    DevOps Security: Stop Discussing, Start Implementing

    Is it Strong DevOps? DevOps Security? Secure DevOps? DevSecOps? DevSecQAMktSalesOMGBBQOps?

    Who cares?

    Like a ton of people with an interest in information security, I was appalled when I read “The Phoenix Project.” Here was a book that portrayed DevOps, why it was required, how it could help and the benefits very well. But it served security terribly. Worse than terribly. While it did accurately portray the predominant feelings of developers and Operations toward security, it utterly failed to adequately consider the correct usage of DevOps to attain InfoSec goals. Indeed, while it is a light treatment, it certainly comes across as, “Give up on InfoSec and you’ll be happier, healthier and more popular!”

    Clearly it was not a book written by information security staff.

    The Point Is …

    Don’t get me wrong, those who follow me know that I’m a developer that learned operations and has always found himself doing security bits, because no one else was, or because I was teamed with them (as an enterprise architect, our team was EA + Infosec, so we did a lot together). But that abiding interest in InfoSec has made it easy for me to see that the bulk of the problem between Security, Dev and Operations really is communication. An example might be in order.

    When SQL injection first hit the scene in a big way, it came with simple examples and was easy (for a developer) to understand the danger. Nearly immediately, developers had worked up solutions, were sharing them and tools were being developed to scan for injection weaknesses. Things moved very quickly, because developers understood the danger and agreed that it was a big deal.

    Meanwhile, using page data—hidden fields, hard-coded values (like from a list), etc.—pose the same level of risk. Copying the page, modifying those values and submitting the page—or using any of a dozen easy to use tools to mock up the data—makes them equivalent to user input, particularly in cases where they are used directly in queries. Yet even today, many many developers still use them without user-input error checking.

    Why? Because they don’t believe the risk is equivalent. For SQL injection, all a bad actor has to do is hit a vulnerable webpage and enter the right (and, I might add, well-documented) characters to open themselves to free querying of the database—at least one table, possibly much more. They see that as a much greater risk than someone having to modify HTML to get the right field to have the correct data and submit it.

    The fact that both attackers and tools are advanced enough to make the difference negligible doesn’t change the belief unless security convinces developers through education.

    ‘Faster’ has Challenges

    By the same token, both agile and DevOps move fast. They are designed to move fast. Security is more concerned with “protected” than fast, and is designed that way. Security staff (and this is the real source of a lot of burnout) hires on with “Protect Our Systems” as a job title, with the subnote, “But don’t get in the way.” This is a set of core principals that are at odds before the InfoSec person even sits down to interview. Agile and DevOps aggravate this tension, because, “Wait, there is a problem here, give us until tomorrow to get details,” now violates “but don’t get in the way.” “The developers in question have a stand-up coming and really short, really tight deadlines to meet. And InfoSec is interfering—again,” will likely be added to that statement by Dev. The same is true in Ops. Stopping an entire deployment because InfoSec is worried about security of private keys inside the private network violates the “but don’t get in the way” rule.

    But Solutions are Available

    So how can these tensions be brought together to resolve your problems? I’ve got some suggestions (they probably aren’t in the order you would expect, so I’ll explain as I go), but honestly  they are just a starting point. Entire books have been written on these topics, and more are about to be, if the state of the DevOps/InfoSec union is any indication. We can’t even agree what to call it, so we clearly aren’t agreed as to how to achieve it. Take these as what they are—suggestions—and start moving forward with what your org needs to be successful.

    1. Automate all of the things. Yep. Go download the various OWASP security tools, or your other favorite open-source tool, or call up your preferred vendor and get the automation of security checking—from source code analysis to penetration testing—going. Do those tools have weaknesses when compared to manual security evaluation? Most of them, yes. But here’s the thing. There is a quality staffing shortage in both InfoSec and DevOps. It is time to lean a little more on those tools, even contribute to make them better. Because the security checking they can do is better than nothing, and frankly is better than spending limited resources checking by hand. And that is why this step is first on my list. You need those resources. You need them to handle the rest of the steps. Once you have a tool like Jenkins auto-running these tools, and output review being just part of the job, then you can start to consider using those freed up resources more productively, or reporting that you’ve got more testing with DevOps than you had, whichever is true.
    2. Embrace and enhance education. Because of the rate of movement in an agile-plus-DevOps world, this must become a partnership with both Dev and Ops. Focus on helping developers and admins with the why as much as the how. People are more quick to adapt if they understand the reason for doing so. And for InfoSec to keep pace, they will need to adapt quickly.
    3. Look for ways to automate beyond implementing simple tools and reviewing results. The more repetitive work is built into the process, the more InfoSec is available to tackle bigger, less scriptable problem-solving. I’ve been talking a lot with CloudCoreo, for example, and its auditing tools can help InfoSec understand the state of cloud deployments with both alerting and reporting. Infrastructure monitoring tools make a lot of sense in a world of frequent infrastructure changes initiated by both auto-scaling and more frequent deployments.
    4. Shift automation of InfoSec to the DevOps team. Security is normally a relatively small function, and open positions can sit there or bring in people who need training in an organization’s tools and processes. So once automation is in place and reliable, shift responsibility to maintaining it (software updates, etc.) to the DevOps team, because it is a part of the DevOps process. Security can continue to monitor output and validate automated security testing results, but maintaining that piece of the DevOps infrastructure should not be InfoSec’s job.
    5. Rank what’s left that’s manual. Give each an importance. If there is potential impact to the business, ask business people to help you. Then assign work based on severity rankings. We do this stuff with risk management and threat assessment; this is no different, except you have to be willing to drop low-priority things—not to let them slide because you never get to them, but to publicly say, “This is a risk we are willing to take.” Let the team know that they’re not the only ones adapting.

    Will these basic starting steps solve all of InfoSec’s problems and make security never seem to “get in the way”? Of course not. Don’t aim for hanging around the campfire singing “Kumbayah”; aim for working as a team to turn out quality secure compliant code in a more predictable (and if you are an org that needs it, much faster) manner.

    A Rose by Any Other Name

    What, then, we should call it?

    Frankly, I suggest we call it DevOps. We’re not going to add every team that is subsumed into the DevOps umbrella into the name, so just call it DevOps and have a security piece in the process.

    Because it really doesn’t matter what you call it—it matters that it is compliant and protected.

    — Don Macvittie

  • DevOps Connect: DevSecOps Edition Complete Session Videos

    DevOps Connect: DevSecOps Edition Complete Session Videos

    [nextpage title=”Introduction” ]

    The third annual “DevOps Connect: DevSecOps” held at RSA Conference 2017 shows just how far DevOps has matured in recent years from IT subculture to mainstream practice. In the presentations in this slide show, you’ll see firsthand accounts where enterprises have transformed legacy methodologies to DevOps practices, building more healthy cultures and, of course, more secure software.

    [/nextpage]

     

     

     

     

    [nextpage title=”Breaking Bad Equilibrium” ]

    Breaking Bad Equilibrium

    John Willis

    In DevOps we try to identify and fix bad equilibrium. We constantly look for discontinuity in the areas of technical debt, collaboration, risk and work-life balance. In this presentation, John Willis looks at some other successful fields that address equilibrium and discontinuity in their respective fields. Willis looks at areas of behavior economics, cognitive psychology and game theory. He also has some fun with a few pop culture books, movies and game shows as examples of bad and/or Nash equilibrium.

    You can see this presentation here.

     

    [/nextpage]

    [nextpage title=”A Tale of Two Stories” ]

     

     

    Building Security In: A Tale of Two Stories

    Laksh Raghavan

    The holy grail for software security professionals is to make their development teams treat functional and non-functional requirements as equal citizens. This becomes even more challenging in “agile.” Wouldn’t it be great if you had a quick and easy means by which you can write pertinent and actionable “security stories” and place them into the backlog of all your scrum teams so that they can get prioritized and completed along with “user stories”? The challenge, however, is making this scalable and seamless in a large enterprise with diverse sets of frameworks, application stacks and programming languages. In this talk, Raghavan shares tales from the trenches of implementing such a system—what worked, what proved challenging and the associated outcomes.

    You can see this presentation here.

    [/nextpage]

    [nextpage title=”2016 State of DevOps Report” ]

     

     

    DevOps and Security: What We’ve Learned from the 2016 State of DevOps Report

    Dr. Nicole Forsgren & Jez Humble

    Four years and more than 20,000 survey respondents later, Forsgren and Humble have learned a lot about what makes IT and organizational performance awesome. They also have learned some things about the role that security plays in technology transformations. Their latest research includes insights into trunk-based development, lean product management and employee engagement. Watch this talk for practical takeaways that will  make your teams and technology transformations even better.

    You can see this presentation here.

    [/nextpage]

    [nextpage title=”Bits and Bytes” ]

     

    Where Bits and Bytes Meet Flesh and Blood: DevOps, Cybersecurity and IoT

    Joshua Corman

    We’ve heard software is eating the world. Corman says software is infecting the world. Our dependence on connected technology is growing faster than our ability to secure it—in areas affecting public safety and human life. Adding millions of lines of code and connecting everything to everything else exposes cyber-physical systems to new accidents and adversaries, Corman contends in this talk. This is truly where bits and bytes meet flesh and blood.

    Despite best practices, modern software development and security have allowed 100 of the Fortune 100 to lose intellectual property and sensitive information—even our governments routinely succumb to adversaries. These failure rates cannot stand with the consequences of failure being measured—not in record count—but in human lives and GDP. Paradoxically, Corman says, it may take DevOps to rise to these challenges. Rugged DevOps is finding un-obvious common ground and breakthroughs like software supply chain principles, greater visibility and response agility, and immutable infrastructure. Corman says we must be better, and provides his view of what better looks like.

    You can see this presentation here.

     

    [/nextpage]

    [nextpage title=”Release engineering” ]

     

    The Intersection of Release Engineering and Rugged DevOps

    Paul Reed

    At RSAC 2016, release engineering’s role in rugged DevOps was discussed with a focus on how it relates to software delivery supply chains and the increasingly critically important topic of security and security management.

    This year, J. Paul Reed explores what we’ve learned in the past year about the intersection of release engineering and rugged DevOps.

    He takes take a deeper dive into specific release engineering techniques and tools that can not only start you on the path to effectively managing your software supply chain, but also pay concrete dividends in making your software’s security posture better and help you remediate issues more quickly when a security issues arises.

    He also explores some nascent trends on the frontier of software delivery and security management, including the role of human factors and systems safety in the broader context of fast, sustainable and, yes, secure delivery of increasingly critical software components in our society.

    You can see this presentation here.

    [/nextpage]

    [nextpage title=”Next Gen Security” ]

     

    Next Gen Security Needs You!

    Shannon Lietz

    Next-generation software deserves security from the start and better collaboration to effectively reduce the real risks posed by attackers. Some might say this is heresy, but given the endless trend of security breaches from traditional methods, likely not. The ideal state of security has always been to achieve continuous improvement or level 5 maturity. By this very intention, security has always been a significant factor in the production of software but relatively difficult to commoditize because of its complexity.

    Using DevSecOps methods and principles, simplicity and high-fidelity controls are emerging within the software industry to help organizations forecast and react faster to attackers. Lietz’s talk provides an essential road map for security practitioners to tackle how to bring DevSecOps to their organization and avoid common pitfalls that have come from early day lessons.

    You can see this presentation here.

     

     

    [/nextpage]

    [nextpage title=”DevOps in a Regulated Environment” ]

     

     

    Implementing DevOps in a Regulated Environment: The Aetna Experience

    Duane Schleen

    One of the big challenges organizations are facing is how to introduce DevOps principles to regulated industries. Industries such as health care or financial services must adhere to stringent security and governance controls, which often make it difficult to adopt new technology stacks such as DevOps and containerization. If you have adopted an agile approach to software development and have plans for moving to DevOps, microservices and containerization, what processes do you follow to avoid compliance missteps? This talk shares Aetna’s journey of modernizing its application stacks and infrastructure.

    Schleen covers which considerations went into the design and selection of the DevOps methodologies, which applications were moved to microservices and containerization first and what was observed as a result. Schleen also covers how security departments can help the business understand the advantages of DevOps and containers—removing fear rather than adding fear. Finally, Schleen details the experience of architecting security across a rapidly changing application environment, and how continuous integration and continuous monitoring can go hand in hand in delivering application agility, but also security vigilance and competency.

     

    You can see this presentation here.

     

    [/nextpage]

    [nextpage title=”Ops Happens” ]

     

     

    Ops Happens: DevOps After Deployment

    Damon Edwards

    Listen to enough DevOps conference talks and it all starts to sound like: “deployment, deployment, deployment.” But what happens after deployment? What does DevOps mean for other traditional enterprise operations activities such as incident response, problem management and compliance?

    Damon Edwards tackles these questions in this session. Here, Edwards examines what happens when the “go fast” ethos of DevOps inspired delivery teams meets the “be stable, be secure, be compliant” mandate of traditional enterprise operations organizations.

    Damon also identifies DevOps-inspired principles and practices being leveraged by high-performing enterprises who are currently transforming their operations organizations.

     

    You can see this presentation here.

     

    [/nextpage]

     

    [nextpage title=”Requirements Gathering” ]

     

     

    Requirements Gathering for a Successful Rugged DevOps Implementation

    Hasan Yasar

    It is a must to include secure coding practices in application development life cycles to produce rugged software. Yet, each organization’s development pipeline and application is different compared to others. It is also necessary to have preparation prior to having a successful implementation of rugged DevOps. This includes organizational culture, security policy, development platform, application technical stack, operational team involvement and foremost secure coding practices. The questions are: how to assess, what to find as bottleneck, train whom on what, what to measure and, finally, how to monitor. Then, build up your customized integrated DevOps platform where you can build a rugged application along with other quality attributes such as compliances, secure testing, performance monitoring.

    The burgeoning concepts of DevOps include a number of concepts that can be applied to increasing the security of developed applications. These include adding risk-based architectural design, automated security testing techniques such as fuzz testing, software penetration testing to the software development cycle or the continuous integration cycle. Applying these and other DevOps principles can have a big impact on creating an environment that is resilient and secure. In this session, Yasar explains how his company figured the right requirements and then how you can utilize this in your own organization for Rugged DevOps.

    You can see this presentation here.

    [/nextpage]

    [nextpage title=”Getting Security Up to Speed” ]

     

    Getting Security Up to Speed

    Oleg Gryb

    So, you’ve adopted agile software development life cycle and your DevOps team runs continuous integration/continuous deployment. But what about security? If you haven’t figured out yet how to speed up your security processes , it can easily become a bottleneck and slow down the whole software development process. Gryb shows how to avoid this.

    Gryb discusses how to replace old security processes with the new processes, and how to add more security automation tools that utilize existing quality assurance test cases.

    You can see this presentation here.

    [/nextpage]

    [nextpage title=”Scaling Rugged DevOps” ]

     

     

    Scaling Rugged DevOps to Thousands of Applications 

    Tim Chase, Aaron Rinehart, Jeff Williams

    Most of the talks on rugged DevOps are trivial. Write a script to hook up your scanner to Jenkins, and your WAF to your SIEM, feed the results to developers via JIRA, and claim victory. If you have multiple tools, maybe push the results into ThreadFix. But very quickly your cup will runneth over with vulnerability reports that need to be manually triaged. If you try to scale, you’ll need a dump truck and an army. If you want to really scale rugged DevOps, you need to get the humans out of the critical path.

    In this talk, this trio explores how large enterprises handle this challenge by instrumenting their application portfolio, assessing and protecting applications in parallel and integrations enabling instant notification directly to stakeholders. The result is continuous protection during both development and operations.

     

    You can see this presentation here.

     

    [/nextpage]

    [nextpage title=”Other articles” ]

    Other staging-devopsy.kinsta.cloud Articles you might like:

    Security @ the Speed of DevOps Survey: Efforts Still Lag

    The Elusive Definition of DevOps

    DevOps in 2017: From Building to Executing

    [/nextpage]

    — George V. Hulme

  • Everything Ops: Are DevOps Principles Being Applied Too Broadly?

    Everything Ops: Are DevOps Principles Being Applied Too Broadly?

    From big data to storage to security, the DevOps concept is being applied to every field of IT operations under the sun today. This “Everything Ops” movement reflects the popularity of DevOps—but is it also diluting DevOps’s significance?

    DevOps itself focuses on software delivery. It’s about designing, building, testing, deploying and managing software applications.

    If you follow the DevOps conversation, however, you know that DevOps principles are now being extended to lots of niches that don’t have much or anything to do with software delivery chains. Consider these examples:

    • DataOps: DevOps principles for data analysts.
    • ChatOps: The idea that chat tools should be integrated into workflows.
    • SecOps (or rugged DevOps, or DevSecOps, or whatever else you want to call it): DevOps practices for security teams.
    • Storage Ops: The insertion of DevOps practices into storage.

    The list could go on. Taken together, these many flavors of DevOps reflect what I like to a call an “Everything Ops” tendency. Fans of DevOps want DevOps to take over the entire world of IT.

    Benefits and Drawbacks of ‘Everything Ops’

    If you believe that DevOps represents a better way to deliver software, then the Everything Ops movement is a positive thing. It’s a way to help people who work in areas of IT other than software delivery to innovate as well by taking cues from their DevOps colleagues.

    But there is also a danger that Everything Ops can be applied too broadly. You can’t fit every single thing in the IT universe into the DevOps mold. For example, CloudOps (the DevOps-related way of managing cloud infrastructure, not the company of the same name) just doesn’t make a lot of sense. It’s basically just a reiteration of the ideas that are already at the core of cloud computing: Scalability, agility and location-agnosticism.

    Concepts like ChatOps can also be problematic because they refer to a specific way of using a particular type of technology, whereas DevOps is about cultural practices. ChatOps is a fundamentally different sort of thing from DevOps.

    Conclusion

    In short, by overextending the DevOps conceptual framework, you run the risk of diluting the importance of DevOps itself—and of losing your focus on software delivery, which is the area that DevOps benefits most.

    This is not to say that we shouldn’t extend DevOps to other fields. We certainly should. But we should be careful when doing so. Don’t try to make DevOps eat the entire IT world, because that just doesn’t make sense.

    — Chris Tozzi