devopsy.kinsta.cloud

Tag: devsecops

SecOps: The Next Stride for DevOps
Global IT spending is now touching a figure of $4 trillion. In today’s technology-intensive environment, data is the biggest commodity, more valuable and powerful than ever. And like Peter Parker’s uncle Ben noted, “With great power comes great responsibility.”

Security has always been a big concern for valuable things and IT is no exception. IT as a whole is trying to push security left in the development cycle—trying to involve it in every step of the development cycle. And just when development and operations teams are getting used to the “esprit de corps” we call DevOps, I think it’s time we add the third musketeer: security.

What is SecOps?

SecOps is a collaboration between security and operations teams, just like development and operations teams collaborate on DevOps front. SecOps is a set of practices organizations need to follow, processes they need to execute and tools they need to use to ensure the security of their application environment. SecOps is making sure organizations do not sacrifice security to attain set performance and uptime indexes.

In a typical development cycle—requirements gathering, design, development, testing, implementation or deployment and maintenance—security normally is introduced in the later stages, somewhere between testing and deployment or even later. But SecOps is all about making sure to introduce aspects around security much earlier or at each stage of the software development life cycle (SDLC).

I know what you are thinking: This is going to complicate things and increase the time to delivery. This is where operations and development teams need to join forces to uncomplicate the things and make it time efficient practice. Next thing you must be thinking of is, Why so much hassle? Think of it the other way. Wouldn’t it save more time when you address the security concerns at much earlier stages than at the time of delivery or implementation? All it takes is an amalgamation of the security group, development team and operations team; a little bit of planning; and a whole lot of execution.

SecOps + Containers

Containerization is slowly but steadily moving from an alternative to full virtualization to a serious platform for running your applications. Containers have some obvious advantages including scalability and flexibility, and this solves most of the problems related to resources in case of application development. Reduced size; reduced time to provision application environment and testing; platforms including Docker, Solaris Zones, BSD Jails; and orchestration platforms including Kubernetes, CoreOS Fleet, Amazon ECS and OpenShift make containers a more preferred option for application development environments.

This increased traction toward containerization points to the increased need to concentrate on security aspects. Here are some best SecOps practices for container environment you and your organizational teams can follow:
- Authentic sources and images: Always check for authenticity of container images. There are various tools such as Docker’s security scan. With Docker Cloud and Docker Hub you can scan images to check for potential security vulnerabilities. Most images are built from some base image and not built from scratch, so there is always a threat with the used images.
- Vulnerability management tool: There are tools available in the market to analyze container image formats and libraries for threats before you actually start using them.
- Follow benchmarks and hardening guidelines: Always make sure you do the checks and follow hardening guidelines for containers, images, hosts and platforms before you start with production. There are few standards and benchmark checks for containers such as CIS’s Docker security benchmark, PCI compliance checklist, etc.
- Periodic auditing: Regular auditing of your application environment can help you save yourself from the future troubles. Moreover, automation of auditing process can help in detection of unused images and containers.
- Use of management frameworks: Use frameworks that can automate behavior profiling and control all the users, authorize the access to the containers, images and hosts.
- Security built in to container engine systems and third-party security solutions: Third-party vendors have a number of applications for container security in addition to security systems of container management platforms.
Dev + Sec + Ops

With the continuously increasing business demands for new applications and software, and new practices and development trends such as DevOps, Agile, cloud, automation, CI/CD and others, traditional security needs to upgraded in the new paradigm. Thankfully, some of these practices facilitate the security. Consider CI/CD as an example: Continuous integration requires continuous integration tools, or what we call build servers. Some popular examples are Jenkins, TeamCity, GitLab CI, Travis CI, Bamboo, Go CD, CircleCI and Codeship. The best SecOps practice is to check and fix vulnerabilities at early stages as a part of CI/CD workflow. Integration between authentication, scanning, management tools and CI/CD pipeline tools could be the best possible solution to your security-related problems. Some easy-to-implement solutions can include automated security testing, static code analysis, authentication checks and login tracking.

SecOps enable organizations in lifecycle management, analysis of security threats, incident management, optimizing and measuring the effectiveness of security controls, reduced breach response time, reduced security risks and increased business security. The basic principle on which SecOps works is Avoid, Analyze, Respond, Review, Repeat. By analyzing the security events and data, you can build incident response plans to avoid future unwanted events.

Frameworks and Tools

Now that you have a clear understanding of why you need your security, development and operations teams to work together, let’s see what tools and frameworks you can use.
- Docker-native tools: If you are using Docker as a platform then you can use few security tools provided by Docker itself for the security of production environment: Docker Bench and Docker Notary. Docker Bench is a script that checks common best practices around deploying Docker containers in production. Docker Notary enables you to check whether content is from a trusted publisher.
- Chef: Chef provides different tools including Inspec to automate security testing.
- Puppet: Puppet provides security compliance and policy defining frameworks.
- Ansible: Ansible provides system tracking, setting up firewall rules, user lockdown and compliance automation solutions.
- CoreOS Clair: CoreOS Clair is an open-source project for vulnerability analysis in applications and Docker containers.
- SaltStack: SaltStack can help in orchestration and automation of security practices solutions for containers.
This is just a look at some of the most popular ones. If you want, there are a number of others that can look after the security of your application environment.

The main motive behind implying SecOps practices in any organization is involving security team at all possible stages to remove any ambiguity in any stage of development rather than security team providing analysis reports to the operations team and then sitting back and enjoying the show. When these teams perform in a synergistic manner, the business focus can be shifted to other important things.

About the Author / Chaitanya Jawale

Chaitanya Jawale is founder and CEO of Opcito Technologies, a leader in microservice-based product engineering and automation. Chaitanya comes with strong background in product engineering, data center automation, DevOps and multi-cloud orchestration and management.
August 14, 2017
Jenkins World: Q&A with CloudBees CEO Sacha Labourey

The Jenkins Community and DevOps professionals around the world are excited for Jenkins World, coming up in just a month, Aug. 28-31 in San Francisco. CloudBees, the hub of enterprise Jenkins and DevOps, is the lead organizer and premier sponsor of the event. We sat down with CloudBees CEO Sacha Labourey to discuss everything Jenkins World.

NOTE: If you haven’t registered yet, there is still time! devopsy.kinsta.cloud readers can register now with the code JWDEVOPSCUST and get 20 percent off.

Q: How has Jenkins World evolved since its inception?

A: It’s been quite the journey since the beginning of Jenkins World. The very first Jenkins World was back in 2011. We had 200 people attending and we were extremely proud of that. The Jenkins project was still new, as it had just changed its name in 2011, so we were excited to see the community already coming together. Fast forward to 2017 and we’re expecting about 2,000 attendees at this year’s event. We’ve grown 10x since the first show and even from last year to this year we’re expecting almost 50 percent more attendees. It’s been great watching the conference mature and grow over the years. 2017 will be our best show yet!

Q: What’s new at Jenkins World this year?

A: This year we’re expanding everything, covering a wide range of topics including DevOps culture, process design, automated testing, performance measurement, security, leadership and more. We’ve added a welcome reception and evening event in the expo hall so attendees have more opportunities to network and learn from each other.

Additionally, we’ll be kicking off the first-ever annual Jenkins World Awards. These awards recognize the achievements of CD innovators and Jenkins contributors from around the world. There are two award tracks: Jenkins Community Awards and CloudBees Innovation Awards. Winners in each track will be featured at Jenkins World.

Q: What can attendees expect from the keynotes?

A: We have a great lineup of keynotes this year, including myself! My keynote will be a state of the union that looks at what’s happened in the last year, what worked, what didn’t work and what we’ve learned from it. Stemming from that I’ll also offer a vision for the future. This will be actionable, and practical—something we can truly act on. I’m excited to say that there will be some significant announcements throughout the week as well.

Kohsuke Kawaguchi will also be keynoting. His keynote is always excellent. He’ll offer a state of the union from the Jenkins community angle. He’ll go over the evolution of the Jenkins project and run through the latest numbers. It’s such a pleasure to watch him on stage each year; his talks are always exciting.

We’re also thrilled that Jez Humble will be keynoting this year. He literally wrote the book on DevOps, so if you’re looking to learn about DevOps, he’s the man you want to hear. He’ll be discussing the DevOps market, challenges, opportunities, the evolving requirements and needs of DevOps professionals and more.

Q: What advice do you have for first-time attendees?

A: My advice is: Take advantage of the trainings, workshops and certification opportunities. Last year, workshops and training were a huge success, so we’re offering even more this year. It’s a great way to further your career. It’s very hands-on and provides an opportunity to show tangible results of how the conference helps you improve your skills and ultimately helps your career.

Also, make sure to network with fellow professionals. It’s the perfect time to find out how others are approaching their projects, what challenges they faced and how they’ve overcome them. It’s such a great community of professionals to learn from.

Q: Are there any sessions you recommend?

A: I’d certainly recommend checking out some of the specialized vertical sessions. For example, we’ll have a number of sessions that focus on the financial services industry with speakers from Capital One, PayPal and more.

We’ll also have some great DevSecOps presentations. It’s a very hot topic and is increasingly important in DevOps. I’d highly recommend attendees get to at least one of these sessions.

Finally, there will be several sessions focused on testing—which often adds the most friction to delivery pipelines. These sessions will prove really helpful for attendees looking to enhance their testing processes.

There you have it! This year’s show is bound to be bigger and better than ever before. Register now with your 20 percent off code: JWDEVOPSCUST.

— Alan Shimel

August 4, 2017
Survey: Inviting Security into DevOps Promotes Effective Agility

Two of the biggest trends in business technology are seemingly at loggerheads with one another. Many companies are under severe pressure to digitally enable their businesses. At the same time, the need for hardened application security has never been more critical than it is now. You can deliver apps quickly and you can deliver apps securely but, generally speaking, the two things don’t happen at the same pace. The DevOps mission is aligned more with development efficiency and agility, but it’s also in keeping with the thinking behind DevSecOps. How are enterprises handling the conundrum?

According to a new survey from identity and encryption enterprise vendor DigiCert, they are handling it quite well. The recently released “Inviting Security into DevOps” survey found that 98 percent of respondents said their companies are integrating their security teams into their existing DevOps methodologies. The survey found that 49 percent of the respondents are in the process of doing so; the other 49 percent have already done so. Those who report having already integrated security with DevOps are 21 percent more likely to report what might seem counterintuitive: They are doing well at meeting app delivery deadlines.

“Successful security for DevOps requires a combination of culture building and the right technology,” said DigiCert CSO Jason Sabin. “Companies that can do this and bring in security at the start of a project avoid costly delays, because they deliver their project just once rather than discovering security issues late in the process.”

The methodology for the survey, which was conducted in May, involved 100 DevOps professionals, 100 IT professionals and 100 security professionals with executive management to management titles skewing 3:1.

The large enterprises polled for this survey agree it’s worth striving for. Some 88 percent of the respondents called security working directly with DevOps somewhat or extremely important. More than 70 percent of the respondents are concerned that if their companies don’t make this change, one or more of these negative repercussions are likely: increased costs, slower app delivery and increased risks.

Although nearly all the respondents have integrated or are integrating security within DevOps, they’re not saying it is an easy process. Their top challenges include a lack of a champion for the transition, the security team resists the change, lack of relationship skills required to bring the teams together and it takes much more time than expected—an average of one to two years.

How should you approach this in your company? First, recognize that it’s no panacea. It’s a logical first step, but don’t spend a year planning it, just do it. Start by appointing or identifying a leader for the project. Someone who understands both sides, ideally, and who knows how to get things done. And install a security lead at the DevOps table for all DevOps business. Integrate, standardize and invest in automating baseline security practices within DevOps workflow. Thinking that way will get you the agility you need.

Then address what comes next. Have the team identify choke points in the application security process and develop ways to work around them or eliminate them. In other words, attack the problem head on with all your best minds. Don’t forget to look for best practices developed by others. It’s a problem a lot of companies are trying to solve, so networking with people from other companies at industry events may give you your best ideas.

— Scot Finnie

August 2, 2017
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

July 21, 2017
Barracuda Networks Enhances API to Advance DevSecOps

Recognizing that DevOps teams deploying applications in the cloud need a more sophisticated approach to security, Barracuda Networks at the Microsoft Inspire 2017 conference unveiled an enhanced REST API for its Web Application Firewall (WAF), in addition to providing integration with the IT automation framework developed by Puppet Labs.

At the same time, Barracuda Networks revealed that it has integrated all of it firewall offerings with the Microsoft Operations Management Services running on the Microsoft Azure Cloud. Finally, Barracuda Networks announced it is now including a software-defined wide area network (SD-WAN) capability with the Barracuda NextGen Firewall platform.

Tim Jefferson, vice president of cloud for Barracuda Networks, says the REST API the company is exposing in its WAF enables IT organizations to better manage security within the context of larger DevOps environment. As part of that effort, Jefferson says, Barracuda Networks also plans to integrate its WAF offering with other IT automation frameworks.

Jefferson says many IT organizations are discovering that public clouds are more secure than on-premises environments because of the level of security and instrumentation that cloud service providers now routinely include. For example, cloud service providers make it easier to track unusual API calls that might indicate an IT security breach or even an attack in progress. Those capabilities, says Jefferson, make it easier for vendors such as Barracuda Networks to provide more visibility into what’s occurring in a public cloud than what’s generally feasible on-premises.

However, each cloud service provider has its own unique network stack that requires security tools to be optimized for each platform, says Jefferson. Because of that issue, most IT organizations have not had the security wherewithal needed to rise beyond adopting more than one public cloud service in their production environments, he says.

In general, Jefferson says, developers are not likely to consume security technologies on a public cloud that can’t be invoked via an API. Because of that issue, many IT organizations are discovering that the security platforms they have employed on-premises simply can’t be lifted into the cloud. That issue, he says, creates a level of friction inside the organization that inevitably hampers usage of cloud platforms more than any other challenge an IT organization faces. Cloud applications require a DevSecOps approach that developers will view as a natural extension of existing DevOps processes, says Jefferson.

To achieve that goal, organizations need to make it easier for developers to secure their applications and invite IT security experts inside their organization to participate in, for example, scrum teams that collaboration build, deploy and manage applications. In fact, Jefferson notes most DevOps teams don’t even want to talk to a vendor’s sales representative; they prefer to be able to download code that they can test and deploy on their own before committing to buying a license.

It’s still relatively early in terms of appreciating the impact DevSecOps will have on improving IT security. But one thing is clear: IT security vendors that don’t make it simple for developers to invoke the capabilities they provide soon will be left behind.

— Mike Vizard

July 18, 2017
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 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 devopsy.kinsta.cloud’s DevOps Chat and we’ll see you on the next chat.

— Alan Shimel

July 10, 2017
Signal Sciences Looks to DevSecOps to Improve App Security

The time has come to put control over IT security into the hands of the developers who increasingly are being held accountable for it. To make that possible, Signal Sciences has launched a Web Protection Platform (WPP) capable of inspecting traffic in real time across multiple deployment models.

Intended as a replacement for more traditional web applications firewalls (WAF), WPP redirects any suspicious traffic to a cloud analytics engine without adding any meaningful overhead in terms of overall latency, says Signal Sciences CEO Andrew Peterson.

What makes WPP unique, he notes, is that it can be deployed in three different modes. When deployed on a local server, no changes to the application code are required. WPP also can be deployed as a reverse proxy in from of a web server. But from a DevSecOps perspective, the most flexible options is to deploy WPP in a runtime application self protection (RASP) mode that allows developers to embed WPP directly into their source code. In the later instance, Peterson says developers can assume security responsibility for their own applications, in keeping with process employed by organizations that have implemented advanced DevOps processes.

Peterson says WPP not only provides protection against the top 10 most common web applications threats, but it also thwarts distributed denial of service (DDoS) attacks, account takeover and even attacks employing malware embedded in custom business logic.

Regardless of the delivery model, Peterson says it’s become apparent that legacy WAF are not able to secure modern applications based on containers and microservices, Embedding WPP in application source code enables developers to embed a cybersecurity defense mechanism in each container-based microservice in a way that scales over time.

As part of its commitment to DevSecOps, Signal Sciences has created 16 pre-built integrations with a range of third-party DevOps tools and security technologies, including Atlassian JIRA software, Datadog, PagerDuty, Slack and Splunk. In addition, DevOps teams can take advantage of an application programming interface (API) that Signal Sciences has developed to integrate WPP with other applications.

Of course, the whole DevSecOps movement is only in its infancy. Most IT organizations are still struggling with the concept. It’s also not clear how much IT security professionals will be comfortable relinquishing control over application security to developers. However, Signal Sciences claims that 95 percent of its customers have implemented automated blocking, versus only 10 percent to 15 percent of IT organizations that have implemented a WAF.

Signal Sciences is betting that in much the same way they now exercise more influence over IT operation, developers will play a much larger role in IT security. In fact, as developers are held more accountable for application security, Peterson says many of them will demand to be able to programmatically implement IT security controls. Naturally, there’s no such thing as perfect security. But is the case of application security, DevSecOps may turn out to be our only hope.

— Mike Vizard

May 17, 2017
I Can’t Go to That DevOps Conference

Last year, I was able to attend 18 DevOps conferences. I saw some awesome presentations, met incredible people and expanded my knowledge of the latest practices at each conference. While my role as the DevOps Advocate for Sonatype enables me to get out to all of these conferences, not everyone has the time, the budget, or the approval to get to even one event a year.

DevOps for the Masses

This is what led me and my colleague, Mark Miller, to found the All Day DevOps conference last year. Our dream was to build a DevOps conference for the masses. We decided to offer 57 online sessions over 15 hours and 15 times zones, and registration would be free. Our initial goal was to see if we could find 1,000 people to attend (because that sounded like a big number at the time), but the idea of a free online event caught a viral wind and we ended up having over 13,500 people register to attend.

Every session delivered during the conference was shared by a DevOps practitioner. We had a simple rule for the conference and that was: no vendor pitches.

Team Time

People also told us that they valued having the chance to talk to other attendees they met at DevOps conferences, so we set up a free Slack channel for All Day DevOps. By the time conference was over, we recorded more than 10,000 conversations between the speakers, attendees and organizers.One of the things that fascinated us most about the conference was that organizations such as Accenture, Capital One, Ericsson, Oracle, Target, Telstra and many others had more than 20 employees attending the event. A few of these had hundreds. None of them needed to approve expenses for travel, hotels or conference fees. They just watched and joined in the conversations from their homes or offices.

Here are some of the folks who spoke at last year’s event across our CI/CD, Modern Infrastructure and Automated Security tracks. This year, we have also added a DevOps in Government track to the agenda.

The event was so successful, we set it on the schedule again. All Day DevOps 2017 will take place Oct. 24. It’s online, it’s free and this year’s event will run for 24 hours. Therefore, no matter where you live, if you have an internet connection, you will be able to tune in to join us.

A Few Things to Know

1. You can register for free at www.AllDaydevopsy.kinsta.cloud. Invite your entire DevOps team to join. Everyone registering will have free access to all 57 recorded sessions from 2016.

2. The CFP is open through May 31. If you have a story to share, we want to hear from you. Remember, no vendor pitches are permitted.

3. All Day DevOps is a community event. Last year more than 40 DevOps meetups and software companies helped us spread the word. For those that helped, we added their logo to the site. Same applies to this year. Apply to be a supporter here.

Please join us for this year’s event!

Finally, a big thank you goes out to devopsy.kinsta.cloud, which helped us promote last year’s event to all of their readers. We are excited to have them helping us to promote the 2017 conference as well!

— Derek E. Weeks

May 9, 2017
From Architect to Operator: The Rise of Developers
Over the past five years, DevOps has transformed from a model for agile software development practices to the aspirational standard for functions across the IT spectrum. Previously, developers and IT Ops teams were distinct and siloed—developers built the application and IT Ops managed production environments—but now many in the industry have shifted to create a net-new liaison between the two, allowing applications to exist simultaneously in the worlds of development and production.

While everyone is focusing on the convergence and collaboration of the developer and the IT Ops person, however, the storyline is changing again. The focus is now shifting back to the developer (and his/her specific skill sets), as there’s an increased demand for a single team to manage the entire application life cycle. Now more than ever, the people who actually develop the systems are poised to take ownership of traditional IT operations functions, such as maintenance, performance and availability.

As IT continues to evolve, three trends point to the expanding and evolving role of the developer.
1. The decoupling of infrastructure from services. With the rise of public and private clouds, more of the technology stack is becoming abstracted away from infrastructure, and often offloaded to a provider. This has created challenges for how developers manage and deliver applications in this new environment. In the past, IT operations was responsible for ensuring things such as availability and performance, but now, developers can build those capabilities into the applications themselves.
2. The elimination of infrastructure setup. IT Ops roles have traditionally been the gatekeepers, and new technologies didn’t make their way into the data center if it didn’t pass their standards. Getting into the data center was just the first step, though, as lengthy deployment of physical infrastructure and provisioning of virtualized instances for applications would require substantial expertise and time. Now, developers can spin up services instantaneously, and infrastructure setup has been reduced to a simple configuration file. It is the developer who understands which resources the application will need, and with infrastructure reduced to a couple lines of code, the speed at which it can be applied is impossible to ignore.
3. Microservices create fault tolerance. How we’re building applications also greatly impact how they will run in the future. Historically, you would build a single monolithic service that would respond to every request from the users of that application. This approach meant that when a part of the service failed, everything would go down. However, when you abstract away the infrastructure, you gain the ability to decentralize the application or service into many loosely coupled microservices. This makes the application much more fault-tolerant and reduces the impact of an outage or shortage of resources. As such, developers can help ensure system continuity and performance by building resilience and monitoring capabilities into the software.
End-to-End Visibility and the Need for IT Ops Persists

While developers are certainly on the rise, the role of IT Ops remains uniquely necessary in today’s IT environment. IT Ops will always have the best end-to-end IT system perspective, encompassing the application environment as well as shared services and infrastructure (think backup, endpoint protection, single sign-on, DNS, etc).

Developers build visibility from the inside out. But because it’s happening in the app itself, there’s no outside-in look, and thus pieces of the stack go unmonitored. As a result, you can’t understand the holistic end-user experience—which, when it comes to application health, is both the start of the conversation and the end of the argument. IT Ops brings incredible value, offering end-to-end visibility with better monitoring and a focus on ensuring every transaction—both internal and external—goes smoothly. While it has become common for developers to instrument their applications, they don’t have nearly as much expertise in end-to-end service management and measuring performance across each component. Additionally, IT Ops workers tend to possess a great level of operational rigor; they’re better versed in dealing with third-party vendors; and they understand the entire system (the weakest link, what works, what fails, etc.), including back-end functions, in a way that developers simply don’t.

What Comes Next for Developers?

We’re already seeing how developers are taking greater control over traditional IT operations functions, but what comes next? Looking forward a few years, I believe the next frontier to monitor is the role developers will play in SecOps. Security attacks are about finding the path of least resistance, and as SecOps matures into active threat-hunting and breach detection, attackers will evolve their methods. If SecOps can solve current attack vectors—phishing, especially—tricking software into following unexpected code paths will once again be a reasonable route to a breach.

But there are ways to mitigate that during the development process, by building security into the code itself. As SecOps teams increasingly treat the environment as an ecosystem, they’ll see the application itself as a vulnerable piece of the attack surface; they may begin requiring secure development practices with a level of governance over development teams. As security increasingly becomes everyone’s job, everyone in IT must shift their mindset, and while development teams may be late to the party, SecOps will eventually extend a mandatory invitation.

About the Author / Eric Thomas

Eric Thomas serves as Director of Solutions Architecture for IT analytics company ExtraHop. Eric leads the Professional Services team, and draws on over 20 years of experience in IT operations. Before joining ExtraHop, Eric performed a variety of operational roles, most recently as Director of Advanced Engineering for Thomson Reuters, where he led a team of performance and availability specialists, supporting over 200 applications representing $2B in annual revenue. His prior experience includes Enterprise IT management, SaaS production operations and next-generation technology advocacy.
May 4, 2017
DevSecOps @RSAC, My 2 Favorite Presentations

For the third year, devopsy.kinsta.cloud hosted a DevSecOps/Rugged DevOps event at RSA Conference. As with years before, we smashed attendance records. We had just shy of 900 people stop in on Monday of RSA Week to hear from the 11 presentations we hosted. Taken in total, the presentations presented a wide range of DevSecOps issues. I wanted to draw your attention, though, to two of the presentations that I really enjoyed.

First of my favorite presentations

The first was from someone I had not met before who came to our attention via our call for speakers. Duane Schleen presented, “Implementing DevOps in a Regulated Environment: The Aetna Experience.” His presentation is below:

Why did I love this presentation? Good question. First of all it is rare that we get such an open peak behind the kimono at the actual inner workings of an enterprise, especially in such a regulated industry as insurance.

More than that though I am telling you that Duane Schleen or DJ as he is called is going to be a DevSecOps rock star. Can’t wait for him to write a few articles for us here at devopsy.kinsta.cloud. If you get a chance to see him speak at a conference near you, jump at it. Can you tell I am a fan?

On top of this the look Schleen gives us into DevSecOps at Aetna shows that despite the naysayers, you can go faster, with higher quality and be more secure!

The Second Presentation I loved

The second presentation I wanted to bring to your attention was the opening keynote by John Willis. Most of you have probably seen John present before either live (if you are lucky) or on line. John is of course a co-author of the DevOps Handbook as well.

John’s presentation is entitled, “Breaking Bad Equilibrium”. It is about cooperation in DevOps, technical debt and uses some game theory to explain some of the John’s thoughts.

My favorite part is when John uses some clips from the UK game show “Golden Ball” to discuss Nash Equilibrium (or prisoners dilemma ) and game theory. Both clips really grab you and make you think (as many of John’s presentations do). I will let his presentation speak for itself though.

Beyond, these two excellent presentations, you can see the rest of the presentations from our DevSecOps event at RSA Conference this year on our DevOpsTV channel on YouTube. The link takes you to the playlist with all 11 presentations.

This years DevSecOps event at RSAC was a smashing success with almost 900 people stoping in to hear some of the excellent presentations. It did this authors heart good to see this great mixing of the DevOps and security tribes coming together.

— Alan Shimel

March 29, 2017