Tag: devops

  • Why Baking Security Into the DevOps Framework is Vital to Its Success

    Why Baking Security Into the DevOps Framework is Vital to Its Success

    I attended my first official DevOps conference in Israel in September 2013.  But I was initially introduced to DevOps by my customers – firewall and network managers who, through their efforts to automate  security policy management, found themselves dealing with a new and like-minded set of IT stakeholders  –  DevOps teams.

    They said DevOps was also all about automation – automation that allowed IT to increase their business contributions by enabling new applications and other IT services to be rolled out faster with greater control and efficiency.  

    Conceptually, it was clear to me that the DevOps value proposition is just as relevant to Security as it is to Operations and Development groups, especially since Security teams apply automation with the same fervor as DevOps.  

    In fact, using automation to accelerate IT has caught hold in the network security world to fuel a new movement and class of solutions, called Security Policy Orchestration.  As the CTO of Tufin, a Security Policy Orchestration company, I could not help but recognize the synergies.  I was (and still am) intrigued by DevOps, so when I heard about the conference, I decided to go.

    And I am so glad I did.

    The alignment between DevOps and Security Policy Orchestration is obvious. They both champion the use of automation to accelerate the pace of business. We Security Policy Orchestration folks are just coming at it from a different area within the organization.  Kindred spirits, right?

    In theory, absolutely, but in reality…not so much.

    The conference as a whole was great.  It completely validated my theories regarding the synergies between Security Policy Orchestration and DevOp.  But what surprised me was that security was a topic that was not being discussed at all at the conference.   Maybe a hat-tip to application security, but network security was not even on the DevOps radar, at least not at this particular conference.

    It needs to be.  For DevOps, to really be able to move the needle, we have to work together.  If history has taught us anything, it’s that when new applications and services are not created or rolled out with security in mind, at some point we will have to go back and retrofit it back in.

    Envision the typical experience:   the development team builds a new application, brings IT Operations in to implement it.  Once that is done, IT Ops prides itself on all the corkscrewing it took to make the application work on the actual infrastructure.  Except for once the app is in production, it doesn’t work.  The troubleshooting begins.  Invariably, issues of network connectivity come up.  Solving them requires app, dev and security managers to break down the cultural and organizational barriers that exist within their organizations to work together to ensure the application is architected correctly into the network.  This starts and the process of change requests between AppDev and IT to get the app up and running. 

    If that process is not automated, it can take months longer than it needs to resolve everything.   Not to mention any company subject to PCI has to consider terms like secure zoning, a concept that is not second nature to DevOps folks.   If PCI is not an issue, there are plenty of other internal and regulatory mandates and security –related considerations that, if for no other reason than common sense, can exponentially reduce the chances of a company ending up in the headlines due to an APT.    

    These are just a couple of many scenarios that can be avoided if development, IT and security work together from the get go.

    The net/net is that Dev and ops have the same goal but they are siloed, which is slowing down the pace of business – inhibiting it.  Collaboration is not some warm and fuzzy team-building thing – it is a fundamental business requirement.

    And that’s why I am so excited to have the opportunity to do this blog.  I think I can add a unique perspective on how DevOps and Security can work together to reach our common goals.

    My next post will explain will dig into what Security Policy Orchestration actually is, so we can begin to tease out the similarities and determine how to build on that to true alignment and partnership. 

    Stay tuned as the drama unfolds! This should be fun….

  • The Unexpected Benefits of DevOps

    The Unexpected Benefits of DevOps

    There are many well and widely known benefits of DevOps, including rapid software delivery, a higher degree of enterprise agility, increased system resilience, and being able to swiftly identify and resolve problems.

    But what unexpected benefits have been experienced by organizations that are already down the DevOps path? Kevin Behr, chief science officer at Assemblage Pointe, says that one is the move to continuous improvement. “We’re seeing organizations move to continuous improvement because, as it turns out, the DevOps teams lend themselves very well to continuous improvement and cross-functionality,” he says.

    While working with a current enterprise, Behr explains how the company established a continuous improvement IT team in the same spirit as the continuous improvement culture at the automaker Toyota. “The development and operations teams are doing this and they’re solving some really, really crazy problems really quickly. You couple the collaborative mindset of DevOps with continuous improvement and you see stunning results,” he says.

    One of those outcomes includes hybrid thinking among collaborating teams. “I witnessed a developer using a checklist the other day. That’s something you never see. Developers are typically all about how many scissors they can run with pointed at their eyes. They are about creativity and danger,” Behr says.

    However, after working more closely with the operations teams, the developers tend to start adopting some of the tactics employed by ops teams. “The developer explained how the operations team provided a pre-handoff checklist, because items often were forgotten before release,” Behr says.

    The tighter coupling with developers is also changing the perspectives of operation team members. “Operations people typically have this fortification versus resilience mentality. They build big turrets, and they’ll put a big gun down. Now, having worked with more nimble dev teams, they’re wondering how—when the big gun fails—they can react more quickly,” says Behr. “You never often hear ops people talk like that,” he says.

    Another surprise is increased security. While some organizations fear that the rapid release cycles and the autonomy within DevOps would derail security efforts, many are experiencing quite the opposite. “I think that existential fear is present in security professionals, as well as a lot of test and QA professionals,” says Gene Kim, founder and former CTO at IT security firm Tripwire, and author of The Visible Ops Handbook and The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. “In observation, however it is the exact opposite. No longer does infosec do the testing work. QA and infosec now will be the consultative authorities to help developers do the testing. They will either write the tools that help increase the quality or help developers write their own tests. We no longer become the bottleneck that people try to figure out how to go around. Instead, we are actively helping them do their daily work. It’s the opposite of preordained failure; it’s active involvement,” says Kim.

    Another unexpected outcome that resulted from security becoming more integrated with DevOps is an emphasis on relevant metrics, explains Bill Burns, former director of information security for a U.S.-based major on-demand Internet streaming media provider. “If the security team identifies an important capability or service to build into a new service or product, then, just like other business units, security teams should proactively prepare to present metrics for the risk items they discussed,” he says.

    As Burns explains, operations teams see this more clearly as development and operations capabilities merge: the business has an expectation to have key operational metrics available all the time to support decision making. Security is no exception. And having security metrics as part of the same dashboard or review process builds trust and credibility toward the security team. “It also forces the security team to really focus on what the key threats or risks are, how they to measure them, and why the business should care,” says Burns. “This level of relevancy is great, another way for security teams to communicate and work with business units—something every security (should) strives for,” he adds.

    The next unexpected benefit—more work for the security team—is both good and bad news, explains Burns. “We’d engage with one team on one particular project, and out of the blue we would get that same person or one of his peers come to us proactively and request our input on other initiatives. Those were exceptional moments for me. You would have a small success with one engagement and you would build trust, and then you find other developers come to you and seek advice. That’s a huge indicator of success right there,”

  • DevOps: It’s All Open Source’s Fault

    DevOps: It’s All Open Source’s Fault

    Blame DevOps on open source. After all, it was the open source movement that gave developers the idea that they were free to code, free to build applications and other software for their companies without needing prior approval. It was open source that crowned developers kingmakers. It was open source that gave developers the freedom to not only write code, but also manage it.

    It was open source that gave us DevOps.

    DevOps: Freedom To Get Stuff Done

    Traditionally, IT operations has been a specialized task, an exclusive one that largely controlled the code allowed to run within the enterprise. Given the fact that all software had to be purchased before it could be run, there was little risk of developers or anyone else introducing rogue software into the hallowed halls of the data center.

    Enterprises were able to enforce policies because all software had to start with Purchasing and end with Operations. There simply was no other viable way to get software into the enterprise.

    That is, until open source.

    Open source ruined the neat and tidy relationship between Purchasing and Operations. Suddenly software didn’t have to be purchased. It could simply be downloaded. As pressures mounted on lines of business to accelerate their pace of innovation, developers stepped up: “I have an open source project for that.”

    Operations fought back, trying to crimp open source adoption. They failed.

    There simply was too much pressure on developers to get stuff done. Once Amazon gave developers a home outside the data center to deploy their code, the battle was over and a new model for building and managing code was born. Dubbed DevOps, the movement gave developers end-to-end control over their creations.

    Since 2011, DevOps adoption has increased 26%, according to a 2013 survey by Puppet Labs, resulting in 50% application failures and the ability to recover up to 12X faster. The rise in DevOps also translates into the ability to ship code 30X faster. All of which is expressed in a separate CA Technologies survey of senior IT decision-makers, which found that improvements to the customer experience is by far the biggest reason enterprises are embracing DevOps. 

    Given these improvements, there’s no way we’re going back to Operations-focused IT.

    Blessing Or Curse?

    All of which is not to suggest that DevOps has been an unalloyed blessing. In my experience, developers are often unprepared or unwilling to take on the burden of managing their applications in production. Trained for years on the idea that they could build an application and dump it on Operations to manage, developers are discovering that the “Ops” in DevOps is real, and sometimes really a pain.

    For example, one big problem is that production environments and dev/test environments are typically very different. An application that works flawlessly in a small-scale test environment may miss a whole class of errors that only occur in the presence of the more complex production environment (e.g. problems that only occur when application changes interact with a complex, zoned network topology).

    The reality is that over-optimizing for Ops (safe, secure and slow) or Development (Fast, opportunistic, iterative) proves sub-optimal. A balance is needed.

    But that balance increasingly skews toward upgrading Ops to meet developer demands. Indeed, developers are writing a host of infrastructure and tools to help other developers better manage their creations. Often such tooling is SaaS-based, and a significant percentage is open source, allowing developers to continue to skirt the controls of Operations while maintaining flexibility. Companies like Boundary, Puppet Labs, SumoLogic and more have arisen to make operations easier for DevOps professionals, among others.

    My own company, MongoDB, develops the most popular database for modern applications. Universally lauded for how easy MongoDB makes development, our tools for facilitating the operation of MongoDB at scale have lagged. Over the past two years we have been building out monitoring, back-up and other management tooling for MongoDB. It’s simply not enough anymore to forget the “Ops” in DevOps.

    No Putting The DevOps Genie Back In The Bottle

    I expect we’ll see this trend continue. The power of developers will increase in large part because the industry will better enable them to manage their applications, or to work more seamlessly with their Ops peers. But the era of Ops dictating to developers is over.

    Blame open source.

  • JumpCloud Joins Rackspace Marketplace

    Automating Server Management is Now Just a Click Away For Rackspace Customers

     BOULDER, Colo., Feb 25, 2014 (BUSINESS WIRE) —JumpCloud™ , the leading automated server management tool for DevOps and IT pros, today announced that its best-in-class service is now available through the Marketplace for Rackspace® Hosting,RAX +5.66% , the open cloud company. An ideal addition to the Marketplace, JumpCloud automates the tedious tasks of managing servers so DevOps and IT pros can focus on what makes their businesses tick: innovation.

    Rackspace customers can now receive automated server management capabilities with JumpCloud. This bolsters the shared goal of supporting highly agile and flexible infrastructures and workflows. With JumpCloud, end users are able to easily and effectively automate the management of their Rackspace servers, which saves time while also securing their infrastructure. The JumpCloud platform effectively automates tasks such as SSH/privileged user management, admin activity monitoring, patch detection and selected compliance requirements.

    “As one of the industry’s leading IaaS providers, Rackspace is in a unique position to complement our offering,” said Rajat Bhargava, President and CEO of JumpCloud. “Server management is critical, and every time someone spins up a dedicated server or cloud server based on OpenStack at Rackspace, we can now be a natural extension; we will be there to help automate the labor intensive, yet essential tasks associated with managing servers – in the cloud or otherwise.”

    “As organizations have increasingly scaled their server infrastructures, many have found it challenging to realize the full potential of both enhanced organizational speed and agility,” said John Engates, Rackspace CTO. “Rackspace solves this problem for organizations by offering a unique hybrid cloud platform, which combines public and private cloud form factors with dedicated, bare metal servers. The addition of JumpCloud to the Marketplace will help customers effectively leverage the full potential of the infrastructure they host with Rackspace.”

    For additional information about JumpCloud and the Rackspace Marketplace, visit:https://cloudtools.rackspace.com/apps/1007?restoreSearch=true#!overview .

    About JumpCloud

    JumpCloud automates manual, tedious server-management tasks from the cloud for DevOps and IT pros. Complementary to and integrated with Chef and Puppet, JumpCloud picks up where they leave off by automating management of users, patches, security, and compliance. JumpCloud returns days to DevOps and IT admins’ lives while increasing security. An automated SaaS-based offering, JumpCloud installs in seconds and deploys on physical, virtual, or cloud servers. For more information visit JumpCloud.com.

    SOURCE: JumpCloud

    Matter Communications for JumpCloudMaria Brown / Ryan Lilly, 978-499-9250jumpcloud@matternow.com

    Copyright Business Wire 2014