staging-devopsy.kinsta.cloud

Tag: devsecops

  • 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, staging-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 staging-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, staging-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

  • What Is DevSecOps and How to Enable It on Your SDLC?

    What Is DevSecOps and How to Enable It on Your SDLC?

    For the past three to four years, all the companies around the IT world have adopted agile and different application development methodologies that leverage the work for different departments or areas and helps them to develop new products and release new features to improve their processes and infrastructure.

    In this new Agile and DevOps world where everybody on a team is involved in the rapid-changing and evolution of their application, we are promoting accountability for everybody in terms of security—this is when DevSecOps joins the party.

    What is DevSecOps?

    DevSecOps is a new model that provides accountability for the security implementation in the application; from the planning, design, development, QA/testing, to release and when operating on a production environment.

    When implementing DevSecOps on the Software Development Lifecycle (SDLC), an organization will experience the continuous integration and will notice that the costs for compliance are reduced, code is constantly being analyzed, tested, delivered and released properly.

    DevSecOps enables the process of implementing security to everybody and makes them accountable.

    Why Is It important?

    As I stated previously on this blog, on this rapid-changing era, everything is evolving at a very accelerated pace. We continue to discover vulnerabilities and breaches across platforms and operating systems, patches are released constantly but we—as part of the operating team of a company—cannot afford the risk of having a vulnerability on any side of our IT system/application.

    Main Benefits

    • Reduces vulnerabilities present on your code.
    • Reduces vulnerabilities present on your IaC technologies.
    • Reduces the number of ways to exploit your application
    • Reduces downtime.
    • Improves your application stability, availability and security.

    How Can I Enable DevSecOps on My Current DevOps Pipeline or SDLC?

    DevSecOps is a must-have methodology that needs to be integrated into your DevOps process/pipeline to help you improve your security on your SDLC.

    There are five important phases that need to be followed in order to enable DevSecOps on a current DevOps pipeline or in the SDLC. Here are the crucial phases to enable it:

    Phase 1: Secure Local Development. Start by implementing secure working-environments. When you are developing an application, in most cases you will use open source technologies. Docker is a great helper at this phase since it automates the infrastructure and services deployments on local machines. So when you are using this ready-to-go docker environment, make sure that you are using the most recent/updated versions of the Docker Images and scan them for vulnerabilities. Even the images from official providers have vulnerabilities that need to be patched.

    Phase 2: Version Control and Security Analysis. Enable Vulnerability while uploading your source code.  Having multiple hands or people working at a piece of code can lead to vulnerabilities, especially when they are remote. Git systems have been a great improvement for collaboration between team members and code. When a team member uploads a piece of code, I strongly suggest that you enable automated testing for security on your code dependencies and core. Some good alternatives to do it are Snyk or Sonatype’s Nexus.

    Phase 3: Continuous Integration and Build. When creating the development image/package, you’ll need to make sure that your build tool or system has the proper security in place. It uses https:// protocol, it’s properly hardened and secure, it’s available and protected for attack mitigation or even not accessible via the internet. The tools that you can use here are Jenkins, Circle CI, AWS CodeBuild, Google Cloud Functions, Azure DevOps.

    Phase 4: Promotion and Deployment. When deploying to an environment, insert the environment variables through your CI/CD tool and try to manage them as secrets. Proper encryption and management of these are recommended in order to enhance your security protocols.

    Phase 5: Infrastructure Security. When your app is deployed, make sure that you have an IDS (Intrusion Detection System). Tools such as OSSEC or Wazuh will help on this matter to protect all your hosts.

    Once your code gets to the production, it doesn’t mean that it will be 100% secure. New vulnerabilities are disclosed every day but this cycle will help you and your team to test your code against all the repository of known vulnerabilities, at the time of monitor, configure, reconfigure, adapt and deploy solutions to the environment.

    Tools and Processes

    These are the tools you will need to enable in your DevSecOps process:

    • CI/CD Tool.
    • Secrets Manager.
    • Version Control System.
    • Docker Orchestration tools.
    • Security Analysis tools.

    And these are the processes:

    • Automated regression testing.
    • Dynamic testing.
    • Automated Vulnerability Assessment.
    • Automated Integration.
    • Promotion.
    • Automated Deployment.

    What Is the Ideal Workflow for DevSecOps?

    1. A developer creates a new code and integrates it into the VCS.
    2. Members from the QA team retrieves the code to perform the static code analysis to identify security flaws or functional tasks.
    3. A test environment is created automatically using IaC such as Terraform, CloudFormation, Chef or Puppet and the security configurations are added to the system.
    4. The test automation suite is performed to the application with a tool usually Selenium or any other tool that performs backend, UI, integration, security and API tests.
    5. After the test suite is performed and successful the new changes are sent to the production environment.
    6. The new version of the code is now going to be monitored in the production environment using an APM or Cloud-native monitoring tool.

    Following these points you are ensuring that your application is following TDD practices improving the code quality, compliance, increasing the number of releases of code to production and reducing the time to market which is essential for any organization.

    What Are the Challenges When Enabling DevSecOps?

    • Enabling too Many Tools: Enabling too many tools can become a problem on your SDLC, especially when your team is not used to work and relate with DevOps/security tasks. The main recommendation here is to start slow. Start by enabling only the necessary tools to get your team familiar with the process and add more when you feel your team is prepared for it.
    • Getting Used to the Methodology: It will take some time for all the team to get used to the DevSecOps methodology/culture and also to keep following it in order to be compliant with the normative that your business demands. Try to always stay up-to-date and coaching your team for the newest technologies.
    • Chasing Perfection on the Process: Keep in mind that all the DevSecOps process won’t be perfect, but it will get mature over time. Teams always try to chase perfection and this only leads to more problems with even more integrations or dependencies.

    Conclusion

    In the end, I think every organization must make the effort to shift to a DevSecOps methodology or process and come up with a multidisciplinary team with a focus on security. That’s how an organization will transition from doing DevOps to DevSecOps. Allowing all their collaborators to have accountability on the part they are actively developing.

    — Guillermo Vélez

  • Report Pins Cloud Security Woes on Flawed DevOps Processes

    Report Pins Cloud Security Woes on Flawed DevOps Processes

    By now it’s become apparent that the bulk of security incidents involving cloud platforms revolve around some type of configuration issue. An analysis of those cloud configurations published today by the Unit 42 research arm of Palo Alto Networks suggests that the root cause of the issue is most likely the templates many developers and DevOps teams rely on to configure cloud infrastructure. In fact, according to Unit 42’s analysis, more than 199,000 templates have medium-to-high vulnerabilities in use on public clouds.

    Matt Chiodi, chief security officer for public cloud for Palo Alto Networks, said the issue stems from the rate at which organizations now want to be able to deploy applications on public cloud. Templates greatly accelerate the process but very few of those templates have been vetted by a cybersecurity team.

    According to the report, the most commonly used templates are created using YAML files on instances of Kubernetes (39%), Terraform and CloudFormation (24%). The most vulnerabilities were discovered in templates created using CloudFormation (42%), Terraform (22%) and YAML for Kubernetes (9%).

    Chiodi noted most templates are created through a simple three-step DevOps process: design, code and deploy. Unfortunately, in the rush to deploy most DevOps teams forget to scan for vulnerability issues. As a result, Chiodi said cybercriminals have become very adept at siphoning off cloud resources to mine cryptocurrencies at low-enough consumption rates to go unnoticed by many IT organizations.

    Other significant cloud security issues surfaced in the report include the fact that 43% of cloud databases are not encrypted and that 60% of cloud storage systems have logging disabled, which Chiodi noted makes it impossible to know whether those systems have been compromised. In addition, the report finds 76% of cloud workloads expose SSH (port 22), while 69% of organizations expose RDP (port 3389) and 27% are using outdated versions of Transport Layer Security.

    Overall, the goal now needs to be to make it as simple as possible for DevOps teams to do the right cybersecurity thing going forward, said Chioti.

    Unit 42 researchers employed a publicly available GitHub Searching application programming interface (API) to find AWS CloudFormation files, Kubernetes YAML files and HashiCorp Terraform files. Hundreds of thousands of templates were then downloaded and analyzed by the Prisma Cloud infrastructure-as-code (IaC) Scanner to identify the insecure configurations. Each IaC file was also sent to an IaC resource checker to analyze the cloud resources being used in the template. Researchers also used Palo Alto Network’s proprietary AutoFocus and Wildfire tools to identify and investigate cybercrime groups through their usage of custom toolsets (malware samples). Those samples were dynamically and statically analyzed to ensure indicators of compromise.

    The Unit 42 research makes it clear there’s a lot of room for improvement when it comes to employing best DevSecOps processes in the age of the cloud. The challenge, however, may have little to do with the tools available. Rather, it’s the absence of a structured set of processes through which DevOps teams and cybersecurity professionals can collaborate that appears to be inflicting the most damage.

    — Mike Vizard

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

    DevSecOps: A Renewed Commitment to Secure Delivery, Part 1

    Security has never been as high a priority than it is today, as companies fear they’ll be the next headline, the next victim of a data breach. Executives also worry about applications meeting the high standards of compliance–either with global regulations such as GDPR, state-oriented privacy laws or the many specific ones covering finance, health care, energy and other industries.

    It’s a bit of a challenge introducing new tools and processes into a longstanding software development life cycle, even when it’s for the sake of increasing security. That’s why companies need to first carefully review their development and production processes to fully understand how they create and release software before they can effectively integrate security into DevOps.

    A reconstruction, so to speak, of application delivery allows companies to step back and smartly modernize their pipelines so there’s minimal human interaction or machine disconnect in newly secured DevOps processes. Involving IT security as a stakeholder in defining governance in a DevOps release pipeline is also crucial. Only then does the “Sec” fit nicely into DevSecOps. In this two-part series, we’ll look at the three critical components that shape a sound DevSecOps pipeline. They are easy to remember: processes, people and tools.

    Vulnerabilities Call for a Maniacal Focus on Security

    Although microservices, containers and cloud-native architectures enable companies to create and deliver applications more nimbly and faster than ever before, many of these innovative technologies also increase the probability of security flaws and vulnerabilities in products. Exposure to risk is much greater with applications being released at higher frequency and in higher quantity as smaller containerized deployment units, as opposed to development happening on a gated monolithic Java application.

    For example, the provenance of images from public container registries can be compromised and thus a potential exposure point in development. Likewise for the proliferation of open source software that is often used as libraries and dependencies. Perennial tools, such as GitHub, have fostered sharing and open communities, sometimes with grave consequences to those contributors that publish sensitive data to public repositories. How many times have we heard about passwords being pushed to public repos for all the world to see? 

    With all those considerations in play and with so much at risk, companies now have a maniacal focus on securing DevOps. But before they can even start formally considering security, they should first review employee responsibilities, organizational accountability, delivery practices, governance and the other aspects that go into the design, development and delivery of digital products. For enterprises that are modernizing to cloud native platforms and technologies, it might be an opportune time to reexamine and freshen up approaches.

    DevSecOps is indeed about people, processes and tools. Fully understand those three and you can build a secure delivery process that engenders trust and confidence in DevOps. Trust and confidence foster accountability and the notion that digital reputations are everyone’s responsibility.

    Determine the Process for the Release Pipeline

    Here, it’s about cementing a formal governance of processes, all the steps behind an application moving from one point to another. How does code graduate from local development and testing to the production station–and what happens in between? This is a fundamental tenet of the plain ol’ DevOps of yesteryear.

    There are notable considerations in a cloud native pipeline. For instance, the promotion path might be described with Kubernetes namespaces and clusters (not the baremetal servers or VM environments of yesteryear). Another modern DevOps approach is to apply DevOps principles to the application and environment configuration artifacts. Also known as GitOps, it’s applying the use of version control, access management and lifecycle processes to yaml files, helm charts, monitoring scripts and other artifacts that are primarily a concern of operations. Extending DevOps to operations (or GitOps) mitigates risk in environment misconfigurations and configuration drift, an added benefit. Security, in this respect, is addressed through environmental compliance.

    Aim to justify everything that happens in the release pipeline. Examine the value-add of steps and align them with the security risks they are trying to mitigate. Here are some examples:

    • Unit tests must pass in the build phase of the release pipeline to mitigate the risk of non-working code being pushed to the Development environment and entering the promotion path.
    • Vulnerability scanning must occur on all Docker images prior to go live to mitigate the risk of a security flaw or vulnerability being introduced in production.
    • All API interfaces must have a Swagger definition and a set of corresponding Pact/contract tests run in build phase to mitigate the risk of integration defects and corresponding outages.

    Seek Answers, Document Everything and Include Security

    By questioning everything, the answers will reveal what falls under the security lens and what eludes it. Ultimately, you want to document practices and processes so that they’re codified and held with reverence by everyone along the pipeline. IT security should have a seat at the table (alongside development, operations, product owner, QA) and be an equally important voice in examining the release pipeline. A core agile value is to have a product-focused approach to the release pipeline. Involving IT security will bring a healthy measure of risk mitigation into the pipeline, while still considering velocity in delivery.

    But that’s just the process. As we’ll explore in the second part of this series, people and tools also make a difference.

    — Andrea C. Crawford