devopsy.kinsta.cloud

Tag: rugged devops

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

     

    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.

     

    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.

     

    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.

     

    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.

     

    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 Leadership Series 2015

    DevOps Leadership Series 2015

    We recently hosted the 2nd annual “DevOps: Wine-ing, Not Whining” event in San Francisco to bring together a number of thought leaders and leading practitioners in the DevOps field.  We traded stories from the trenches, formed new insights, and offered visions of the future.

    This week, I’ll be sharing videos captured from the event that highlight key themes from our conversations. We call it the DevOps Leadership Series.

    Screen Shot 2015-05-15 at 11.19.59 AM

    You’ll get to hear:

    In the next few weeks, I’ll be on the west coast at the Velocity Conference and on the east coast covering DevOps Days DC.  I’ll be capturing more insight from DevOps thought leaders at these events.  If you are planning to attend one of these events, let’s capture your DevOps perspective for the series.  To participate, please leave a comment below or catch me on @weekstweets.

    Today, we’ll start the series with Gene Kim on important themes for DevOps in 2015:

    [youtube http://www.youtube.com/watch?v=0IXrnhcRNUk]

     

    PART 2 of the series is now available at: 

    https://devopsy.kinsta.cloud/2015/05/19/devops-leadership-series-software-supply-chains/

  • Security, DevOps and the shift to a software supply chain

    Security, DevOps and the shift to a software supply chain

    Last week at the DevOps Connect event held in conjunction with RSA Conference, the security and continuous delivery worlds united to deliver an overarching message that security teams that can embed themselves in DevOps patterns can not only secure IT at speed, but they can actually contribute to a more reliable, repeatable and higher quality release cycle.

    “DevOps extended the value of Agile so that we went from just continuous integration to continuous integration and continuous deployment,” says Josh Corman, CTO of Sonatype. “If the three measures of any software manufacturing lifecycle is speed, efficiency and quality/risk,  then I think this Rugged DevOps era ideally allows you to go even faster, be even more efficient because of fewer break fixes and faster mean time to repair and better quality and lower risk.”

    To read more about security and DevOps, check out our eBook on Rugged DevOps. 

    Corman and Gene Kim, author of The Phoenix Project, developed on this idea in their talk, which pushed the thought that the ultimate Zen state of software delivery to strive for is a software supply chain.

    “The way we can get more safety and security into digital infrastructure, is to move to the ultimate evolved posture of software development as a supply chain,” Corman explains. “This makes you even faster than DevOps–even more efficient and with higher quality and risk mitigation without tradeoffs.”

    The idea of the software supply chain further builds on the lean manufacturing principles of W. Edwards Deming, who many in the Agile and DevOps worlds see as the spiritual grandfather of these movements.

    “If you take Deming to his logical consequence, we’re going to start paying attention to the quality of our suppliers, the quality of our supply and the traceability and visibility of which parts went were, such that when there’s another Heartbleed, we can do a prompt and Agile response,” he says, explaining that that avoiding known bad parts, such as a bad version of struts in car manufacturing or a faulty SSL component like the one that caused Heartbleed, “will make you keep top speed, halve your blowouts, faster meantime repair, better traceability and make the auditors go away with less pain”

    Security teams have traditionally been known as roadblocks rather than speed enhancers to development processes. But looking at it from the perspective of creating an effective software security supply chain, security actually plays a role in further speeding up production if it is helping organizations depend on higher quality components of production code and the code running infrastructure.

    “If we get better at our component selection and our traceability of what we’re using where, we can reduce the number of break-fixes or reduce the number of unplanned unscheduled work,” Corman explains

    He emphasizes that security debt tracks roughly with technical debt and CISOs should be having conversations with DevOps teams to that end. In the end security work pays down principle on technical debt, making it possible to spend more time writing code and less time on rework

    “I’d love to give us a more defensible opportunity which embraces what devops already cares about and doesn’t articulate how we can make them safer, instead articulate how we can make it faster and more efficient,” he says.

    As security pros start to do so, they might be surprised at their reception by the developers and operations folks. As Kim explained in their talk, in the end everyone does want the kind of quality that a cooperative security team can bring to the DevOps equation.

    “When security imposes itself on day-to-day DevOps processes, dev and ops say ‘thank you,’” he says.

  • Chevy and DevOps: What the Wi-Fi?

    Chevy and DevOps: What the Wi-Fi?

    In DevOps: Rapid Feedback, Rapid Repair

    I’m sure you have seen it too.  Chevy cars now come with wi-fi. How cool. I want that (and so would my kids). I can only imagine the possibilities.

    Screen Shot 2015-04-25 at 11.25.49 AM

    But, this is not all about my needs. Chevy and every other vehicle maker wants this too. And not for the reasons that you might first consider. Quickly, let me introduce you to the recalls of today:

    The glitches were related to cars losing power, erroneously deploying airbags, and other defects. This is just a small glimpse of the software recalls that have happened over the past year.

    But more troubling is this form of software “recall” from BMW showing a security flaw that could allow cyber criminals to unlock doors on 2.1M vehicles. Because every one of the 2.1M vehicles has the same defective software part, criminals effectively had access to a skeleton key to every one of them.

     

    http://i2.cdn.turner.com/money/dam/assets/140731164536-car-hacking-distance-1024x576.jpg

     

    In DevOps: Rule Your Supply Chain

    The reality is, that your new car has more software in it than you can image — about 100 million lines of code.  And, as we know, all software has flaws. But who wants to go to a dealer to get a software update? If my car can connect to the internet and update itself, that would save me an unscheduled trip to the dealer for a repair.

    While software updates to cars models in the past were would take 5 years to feed themselves onto the production line, that is now all changing.  For decades, large automakers like Toyota have been applying excellent management process for their entire supply chain.  And with the introduction of wi-fi in vehicles, they are expanding their highly-tuned practices to include their software supply chains. They know where every piece and version of their software is and who owns it. If a flaw is detected (be it quality, safety, security, or another attribute), they will now be able to automatically update that vehicle. Not only can they remove defects, automakers like Telsa are even making their cars faster.

    While many of us outside the auto industry think of these large industrialists as slow moving organizations, the introduction of wi-fi in cars is allowing them to now apply a core principle from the agile manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.

    In DevOps: Version Everything

    For those of you in the software industry, this kind of evolution is at the heart of many DevOps and continuous delivery efforts. Automate everything you can. Version everything you can. Deliver fast, improve visibility, and change fast. In many ways, the addition of 4G LTE Wi-Fi in Chevy Trucks means that DevOps has entered into our auto and software supply chains.

    If you imagine an even broader perspective of this wi-fi feature and software supply chain management, the auto makers are now leading the way to expectations of quality improvements in the Internet of Things (IoT). There is not much difference between an internet enabled truck, thermostat or fitness bracelet when it comes to rapidly improving and updating quality, features, performance, etc. (I’ll cover this topic more in future posts.)

    In DevOps: Optimize Your Software Supply Chain

    What have the auto makers learned from the software industry? And perhaps more importantly — when it comes to software supply chain management and continuous delivery — what can we learn from them?

    A final note on software and auto safety:  I am the Cavalry (@iamthecavalry) is encouraging the automotive industry to commit to cyber safety. The movement recently published a Five Star Automotive Cyber Safety Framework (PDF download) and calls for Automotive Industry adoption. Media outlets from across the US and Europe praised the effort and joined in calling for automakers and security researchers to work together to ensure a safe future.

  • Illumio Hopes To Cater Security To Continuous Delivery And DevOps Shops

    Illumio Hopes To Cater Security To Continuous Delivery And DevOps Shops

    Since coming out of two years of stealth development back in October, the data center security gurus at Illumio have been building momentum in the drive to break out of the confines of the traditional network-centric security model to make it easier to secure IT in the face of distributed computing, continuous delivery and DevOps patterns. This week, the firm got a big boost in the way of $100 million in Series C financing and continued forward movement with some new tweaks to its Adaptive Security Platform (ASP).

    Designed with DevOps patterns in mind. Illumio’s ASP is meant to be a continuous delivery system for dynamic policy enforcement within application traffic across everything from bare metal servers to VMs and containers within the data center and public cloud infrastructure.  According to Alan Cohen, chief commercial officer for Illumio, the idea is to build security attuned to the infrastructure as code movement in IT.

    “Security has been tied to the infrastructure for the  last twenty years–not just client-server, but also right back to the mainframe. And as  we’ve created software infrastructure–software models for applications and compute processes, whether its storage  or network or servers that can be spun up or spun down  or moved very rapidly–the security industry hasn’t  adapted well because its still very hardware, choke-point  centric,” he says. “The industry hasn’t done anything to adapt to distributed compauting and continuous delivery. (When vendors do make adjustments) they’re just running something on software but it operates as it did before.

    The announcement this week adds further capabilities for the platform to segment the continuous delivery of that enforcement down to the process level within workloads, so that as any part of the application changes, the platform automatically adapts security policies on all impacted workloads.

    “So let’s say  you have an application that’s a credit card processing application and it uses a certain database. You may have two instances of that database running on a single host. One is for PCI and one is not,” says Cohen. “Through our virtual enforcement  node we can segment and separate those two workloads and  effectively provide  a layer three layer  for firewall at the process level on an individual host.”

    The added segmentation of dynamic security enforcement gives DevOps shops a greater degree of flexibility in securing microservices environments.

    “When you  talk about microservices there’s two things to think about,” says PJ Kirner, chief technology officer and founder of Illumio. “One is that they’re small and process-oriented, and the other one is they exist for a short amount of time.  Both those aspects are important to consider for security. The fact that it needs to adapt quickly to all of these ephemeral workloads that are spinning up, spinning down to accomplish your goals.”

  • Are You Embedding Security for a Rugged DevOps Experience?

    Are You Embedding Security for a Rugged DevOps Experience?

    ebookcover

    As security thinkers try to wrap their heads around what’s broken in today’s security architecture and processes, DevOps and continuous delivery patterns may seem like yet another potential problem for already overwhelmed risk managers. But once security gurus get past the intimidation of working within a cycle of fast iterations, they could well find that continuous delivery model could actually provide a  blueprint for fixing what’s wrong with security today.

    Security leaders that work with operations, developers, architects, QA and the rest of the team to build continuous delivery momentum are helping their organizations develop a more rugged development life cycle that not only produces more secure software but that also supports faster fixes to security problems as they’re found.

    Learn more about how to start moving toward a Rugged DevOps mentality in our inaugural eBook, Rugged DevOps: 10 Ways to Start Embedding Security into DevOps Patterns. Some of the insights security and DevOps experts shared with our reporter Ericka Chickowski in this special issue:

     

    • The bad guys are already delivering malicious code continuously. Security can respond faster by working within the DevOps patterns.
    • Security can a learn a lot from the DevOps propensity for smart automation.
    • The DevOps model really can be compatible with compliance.
    • The DevOps paradigm shift may give security pros the opportunity to finally bake security into IT processes rather than add it on as an afterthought.

    We will be distributing printed copies of the book at the DevOps Connect event at RSA Conference this week, as well as at a special Rugged DevOps Breakfast Tuesday morning at Jillians.  But you don’t have to be at RSA to download your own copy. Fill out the form below to download a copy.

    The Ebook is sponsored by Evident.io and Incapsula. Thanks to them for their support.

    Enjoy!

    Download Rugged DevOps Ebook

    • This field is for validation purposes and should be left unchanged.

     

    *downloading the Ebook will add your email to our newsletter mailing list which you can opt out of at anytime.

  • Rugged DevOps Breakfast @RSAC

    Rugged DevOps Breakfast @RSAC

    In April devopsy.kinsta.cloud will highlight the intersection of DevOps and Security. We will be hosting DevOps Connect: SecDevOps @ RSA Conference on Monday, April 20 with Gene Kim, Josh Corman, Jez Humble and others scheduled to speak.

    We are also releasing the devopsy.kinsta.cloud authored EBook, Rugged DevOps. The EBook will look at what role security can play in DevOps. It features interviews with several leaders of the community.  Copies of the EBook will be given to all attendees of the DevOps Connect: SecDevOps event and be available for download on our site.

    Rugged DevOps Breakfast @RSAC

    Today we are announcing an additional RSAC week event in conjunction with the release of our Rugged DevOps EBook.  The first Rugged DevOps Breakfast. The breakfast is free to anyone who pre-registers here. All attendees will receive a copy of the Rugged DevOps EBook as well.

    A great way to kick off the first day of RSA Conference and to celebrate the release of our EBook.  Hope to see you in San Francisco!

    The Rugged DevOps Ebook and breakfast is sponsored by:

    evident.io

    incapsula

    Details:

    Date and Time: Tuesday August 21, 8am- 10am

    Place: Jillians  @the Metreon, 175 4th St, San Francisco, CA

    Menu: Full breakfast buffet

    Eventbrite - devopsy.kinsta.cloud Presents Rugged DevOps Breakfast @ RSA Conference

    or register right here:

    (if the button doesn’t work, here is the link: Registration link: https://www.eventbrite.com/e/devopscom-presents-rugged-devops-breakfast-rsa-conference-registration-16228701483)

  • Busting The 4 Biggest DevOps Security Myths

    Busting The 4 Biggest DevOps Security Myths

    Last month when the IT security world convened in San Francisco for the annual RSA confab, a number of security experts tackled DevOps in talks that covered the crossover between continuous improvement and risk management. Among them was a lively panel mythbusting some of the most prevalent misconceptions about DevOps held by the security community.

    Moderated by Dwayne Melancon of Tripwire, the panel was made up of Josh Corman, CTO of Sonatype, Nick Galbreath, vice president of engineering at IPONWEB, Gene Kim, author of The Phoenix Project, and David Mortman chief security architect and distinguished engineer for Dell Enstratius, all of them security professionals and very active DevOps evangelists. The banter backed-and-forthed between the participants, with four myths bubbling to the surface as particular highlights from the discussion.

    Myth #1: DevOps Pace Will Leave Security In The Dust

    One of the most prevalent myths about DevOps within the security community is that the rapid deploys of the approach will throw all risk management precautions to the wind and leave security practices behind as a result. Quite the contrary, panelists argued. They believe that DevOps patterns make it more possible than ever to bake security practices into IT processes more than before, when it is frequently bolted on “at the end of the caboose,” as Galbreath puts it.

    “You’re not throwing out your current security system,” he said. “What you’re doing is removing a lot of the junk work that eats up so much time and keeps people underwater. You’re really enabling different teams to all improve security together.”

    As Corman explained, security people say all the time that complexity is the enemy of security.

    “It also happens to be the enemy of stability,” he said. “That is the reason DevOps people come willingly with open arms to the security community.”

    Not to mention, Kim added, “because you can’t be highly available and have stuff coming continuously through the pipeline if it is not secure.

    Myth #2: DevOps Destroys Compliance And Control Frameworks

    This myth came up during the audience Q&A portion of the panel, where one audience member from the financial industry wondered at how possible it would be to institute DevOps in a highly regulated industry. According to Mortman, as seemingly chaotic and fast-and-furious as the DevOps pace can seem to the uninitiated, it is actually far more process-oriented than people realize.

    “People say ‘Oh, there’s no process to this.’ But it is actually very process oriented,” he said. “It’s just not very bureaucracy-oriented. There’s not a lot of paperwork. In its very guts, it is very service-oriented and very delivery-oriented.”

    As he puts it, every compliance framework in the planet says you need to log, audit and approve changes. But none of them stipulate a workflow where each change has to be approved one at a time.

    “The workflow can be ‘Please approve the following list of actions that I can do without notifying you first,’” he explained, “and as long as you have an audit trail showing that that has been done properly, I have yet to meet an auditor who will not buy into that.”

    Myth #3: DevOps Gives Developers Too Much Power

    Many dyed-in-the-wool security pros fear DevOps because they believe it is a cowboy environment that gives developers too much power.

    “I’ll be honest, when i first started observing DevOps patterns, developers doing their own deploys seemed immoral to me; irresponsible, reckless, just shouldn’t be done,” Kim said. “No sane person would want to be associated with that, right?”

    The thing was, after Kim dove in and also did a benchmark study with Tripwire several years ago across 4,000 organizations, he found that when comparing groups where ops did the deploys to those where developers shepherded code through deploys, change success rates and mean time to repair were not adversely affected, and in fact, “it is often considered indispensible that developers take code all the way through the deployment pipeline and you know they are getting great outcomes.”

    And from a security controls perspective, the truth is that in a DevOps situation developers “are not logging individually into each server and SSH’ing the code up, untarring it and installing it,” Mortman said. Instead these actions are being done by automated systems.

    “They’re actually going to give you much better timestamps, much more accuracy, and more consistent results and visibility than a manual process being done by someone in ops,” Mortman said. “So, actually, you’re getting better change management out of that system than you are in other situations.”

    Myth #4: DevOps Cuts Important Testing

    One discussion point also brought up during audience Q&A was the possibility that DevOps would somehow excise important testing functionality from the IT process. The panel quickly put that one to bed.

    “You can do bad testing in any model,” Corman said. “If DevOps starts eliminating any kind of testing, its a bad DevOps program. I think that’s orthogonal to some of the benefits or opportunities of DevOps.”

    Kim pointed to Google as an example of how testing fits into the DevOps methodology.

    “So, Google does about 5,500 code commits per day, they have about 15,000 software engineers, and 75 million hours of testing is run each day,” he said. “You can’t get that massive amount of deployment frequencies without a tremendous amount of testing.”