devopsy.kinsta.cloud

Tag: devsecops

  • 42Crunch Extends API Security Alliance With Microsoft

    42Crunch Extends API Security Alliance With Microsoft

    42Crunch this week announced it has extended an existing alliance with Microsoft to now include support for Microsoft Azure Pipelines for its REST API Static Security Testing Tool. Previously, 42Crunch only provided support for the Microsoft Visual Studio integrated development environment (IDE).

    Dmitry Sotnikov, chief product and marketing officer for 42Crunch, said support for the Microsoft IDE assumes that developers will run security tests themselves. By integrating its API security testing tool with the Microsoft continuous integration/continuous delivery (CI/CD) platform, it now becomes possible to make testing APIs for security vulnerabilities part of a DevOps process, he said.

    That approach means organizations don’t have to rely on developers to remember to run a security test on their APIs. Instead, security testing of APIs becomes just another gate in the CI/CD process that gets automatically conducted, he noted.

    The company has already integrated its API security testing tool with other CI/CD platforms at the request of individual customers. 42Crunch will be moving to make those integrations commercially available in the months ahead, said Sotnikov.

    As IT organizations have become more adept at thwarting attacks aimed at end users, cybercriminals are now increasingly focusing their efforts on APIs. Akamai, a provider of content delivery networks, recently reported that from December 2017 through November 2019 it observed 85,422,079,109 credential abuse attacks across its customer base. Nearly 20%, or 16,557,875,875, of those attacks were against hostnames that were clearly identified as API endpoints. Many of those attacks involve, for example, unexpected injections of values to a call made to an API, noted Sotnikov.

    The REST API Static Security Testing Tool can locate API contract files in the repository and run more than 200 security checks based on OpenAPI standard requirements, authentication, authorization and data validation. This makes sure that no new or changed API be deployed in production without meeting those standards.

    Issues discovered are also prioritized by impact and each issue is accompanied by a knowledge base article explaining the issue, its severity, exploit scenario and suggested ways to fix it.

    Sotnikov said the REST API Static Security Testing Tool provides a tangible means for DevOps teams to embrace best DevSecOps processes. Too much of what passes for DevSecOps today amounts to little more than attempting to blame developers for cybersecurity issues, he noted, adding organizations that want to embrace DevSecOps in a meaningful way need to put tools into the hands of DevOps teams that enable them to address vulnerabilities once they are discovered and prioritized.

    It’s also critical to provide those tools within the context of existing DevOps processes; otherwise, developers are likely to resist changes to their existing workflow processes, Sotnikov said.

    It remains to be seen how DevOps and cybersecurity teams will meld their respective cultures to drive DevSecOps. It is likely cybersecurity teams will continue to define controls and discover vulnerabilities. However, as DevOps teams continue to make security a natural extension of the quality assurance process associated with building any application, the number of vulnerabilities being discovered after an application is deployed in production should decline steadily.

    — Mike Vizard

  • The DevOps Sweet Spot: Inserting Security at Pull Requests (Part 2)

    The DevOps Sweet Spot: Inserting Security at Pull Requests (Part 2)

    In part one of this two-part series, I explored how organizations can more effectively automate security quality decisions and discard doing automation for automation’s sake. I shared why security scans need to be faster, more reliable and comprehensive. Only then can security be meaningfully automated into developer workflows without slowing them down.

    But, the other part of this is understanding where these security scans should take place throughout the SDLC. Why? Because inserting security too early or too late in development and pre-production can have drastic impacts on remediation efficiency, developer productivity and more. 

    Shifting Security as Far Left as Pull Requests

    Identifying vulnerabilities once they’re in production is the riskiest, as well as the most time-consuming and expensive remediation. Working in pre-production test environments or builds reduces the risk, but not much of the time or efficiency in remediation. Conversely, inserting code analysis into developer IDE’s is too early. While in theory the IDE could be a good place for security feedback, in practice, it slows down the developer’s machine and comes at a huge cost of productivity.

    Instead, commits and pull requests are the ideal place to insert security because it delivers the right vulnerability information to the right developer at the right time. Combine this with integrations into ticketing and other systems and the full developer workflow can be meaningfully automated.

    Simply by getting the right developer, the right vulnerabilities information breaks down one of the biggest challenges in AppSec. Developers typically outnumber AppSec team members by 50-1 or more—hence a security scan that generates 100 vulnerabilities creates a tremendous amount of work for a single AppSec professional. However, assigned to the right developers, at an average of two per person, the challenge immediately becomes more manageable. Still accuracy matters because, while the burden may be spread out, developers triaging false positives is an expensive resource focusing on a low value task.

    Getting developers security feedback at the right time is also vitally important. When developers get immediate security feedback, vulnerabilities become easier to fix because the code is still fresh in their mind. Furthermore, fixing vulnerabilities early has compounding benefits. Since insecure code never goes into production, not only is the attack surface reduced, but additional code that is dependent on the vulnerability never gets written. This minimizes the most expensive and time-consuming security fixes, which require not only fixing the underlying vulnerability, but also rewriting dependent code. Best of all, with immediate, regular, comprehensive and accurate security feedback, developers will ultimately learn and adopt more secure coding practices overtime.

    Lastly, by inserting security at the commit or pull request, security and developers can establish a shared responsibility model on more realistic terms. When security can commit to accuracy and timely KPIs, developers can commit to triaging and fixing vulnerabilities faster. This reduces MTTR, puts a downward trend on defect density and reduces the application’s overall attack surface. It also reflects the realities that AppSec professionals have a limited ability to triage vulnerabilities, because they don’t know the code intimately and that only developers can fix the underlying vulnerabilities.

    By solving the fundamental challenges of speed, accuracy and comprehensiveness to deliver the right vulnerability to the right developer at the right time, security earns the ability to ask more from developers, and CISOs and CTOs can jointly accept responsibility for protecting applications and data.

    The rate at which software is being created and shipped isn’t slowing down, but many organizations have struggled to find where security most effectively fits into this process. By inserting security at the pull request, not only can developers identify and remediate vulnerabilities faster and more accurately, they can better automate security quality decisions. By taking this approach, organizations are fundamentally changing how engineering and security collaborate within enterprises.

    — Chetan Conikee

  • DevSecOps Days Virtual Summit: The Best of Dev, Sec and Ops

    DevSecOps Days Virtual Summit: The Best of Dev, Sec and Ops

    We’re fresh off RSA Conference 2020 and the live version of DevOps Connect: DevSecOps Days, a daylong event packed with industry experts speaking on all things Dev, Sec, Ops and variations of the three. It was highly successful in both attendance and knowledge-sharing, so once again we’ve taken the entire event virtual and bringing it to you.

    The return of DevOps Connect: DevSecOps Days Virtual Summit will take place Thursday, March 26, at 10 a.m. EST. The all-day event will feature speaking sessions and panels focusing on digital transformation and disruption, with experts and practitioners discussing their company’s transformation to DevSecOps, the issues that have impeded their progress and how they get buy-in from all levels of the company.

    Our virtual summits are just like a real conference but without the hassle of traveling, tickets and crowds (and, this year, nasty coronaviruses). The online environment at DevOps Connect: DevSecOps Days Virtual Summit features a lobby, expo lined with booths full of downloadable resources, and an auditorium where attendees can watch sessions by Bryson Koehler and Jamil Farshchi, CTO and CISO of Equifax; Larry Macherrone, director of DevSecOps Transformation at Comcast; and other industry forward-thinkers to get an exclusive look into DevSecOps initiatives at large enterprises and organizations across industries.

    Here’s an at-a-glance lineup of our speakers:

    • Bryson Koehler, Equifax
    • Jamil Farshchi, Equifax
    • Dr. Amit Elazari, Intel
    • Jennifer Czaplewski, Target
    • Bill McArthur, TD Bank
    • Jasmine James, Delta Airlines
    • Charlene Li, author
    • Larry Maccherone, Comcast
    • Sladjana Jovanovic, TD Bank
    • Ross Clanton, executive consultant
    • Sean Davis, Equifax
    • Chris Roberts, Attivo
    • Chris Riley, Splunk
    • Alan Shimel, MediaOps
    • Mark Miller, Sonatype

    DevOps Connect: DevSecOps Days Virtual Summit is truly an all-day affair, with sessions running from 10 a.m. to 5 p.m. Eastern. The expo hall will be open throughout the event, giving attendees the opportunity to chat with vendor sponsors, download information and even take part in a scavenger hunt to win prizes including Amazon gift cards.

    Plus, those who register but can’t make the event will be able to access it later—all registered attendees will receive a link to access the virtual summit on-demand.

    Space is limited, so don’t wait. Register today for DevOps Connect: DevSecOps Days Virtual Summit to hear the best of what’s happening in the DevSecOps space from those who are actually doing it.

    — Charlene O’Hanlon

  • DevOps Chats: Sumo Logic Continuous Intelligence, with Bruno Kurtic

    DevOps Chats: Sumo Logic Continuous Intelligence, with Bruno Kurtic

    Sumo Logic has been one of the pioneers in DevSecOps and log analysis for many years now. In this DevOps Chats, we speak with Founding VP of Product and Strategy, Bruno Kurtic, about the Sumo Continuous Intelligence Platform and how it is taking security into the next era.

    Have a listen to this DevOps Chats as Bruno explains how Sumo is trying to meet the challenges of keeping up with the speed of business, today.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    [soundcloud url=”https://api.soundcloud.com/tracks/764360107″ params=”color=#ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true” width=”100%” height=”166″ iframe=”true” /]

    Transcript

    Alan Shimel: Hi, everyone, it’s Alan Shimel, devopsy.kinsta.cloud. You’re listening to another DevOps Chat. Today’s DevOps Chat features Bruno Kurtic, Founding VP of Product Management and Strategy over at Sumo Logic. Bruno, welcome to DevOps Chat.

    Bruno Kurtic: Thank you, Alan.

    Shimel: It’s a pleasure to have you here. Bruno, as we were talking off mic, I think our audience is plenty familiar with Sumo Logic, you know, they’ve been one of the—not founding, but one of the building block vendors within the DevOps and DevSecOps kind of movements. But just in case, maybe there are some people who aren’t, do you wanna give us just a quick background?

    Kurtic: Sure. So, Sumo Logic is a cloud based machine data analytics platform. We help customers collect data, telemetry, machine data, infrastructure data, application data from all of their mission critical applications and infrastructure. We process that data and provide them with a scalable and secure technology to deliver operational intelligence, use cases such as monitoring, troubleshooting, root cause analysis, security intelligence use cases such as SIM compliance, threat detection and resolution, and also business intelligence use cases for sort of understanding how their customers are using their digital services, how their products are being adopted and so on and so forth.

    So, that’s essentially what we do. We deliver this as a cloud based service, so it’s SaaS. Our customers essentially tap into our infrastructure, send us the data, and they then get to use their data and get the insights in real time.

    Shimel: And you just joined the company last month?

    Kurtic: No, I’m—

    Shimel: I’m kidding. [Laughter]

    Kurtic: I’m a Founding VP. [Laughter] So, a little bit longer than a month, I’d say maybe two months, maybe close to 10 years—here we go, right?

    Shimel: Close to 10 years. Ten years goes in the blink of an eye, doesn’t it?

    Kurtic: It does, it really does. It’s really astonishing. Sometimes, it feels like a really long time, and sometimes, it’s like it was yesterday, right? And so, it depends on the day.

    Shimel: Unbelievable. Yep. I agree. I’ve been there and done that. The last startup I did before MediaOps, I did nine years, and it just—

    Kurtic: Oh, okay, there you go.

    Shimel: I know how that goes. Anyway—so, Bruno, thank you for joining, thanks for the background. But let’s, I wanted to jump into continuous intelligence, which is, you know, kinda the phrase that Sumo Logic is gathering around. And of course, you know, in DevOps, we have continuous everything, right?

    Kurtic: Yep.

    Shimel: But continuous intelligence—continuous intelligence, excuse me. What do we mean by it? What does it mean in the terms of the way Sumo uses it?

    Kurtic: That’s a great question. And actually, sort of, this whole, the purpose of this platform that we’ve built, it really is to provide the continuous intelligence through a digital enterprise, right? And what we mean by continuous intelligence is the following.

    As you just said a couple seconds ago, in DevOps, everything is continuous, right? You continuously push code to production, you do continuous testing, continuous integration, right? And you’ve got continuous feedback from your application services that you deliver and then you take that feedback into your product development cycle and you continue to improve, right?

    When we talk about continuous intelligence, we recognize and see that in this world of high speed software development and digital economy that the data generated by production application, mission critical applications and services that serve customers and generate revenue—collecting that data is important in real time, and this data is ubiquitously applicable, right? This is not just for DevOps teams to manage the applications, it’s not just for security teams to secure those applications. This data is relevant to the entire digital business, right? It’s useful to product managers to understand how their products and services are being used. It’s useful to sales and marketing teams to understand how the customers and prospects are leveraging their digital services. It’s useful to finance teams to understand how the—what’s the cost, behavior, and other things related to those digital services.

    So, continuous intelligence, it basically refers to this continuous need for data in the business to continue to improve how it operates, how it competes, how it delivers value to the customers, how secure, how to secure those properties and so on, right? So, it’s ubiquitously applying the data that’s generated by the digital services across all those use cases.

    Shimel: Fantastic. You know, an aspect to this and an aspect to a lot of DevOps as well as DevSecOps is automation.

    Kurtic: Yep.

    Shimel: But, you know, Bruno, my time in security, if I learned anything is, sometimes, people don’t embrace automation because they’re afraid of security run amok, right? I’m gonna block the CEO’s email or I’m gonna shut down a critical application or, you know, business process.

    Kurtic: Yep.

    Shimel: So, how do you reconcile, right—and so, it’s one thing to gather intelligence, actionable intelligence, as we used to call it, right, and on a continuous basis make adjustments and stuff, but to really, to move at the speed of business today, you then have to, you almost are forced to automate, right, responses and so forth.

    Kurtic: Right, absolutely. So, you know, you bring a very valid point. Like, you know, my entire career has always been in enterprise software and the last 12, 14 years has been in this specific area of sort of monitoring and troubleshooting security. And it has always been the case that—not just on the security side, that our remediation, you know, people are scared of, it’s also on the operation side, right?

    Shimel: Yeah.

    Kurtic: You know, should I—when do I trigger auto scaling, when do I not and all this stuff, right? And, you know, we’re now getting much better at that, but you know, if you look at the history just this last decade, it has been a tricky area for enterprise to adopt.

    And so, you know—but I don’t think it’s possible to not. Like, we, just like you said, the speed of business demands that we make automated actions based on data that we are observing, and there are some insights we get from that data.

    The challenge has been, is how good are your insights, right? The tricky part is, I used to be in the SIM space, S-I-M space, so on the security side prior to Sumo Logic. And, you know, it was tricky to be able to sort of adopt full automation based on those security rules, because those security rules themselves were fragile, right?

    Shimel: Yep.

    Kurtic: They weren’t necessarily overly deterministic, you could get false positives, you could block CEO’s e-mail, you know, inadvertently and prevent something important from happening. And so, it was a—in those days, it was much harder to sort of bet on that automation, right?

    As you fast forward to now, when you apply advanced analytics—this is why we call our platform an intelligence platform. When you apply advanced analytics, you know, more sophisticated technologies like machine learning and AI, when you start sort of looking across not at individual incidents and alerts, but you start looking across multiple incidents to really have a better understanding of what’s the actual impact of these events that I’m observing, then you can start, you know, making those automated actions.

    And of course, there’s always gonna be things you will not know how to act on, right, which then goes into a wholly different pipeline that, where you enable people to understand what’s actually happening and then decide, in the future, do I wanna make this an automated action or not. But basically, as we go through this cycle of, you know, capture a new unknown, learn what it is, route it to the right place—when it becomes unknown, it gets added to that sort of automation engine, and eventually, you keep sort of reducing the number of manual steps you need to perform to run a good business, to run a secure business or whatever it might be at the use cases.

    And so, we’re not done, right? There’s still plenty of situations where you’re not gonna wanna take an automated action. But I think at this point, we’ve achieved the level of intelligence to make that automation actually be useful without hurting you.

    Shimel: It does my heart good, man. [Laughter] I gotta be honest. So, I think I mentioned to you off mic that my last startup was a security company I started in 2001, and that’s when we were making the move from, like, IDS to IPS, right? Intrusion detection to prevention, which meant automated blocking of traffic.

    Kurtic: Mm-hmm.

    Shimel: And, you know, I always thought it was a no brainer, but it really wasn’t, because the state of the art at the time was, we didn’t have an intelligence platform.

    Kurtic: Mm-hmm.

    Shimel: Right?

    Kurtic: That’s right.

    Shimel: You know, we were constantly trying and striving, but, you know, it just wasn’t there. So, Bruno, what would you—and, you know, there’s a tough one—what would you point to that has really sort of moved the needle in this evolving intelligence platform that you could say, “Hey, man, you can trust this now, right, because 99 out of 100 is making the right choices, or 999 out of 1,000.”

    What is—you know, you alluded to it, but let’s get down into it. What’s providing, what do you think triggered it? What do you think was the breakthrough?

    Kurtic: Yeah, so, I would say that it’s definitely not one thing, right? It’s multiple things.

    Shimel: Yeah. It never is, right?

    Kurtic: Exactly. So, I’d say it’s sort of, you know, there’s a few sort of things that have occurred in the last decade at least that we have done internally to bridge this gap, right? At first, the old systems were siloed. They were not scalable enough to actually be able to ingest all of the telemetry required to make these decisions, right?

    So, you have to compromise. Like, if you’re sort of familiar, since you’re familiar with IDS and IPS, you might be familiar somewhat with the old SIM systems, right?

    Shimel: Sure.

    Kurtic: The SIM systems of the old age were, you know—you have to compromise. You couldn’t scale them sufficiently to accept all the telemetry, and so, you have to continue to reduce the amount of data that you were sending into them. And when you have limited visibility, it is much harder to be able to make a deterministic decision on what you can act on automatically, right?

    We’ve built a highly scalable, cloud based microservices multi-tenant back end that can basically accept literally almost an unlimited amount of data, right? And so, we get all the data and all the required telemetry to be able to make those decisions, which then creates a different problem, right? Now that you have all the data, how do you actually make sense of it all, right? And, you know, the data analytics techniques have dramatically improved over the last decade. You know, the old world used to be strictly rule based, and if you know this in sort of the IDS and IPS world, like, it’s basically signatures, right? In the SIM world, it was rules, right?

    And now we’ve moved away from that, right? We don’t even require our customers to tell us what the schema of their data is, because in the new world of high speed software development and DevOps, there is no schema, right? Developers put whatever they want into their logs of whatever metrics are coming from that infrastructure. And so, you need to be able to deal with the fact that this data has no schema and you’re gonna have to deal with the schema on demand and still need to be able to derive intelligence from that.

    So, we built a back end that then allows any data to be ingested, any data to be indexed and analyzed. And then, as you analyze that data, we realized very quickly that even if you have a very scalable back end and a very open ended sort of platform that can accept any data, giving a human a keyboard and a coding language is insufficient in empowering that human to actually construct what they actually want to derive out of this, right?

    So, we invested heavily into a couple of things. One is, you know, from the very beginning, we invested into automated techniques for analysis—advanced statistical analysis, machine learning, and things like that, that basically are special purpose built for these types of data systems where, you know, they detect anomalies, they detect outliers. They enable you to sort of remove 99.9% of stuff that is noise and sort of highlight and find all of those things that are real signals in that data.

    And the second part that we talked about last year, which was one of the big innovations we delivered, was something that we called global intelligence service, which basically leverages all this telemetry that we see across sort of the global infrastructure that we run. And it’s able to sort of derive what I would call best in class behavior. What are you expecting to see to happen on this type of infrastructure, right? If I see 1,000 pieces of infrastructure that is common across hundreds of our customers, and I know that this is what’s normal—well, that can tell me whether your stuff is normal as well, right?

    So, there are all these novel heuristics analysis techniques that can inform those decisions as you then run those automations on the back of them.

    Shimel: Yeah. So, you mentioned, Bruno, you were working—was that on ArcSight before, or a different SIM?

    Kurtic: No, actually, my other founding members were at ArcSight. I was at a company called SenSage, which was competing with ArcSight.

    Shimel: Okay. I—yeah, those were my days, those were my peeps.

    Kurtic: Yep.

    Shimel: But, you know, you’re 100% right. You know, they say you can’t make wine before it’s time. And as much money and effort and blood, sweat, and tears that we poured into SIMs back then, they were almost at some level doomed for failure, just because it was state of the art, right? It was—

    Kurtic: Yeah.

    Shimel: You were always trying to dumb down the amount of signal in there and reduce the signal to noise and what you can do and what people would trust with it. And, you know, in many ways, kinda that, that right there, the flip side of that is kind of the success story behind Sumo Logic—right platform at the right time.

    Kurtic: That’s right. That’s—and we’ve learned those lessons, right? All of the founding teams, Sumo has seen how it worked before, right? And when we started the company, we wanted to build something different, take this to the next level, and that has been the task for the last 10 years.

    Shimel: Yeah, 10 years in the making, another overnight success. [Laughter]

    Kurtic: Right, yeah.

    Shimel: Now, we’ve got this platform, we are—you know, we’re in the right place at the right time. Let’s assume we are. Where do we go from here? Where do we go from here?

    Kurtic: So, where do go from here? So, you know, where we go from here, I think, is—we, as a company, sort of, we deliver on this vision of the continuous intelligence category and platform for our customers. Where we are moving into is, we’re moving into sort of fine tuning and shipping multiple products that are optimizing the outcomes for specific user personas and use cases.

    So, I’ll give you some sort of examples of that. You know, on the DevOps side, right, we’ve spent a lot of time on the use cases around cloud, multi-cloud, packaging out of the box solutions for people running in AWS, GCP, in Azure. We recently introduced a, what we call a Kubernetes solution. So, as more and more of our customers move into solutions like—into platforms like Kubernetes and containers and serverless, they’re looking for out of the box insights that, as soon as you plug the data coming out of these platforms into a platform like Sumo Logic, they want to know what—how is my application, how is my platform doing, right?

    So, we’re spending more and more delivering special purpose insights on top of these specific use cases and areas for specific personas. On the security side, we are sort of extending our product set into things like the cloud SIM, you know, tuning it for compliance, again, across specific domains. Like, if you are running on premise or in multi-cloud or in single cloud, we want to deliver more and more specialized packages that basically enable our customers to consume this without having to think too hard about it, right?

    Shimel: Yep.

    Kurtic: The old SIMs were difficult, because you had to write all this stuff yourself, right?

    Shimel: Agreed, agreed.

    Kurtic: Right?

    Shimel: And I think, you know, it’s almost continuous automated intelligence for DevSecOps.

    Kurtic: Mm-hmm.

    Shimel: Right? And I’m not saying that’s the end of the road or the end of history as we know it, right, because we’re in a constant cat and mouse game and as things change, but it really is such a different place than we were 10 years ago, or even five to seven years ago, for that matter, right?

    Kurtic: That’s right, yep.

    Shimel: Bruno, let me ask you personally, right? Ten years in here, you are, you know, the key person developing this, you’ve got this to where it is—what gets you juiced in the morning, man?

    I know I love doing what I do now, right? I got out of the software game, I’m a media person, I love building my company and doing it. What gets you excited in the morning about coming to Sumo and doing this?

    Kurtic: Thanks for the question. It’s actually, you know, if I kind of, when I look at what’s happening, what are the undercurrents here of this market that we’re in, right? We talked about use cases and all this, but the undercurrent here is that there is a massive transformation that’s happening in the technology landscape, right? And the transformation is driven by the business transformation occurring in all industries today, right? Everybody’s—every company is getting remade from inside to go from a traditional business model to a digital business model.

    And these digital business models are then meaning that every single company is becoming, essentially, a software company. And they’re competing not on manufacturing or whatever business they were in, they’re competing on delivering products and services—digital products and services to their customers.

    So, essentially, the entire GDP is gonna be based on software, right? And in order for all of these enterprises and government organizations, you name it, to do this effectively, they’re all going through basically modernizing of how they do their technology, how they build their applications, how they develop them, how they understand them, how they improve them, how they optimize them.

    And we are just at the very, very beginnings of what this market is going to need, right? And I think our goal from the very beginning has been that we kind of want to be that platform for the digital business that’s leveraging all this new stuff, and to enable those users to actually do this effectively. And the challenge that those users have today are sort of, they seem insurmountable today. There’s so much data, right? There’s so much digital exhaust that they have to contend with. The skill sets available to them to actually adopt these technologies are very, very scarce, right? But everybody is going there because there is no other way.

    And so, to me, this is really exciting. We are sort of at this crossroads, this sort of fork and every 18 months today there’s a massive paradigm shift in technology. And, you know, every 18 months, we have to think really hard about how do we now do this and help our customers do that? You know, it’s no longer like two decades ago when it was like, you know, your three tier applications and that trend is going on for 20 years, right? Now, we’ve gone from on-prem, three tier, to cloud, to microservices, to Kubernetes, to containers, to serverless, and God knows what’s gonna happen in six months, right?

    And that’s just really exciting, and having to build—building a company that can respond to that and support our customer base as they go there so they can compete better is extremely exciting for me. And so, that’s what keeps bringing me back and keeps me smiling when I wake up in the morning.

    Shimel: Great answer, man. You know what? It’s a great time to be alive and in this industry, it really is. There’s so much happening.

    Kurtic: It really is.

    Shimel: We’re on the precipice of so much more, though. Because it’s like—you know, the more we accomplish, the more we can accomplish. And that, I think it keeps a lot of us in this, right?

    Anyway, Bruno, I told you we were gonna do this for 15 minutes, and we’re closer to a half hour now, I apologize. [Laughter]

    Kurtic: No problem.

    Shimel: But it was a great conversation, I’m really happy we got caught up on Sumo, you know, and the continuous intelligence platform. You guys are gonna be at RSA, yeah?

    Kurtic: We will.

    Shimel: Yep. So, I’m gonna try my best to have this up for our audience listening to this, RSA is the week of February 24th in San Francisco, and if you’re attending RSA Conference, go check out the Sumo Logic booth.

    Also, we’re gonna be putting on a whole DevSecOps event conference within a conference at RSA on Monday, February 24th at Moscone—I think we’re in Moscone West this year. So, if you have an RSA bench and you want to talk DevSecOps, come join us there. We have a great lineup of speakers. We also can visit the Sumo booth at RSA Conference, which is, I think it starts Monday night the 24th, the expo floor opens and it runs through Friday. So, check that out—shout out to our friends at RSA.

    Bruno, thanks very much, man. Say hello to all of our Sumo Logic people. Keep up the great work.

    Kurtic: Will do. Thank you, Alan. Appreciate it.

    Shimel: Alright. This is Alan Shimel for devopsy.kinsta.cloud. You just listened to another DevOps Chat.

    — Alan Shimel

  • Tenable Allies With Datadog to Drive DevSecOps

    Tenable Allies With Datadog to Drive DevSecOps

    Datadog and Tenable have teamed up to enable organizations to adopt best DevSecOps processes.

    Tenable CTO Renaud Deraison said his company is making the cybersecurity data it gathers via its Nessus vulnerability scanning software available to the monitoring and analytics service provided by Datadog. The goal is to make it easier for DevOps teams to discover and address cybersecurity issues before an application is deployed in a production environment, he said.

    Tenable has more than 30,000 customers, according to the company. Obviously, not all of them have embraced DevOps. However, unless DevOps teams can find a way to incorporate cybersecurity data, it won’t be practical for organizations to define a set of best DevSecOps practices. Even with that data available, Deraison said he expects it may be as long as five years before DevSecOps becomes broadly adopted. Many organizations are going to find a way to make cybersecurity teams part of the application development process. The challenge, of course, is finding a way to achieve that goal without unduly slowing down the application development process. In fact, Deraison said that despite all the hype surrounding DevSecOps at the moment, there still isn’t enough focus on actual workflows.

    Less clear is whether security will become a distinct functional test within a DevOps process or simply be incorporated into an existing quality assurance process. Deraison noted that cybersecurity and quality assurance are really two sides of the same coin.

    In the meantime, Tenable doesn’t have any plans to integrate with any other monitoring tool. The company chose to ally with Datadog because it makes available a set of application programming interfaces (APIs) that are well-defined, he said.

    DevOps teams going forward should expect to see a raft of integrations between providers of cybersecurity tools and various monitoring platforms. That data needs to be made available both when an application is being developed as well as after it has been deployed in a production environment to help developers prioritize bug fixes. Not all vulnerabilities are equal in severity, so it becomes important for DevOps teams to understand which are critical flaws that need to be addressed immediately versus something that can be addressed later in the application development cycle.

    Naturally, the biggest challenge most organizations will face as they move to embrace DevSecOps is melding two very distinct cultures. In some cases, it may prove easier to teach developers the fundamentals of cybersecurity than it will be to teach cybersecurity how to participate in, for example, a sprint. There may not even be enough cybersecurity professionals available to participate in the application development process, given the current chronic shortage of staff. There are already millions of unfilled cybersecurity jobs.

    Precisely what role artificial intelligence (AI) might play in accelerating adoption of DevSecOps has yet to be determined. However, given the chronic shortage of cybersecurity expertise, it’s apparent more organizations are going to have to rely on AI frameworks embedded in monitoring platforms to analyze massive amounts of data in a way that surfaces actionable insights before applications can truly become more secure.

    — Mike Vizard

  • The DevSecOps Landscape is Maturing — We Want to Hear About Your Journey

    The DevSecOps Landscape is Maturing — We Want to Hear About Your Journey

    The race to out-innovate one’s competition has led to high performing organizations chasing increased deployment velocities but often ignoring the quality of parts being used to manufacture their applications.

    It was 2003 when Bruce Schneier penned, “Today there are no real consequences for having bad security, or having low-quality software of any kind. Even worse, the marketplace often rewards low quality. More precisely, it rewards additional features and timely release dates, even if they come at the expense of quality.” Seventeen years later and it can sometimes feel like we haven’t grown enough. 

    As nimble organizations aim to deliver new innovations faster, using DevOps principles, the question of how and where security fits into the equation has spawned bigger conversations around what DevSecOps really means. And, in some circles where DevSecOps is even a different principle—security should already be a part of DevOps.  

    This is why we do the DevSecOps Community Survey every year—to better understand how organizations are adapting, what previous challenges were overcome, what new challenges may have popped up and to examine what approaches are being prioritized within teams to better identify risks. These questions, and many others, are extremely important and it’s why we’re embarking on the seventh annual DevSecOps Community survey. And, we’re looking for you to help us understand that state of DevSecOps. 

    Sonatype, devopsy.kinsta.cloud, Security Boulevard, Cloudbees, Carnegie Mellon SEI, DevOps Institute,  NowSecure, Verica, All Day DevOps and DevSecOps Days, launched the annual DevSecOps Community Survey earlier this month. Since then, we’ve already received over 5,000 responses. But, we have high ambitions and want this to be the most in-depth and comprehensive studies to date—and we need your help to do that.

    Since we first started this survey, seven years ago, we’ve seen a consistent maturation of DevOps practices and the combination of automated security. More and more respondents highlight that their practices have evolved and adapted to a DevSecOps mentality—or, that they have the ambition to do so.

    That said, we know we’re still in the early stages of so many DevSecOps transformations and while people may recognize the need for governance policies with DevOps, the theory doesn’t always make it into practice. The insights we gain from this survey allow us to provide concrete information back to the community on what those who have successfully transformed themselves are doing well—and what their journey looked like. 

    For instance, from over 5,500 respondents who took last year’s survey, we saw that more than  47% of them were deploying changes into production multiple times per week. This meant that as adversaries are getting faster at exploiting vulnerabilities, DevOps organizations that can identify cybersecurity risks and remediate them sooner can better defend themselves. 

    While we’ve learned that security is difficult to ignore when it’s embedded where developers already are, there is a lot more to understand about current practices. The voice of the community these past seven years has been invaluable, and we recognize that the experiences of those in the community can help us learn what resources are needed in order to support this ongoing cultural shift.

    In this year’s survey, for the first time, we’re also aiming to understand how responders feel about their jobs and the environments they work in. DevSecOps is a culture and we want to better understand the cultural attributes the elite DevSecOps practices employ. 

    Please take a few minutes to fill out the 2020 DevSecOps Community survey today; help us help the industry by better comprehending how the DevSecOps community has matured over the past year. And, you may even win one of our prizes—a Macbook, AirPods Pro or an Oculus Quest. Everyone who takes the survey will also receive first look at the results.

    — DJ Schleen

  • DevSecOps: A Renewed Commitment to Secure Delivery, Part 2

    DevSecOps: A Renewed Commitment to Secure Delivery, Part 2

    If done right, DevSecOps eliminates the cultural roadblocks that often prevent organizations from getting IT security proactively involved with development and operations. Barriers are the last thing any organization should contend with when comprehensive security is an absolute priority at a time when data breaches, intellectual property theft and other cybercrimes can almost immediately cripple a business.

    Still, companies are far from perfect. Misunderstandings, ill-defined policies and turf wars can prevent development and operations from collaborating in a way that naturally bakes-in security into their work. To effectively transform a DevOps pipeline into a DevSecOps one, organizations need to change the way people work and collaborate; make processes inclusive of quality, security and compliance activities; and integrate the right tools.

    Those three steps are the focus of this two-part series on becoming a true DevSecOps enterprise. We reviewed processes in part one and now we’ll cover people and tools in this article.

    For enterprises with deep-rooted DevOps, a renewed focus on security might entail modernizing the release pipeline and involving IT security people even more. For enterprises that are modernizing heritage-monolithic application portfolios and moving to cloud native architectures, pipeline modernization should include a DevSecOps approach that considers containers, microservices and APIs. 

    DevSecOps done right gives organizations a level of visibility and accountability that helps accelerate coding, testing, production deployments, problem determination and defect resolution–all accomplished because of an organization-wide acceptance and commitment to security that should shatter any and all roadblocks.

    Don’t Forget About the Humans in DevSecOps

    When was the last time you heard a developer say, “Hey, let’s get the security guys in here, to hear what they have to say?” Reality is far harsher. Collaboration with IT security often triggers visceral reactions that are not exactly positive. IT security is often stereotyped as the organization of “no” and “you can’t do that.”

    DevSecOps aims to tear down those cultural barriers. DevSecOps is all about embracing your IT sec organization and even inviting auditors to collaborate early on in the release process. 

    Ultimately, security is everyone’s responsibility. Being a developer, there was nothing like the mention of security to make me feel super uncomfortable. I don’t believe that developers set out to purposely create insecure code. However, when IT sec is not involved in a collaborative, cooperative relationship with dev and ops, there is an uncertainty that creeps in, and trust and confidence are shattered.

    We know developers develop and release code, while operators control and manage the runtime environment. What is the expectation of IT security in this process? What are they looking for? What risks do they need to mitigate when a digital product is delivered? Understanding the objectives of IT security in the delivery process will clarify the steps that must take place in the process and reveal which tools should be used to create a product that’s secure and delivered with velocity and quality.

    Understanding what stakeholders do along the pipeline reconciles personal and organizational accountability with tangible value-add in the release process. DevSecOps can be a catalyst to re-examine and provide clarity on who is doing what, when it is being done and why the effort is being exerted.

    Clarity might reveal that personas need to be updated to more modern roles. For example, an operations system administrator might become more of a site reliability engineer (SRE). The SRE role involves more proactive activities, earlier in the release pipeline, to infuse greater fault tolerance in code and greater resilience in the environment configurations–and to solve problems by engineering solutions with developers and IT security.

    Determine who does what and where. Develop personas that outline responsibilities along the pipeline, from the sourcing of code to production, to create necessary transparency. Value-stream mapping is a good way to capture the current state of a release pipeline and an excellent way to construct a desired state pipeline with the necessary people performing value-add activities to releasing a product. 

    Use Tools that Provide Necessary Visibility

    Tools are the enablers. These are the cogs in the machine that will be running test cases, static analysis, vulnerability scans and integration tests. Tools will automate DevSecOps processes and provide the most critical function: visibility. The ability to observe all DevOps processes and determine their origins in the pipeline is critical. Visibility lessens risk and supports compliance and audits. The process that defines how code is governed through the promotion path should drive the tools that will be integrated into the release pipeline. Most tools serve to automate build, testing, scanning, movement through the promotion path and integration with other tools. It only makes sense that end-to-end visibility in the release pipeline should be engineered in.

    Tools, though, must integrate and communicate to achieve end-to-end visibility. In the heritage era of DevOps (basically, the time before cloud native), it was tough to gain visibility because tools came from different vendors and often couldn’t talk with one another. Fortunately, cloud native platforms offer more integrated capabilities. Build and CI tools naturally share information because these capabilities are being refactored into the cloud platforms themselves.

    An example of this is the cloud native CI/CD capabilities of Tekton, which leverage and extend the operator framework in Kubernetes. Translation: CI/CD tools are starting to look like extensions of the cloud native platform, in stark contrast to heritage CI/CD tools which were standalone third-party software products. The result of this tool trend is tighter integration and better visibility built into the platform–you don’t have to engineer it.

    Companies need to review how effectively their tools communicate and close any visibility gaps. When possible, consider some of the next-gen automation tools and technologies such as Tekton, Kabanero.io and Jenkins-x that bring greater visibility, integration and consideration for cloud native apps which heritage tools have struggled with.

    DevSecOps Is a Catalyst for Pipeline Modernization

    A modern security framework will let companies take full advantage of the cloud native technologies that are changing DevOps. Granted, most companies won’t completely shift their entire infrastructure to the cloud, nor should they. Most organizations need to identify a partner to help them assess which processes and tools are worth moving to the cloud, and which ones–like a mainframe that runs core business functions–should be left alone. 

    For those enterprises that have a large heritage application portfolio, DevSecOps could mean retrofitting automation into systems and applications that were often designed and developed without the scaffolding of a secure DevOps pipeline. DevSecOps applies to heritage application, too. After all, what pipeline wouldn’t benefit from the visibility and traceability of tracking a user story to its production release? By automating the delivery of these heritage apps, you’re optimizing the effort of manual activities such as build, test and deploy, and retrofitting the capability of pipeline visibility.

    Cloud has changed the DevOps game, newly defining the fundamental technical underpinnings of what an application really is. And it is cloud that’s driving companies to look at the security of DevOps in an entirely new way. With much on the line–the purity of products, compliance, brand reputation–companies need to rebuild their security frameworks so they can take full advantage of cloud and their on-premises programs. They don’t have to do DevSecOps alone.

    — Andrea C. Crawford

  • Acting Rationally Regarding Coronavirus: RSAC Conference Update

    Acting Rationally Regarding Coronavirus: RSAC Conference Update

    With all the hype surrounding the coronavirus, let’s take a step back, take a breath and not give in to emotional conference mob fear-mongering

    We have all read the headlines: Mobile World Congress in Barcelona has been canceled. Facebook pulled the plug on a smaller conference next month in San Fransisco. IBM Security has pulled out of RSA Conference next week. Health and safety are everyone’s concerns, but are we acting rationally regarding coronavirus?

    RSA Conference (RSAC) put out an update on Friday (use that link to stay up to date on RSAC) with some great metrics on some of the risk factors and attendance numbers. It is also important to note that RSAC is expected to draw a crowd of about 50,000 visitors (some of them attending the DevOps Connect: DevSecOps Days event that we produce).

    Yes, eight vendors have withdrawn from exhibiting at RSAC. Six of these were from China and frankly, given current travel restrictions, probably couldn’t get here anyway. One is from Canada and one from the U.S. (presumably that is IBM).

    But should we give in to emotional conference mob fear-mongering? There is some serious clickbait nonsense being bandied about, including “RSA in Doubt After IBM Pulls out of Conference.”  To be fair, the clickbait headline was updated, but still, that is just fear-mongering at its worst.

    Why would IBM and the Canadian company pull out? Well, two obvious reasons. One is for the safety of their employees and their potential customers. The other is economic if they feel attendance will suffer. But while I don’t have any facts to back it up, I would have to assume that unless the event is outright canceled, vendors pulling out at this late date won’t be refunded their deposits and payments. This is true not only of their fees to RSAC but also of the money they’ve ponied up for hotels, airfare, party deposits, etc. While potential liability for unnecessarily exposing people to the virus could be a legal option, reasonable precautions are being taken. So I don’t think economics play into the decision to pull out.

    As of Friday, RSAC reports that including the members of the canceled vendors, only 0.79% of attendees had canceled their attendance. I would assume that the overwhelming majority of these were attendees from Asia or other impacted regions who could not get flights here anyway. Something like 82% of attendees are from the U.S. On top of this, RSAC is taking additional precautions to keep the conference as germ-free as possible.

    I was in touch with RSAC management earlier last week regarding the DevSecOps event. At that point, I was informed that they were working closely with the City of San Francisco to do everything possible. They are following CDC and WHO guidelines. BTW, CDC still says the impact here in the U.S. to coronavirus is low.

    So, then, are we seeing an overreaction to coronavirus? The security industry, more than the mobile application or other tech industries, is more attuned to risk management. Are we managing this risk adequately? Are we giving in to the fear-mongers among us? The flu has killed so many thousands more people (albeit with higher infection rates), but that has never caused us to shut down conferences or question gathering in groups.

    Personal health and safety is everyone’s own right and responsibility, as well as the responsibility of the authorities. Of course, you should do what you think is best for you and your family. But I think times like this call for a moment of lucidity and the use of the risk management fundamentals so many of us practice in our professional lives.

    Those of you who know me personally know I am a huge Pittsburgh Steelers fan. Their coach, Mike Tomlin, has a saying that I think applies to this situation: “We don’t live in our fears, we live in our hopes.” I hope the current trend of withdrawing from our community is not one that will continue. I refuse to give in to exaggerated fears.

    I do want to announce two things, though, in regard to this coronavirus situation. First, for any conference organizers who have made the decision to cancel their event for this reason (it is your event, your decision), MediaOps is offering a conference disaster program (CDP) that will allow you to use our virtual conference platform and team to take your event virtual with almost all of the features of an in-person conference.

    We have produced more than 10 virtual conferences in the last year or so that have drawn tens of thousands of visitors with hundreds of sessions, exhibit halls, interactive booths, signage, live chat and more. You can go to the home page of Predict 2020, our most recent virtual event, and click “Recent Events” to get an idea here, but just a caution, registration is required. Please see our press release on this for details. It is important that the tech community continues to engage in the very important exchange of ideas, learning and community that is so vital to our success and progress.

    Secondly, Accelerated Strategies Group, DevOps Institute,  JumpCloud and MediaOps are hosting a survey to learn about what you and your organizations are doing in light of the coronavirus outbreak and whether this is forcing you to rethink actions and behaviors going forward—not just for attending conferences, but as part of disaster recovery and business continuity. For instance, is this situation changing your views around working remotely versus working in a large office, going to customer premises or international engagements? Help us gather the information—please take moment and head over to http://acceleratedsurvey.com to answer a few questions.

    As is the mission of Accelerated Strategies, all of the research and analysis will be made available to everyone to use without registration or any payment. Because “knowledge wants to be free.” I couldn’t think of a better example of why that mission is so important.

    “We appreciate being invited to support the efforts of Accelerated Strategies to learn how this global situation will impact people professionally. We know that the JumpCloud community has been impacted, so we are thankful to be able to help in a small way,” said Rajat Bhargava, co-founder and CEO of JumpCloud. “Supporting primary research into the impact of coronavirus across this community is important work, and will hopefully help shape the actions that organizations can take with their teams and business to successfully navigate the future.”

    “DevOps Institute’s mission is to advance the Humans of DevOps and we are obviously concerned about the impact on the thoughts and behaviors of our global community,” said Jayne Groll, CEO of DevOps Institute. “The best way to overcome the hype and adapt to changing times is to collect and share community data.”

    Finally, Mitchell Ashley, CEO of managing analyst of Accelerated Strategies Group, Groll and I sat down for a video discussion of the coronavirus discussion and the reasons behind the survey. The video appears just below. For information, we recorded this just before the news of IBM Security’s withdrawal from RSAC came out.

    [videopress 5RyZpLsG]

    — Alan Shimel

  • SaltStack Updates Enterprise IT Automation Framework

    SaltStack Updates Enterprise IT Automation Framework

    SaltStack has partnered with Tenable.io to make it possible to pull vulnerability data into the enterprise edition of its namesake IT automation framework.

    In addition, version 6.2 of SaltStack Enterprise now integrates with the IT operations analytics platform from Splunk to make it possible to configure the Splunk Universal Forwarder to index and analyze events generated by the SaltStack framework.

    The SaltStack Comply compliance management module has also been updated to include content for Windows Server 2012 and Windows Server 2019 platforms that has been certified by the Center for Internet Security (CIS).

    Finally, SaltStack Enterprise 6.2 optimizes communications between the Salt Master and the SaltStack Enterprise Operations Framework by adding an intermediate SQLite database layer to queue events. SaltStack says IT organizations should see 20 times-plus improvement in event processing throughput. SaltStack has also added the ability to forward SaltStack events to any Salt Returner, such as a SQL database or local file, to improve performance and maintain high availability.

    Mehul Revankar, a senior product manager for SaltStack, said with this update to the enterprise edition of its open source framework the company is leveraging partnerships to enable IT systems to create closed-looped systems. For example, vulnerabilities identified by Tenable.io now can be automatically remediated using SaltStack Enterprise.

    Revankar said the goal is to make it easier for IT teams to create an IT process that can be automated at the push of a button. As IT environments become larger and more challenging to manage, IT organizations will need to automate more processes at scale, he said. To achieve that goal, SaltStack is simplifying the process to connect to a wider range of third-party platforms that house the type of data required to automate a closed-loop process.

    Naturally, organizations that have embraced DevOps principles are at the forefront of IT automation. Revankar said that as teams of IT professionals converge to drive DevOps and DevSecOps processes, the greater the willingness to employ IT automation frameworks becomes. The goal is to automate as many processes to inject a level of agility that serves to accelerate the rate at which applications are deployed and updated. The challenge organizations have always faced in IT automation is the time it takes to integrate an IT automation framework with relevant data sources.

    Revankar also noted resistance to IT automation among rank-and-file members of the IT operations team is declining as the number of applications that need to be managed increases. Most organizations can’t find or afford to retain enough IT personnel to manage IT operations at the level of scale now required. As such, the need to automate as many rote IT processes as possible has become apparent to all. That’s especially critical in the case of vulnerability management, where the amount of time it takes to patch an application directly correlates to a specific level of risk.

    There is, of course, no shortage of options these days when it comes to IT automation frameworks. In fact, the decision concerning which IT automation framework to employ now has as much to do with the number of sources that framework can pull relevant data from as much as it does the reliability of the automated processes that framework enables.

    — Mike Vizard

  • Synopsys Advances DevSecOps via IDE Plugin

    Synopsys Advances DevSecOps via IDE Plugin

    Synopsys has extended the static application security testing (SAST) and software composition analysis (SCA) of the Code Sight plugin it makes available for integrated development environments (IDEs).

    The latest iteration of Code Sight adds the ability to analyze declared and transitive open source dependencies to identify components with known security issues alongside SAST findings without having to exit their IDE.

    Delivered vis the company’s Polaris Software Integrity Platform, the update enables developers to also review known vulnerabilities of flagged components to verify the risk and determine remediation options using vulnerability information from Black Duck Security Advisories (BDSAs). That information is based on data provided by both Synopsys and public CVE records gathered in the National Vulnerability Database (NVD).

    Patrick Carey, director of product marketing for the Software Integrity Group at Synopsys, said the Code Sight plugin enables developers to easily identify and select the best fix for vulnerabilities by providing detailed remediation guidance that directs them to more secure component versions.

    Code Sight also helps developers optimize component selection by including, for example, information regarding open source license risks and potential security and license compliance violations of an organization’s predefined set of open source policies.

    In general, Carey said Code Sight is designed to make it easier for developers to address a broad range of cybersecurity issues while an application is being developed instead of after it’s deployed. The goal is to make it easier for developers to discover and address cybersecurity issues on their own as part of the overall shift toward adoption of best DevSecOps practices, he said.

    The challenge, of course, is most developers have not been trained to identify potential cybersecurity issues in their code. Code Sight fills that gap by surfacing vulnerabilities as developers write code, said Carey. Synopsys plans to continue building on that capability by adding more analytics capabilities to the Code Sight plugin over time, he added. For example, Synopsys earlier this year acquired Tinfoil Security, a provider of dynamic application security testing (DAST) and application programming interface (API) security testing tools that will be employed to surface additional analytics in Code Sight.

    Eventually, the goal is to make identifying cybersecurity issues a natural extension of the quality assurance process within any application development and deployment life cycle, Carey said.

    It’s hard to say with certainty to what degree DevSecOps will be driven by a set of well-defined best practices versus simple evolution of how applications are developed. There’s no doubt cybersecurity professionals have a vested interest in making sure fewer vulnerabilities make it into production application environments. As such, communication between developers and cybersecurity professionals clearly needs to improve. However, the biggest DevSecOps strides any organization might make may simply come down to making the right tools available in the most frictionless way possible to developers.

    In the meantime, there’s no doubt application security has become a major area of focus in the age of digital business transformation. The challenge now is limiting the number of vulnerabilities that might be exploited as more code than ever is developed and deployed at increasingly faster rates.

    — Mike Vizard