devopsy.kinsta.cloud

Tag: security

  • Survey Finds Mixed Progress on DevSecOps

    Survey Finds Mixed Progress on DevSecOps

    A survey of 5,558 IT professionals published today by Sonatype in collaboration with CloudBees, Carnegie Mellon’s Software Engineering Institute, Signal Sciences, 9th Bit and Twistlock finds 27 percent of organizations have mature DevOps practices in place, while another 48 percent are still working on improving them.

    Despite the DevOps works that remains to be accomplished, however, the survey also noted that 47 percent of respondents still manage to deploy code multiple times a week.

    The survey, announced at the RSA Conference, also finds that 25 percent of respondents now consider security to be a fundamental element of quality assurance process. But responses among the 23 percent of respondents who identified themselves as developers suggest implementing best DevSecOps practices remains a significant challenge. For the third year in a row, about half of developers reported they don’t have enough time to address cybersecurity issue.

    The survey, however, also noted that organizations that do implement best DevSecOps practices see substantial benefits:

    • Elite DevSecOps practices are 700 percent more likely to have fully integrated and automated security practices across the DevOps pipeline.
    • Almost two-thirds (62 percent) of respondents with elite programs have an open source governance policy in place that is improved via automation.
    • Organizations with elite DevSecOps practices are three times more likely to provide application security training to developers.
    • A full 81 percent of those with elite practices have a cybersecurity response plan in place.
    • More than half (51 percent) of respondents with elite practices leverage automated security products to identify vulnerabilities in containers.

    Brian Dawson, DevOps evangelist at CloudBees, said the survey results show that despite the gains being made by some organizations, there is much work to done in terms of overcoming technical hurdles and cultural tribalism. For example, 35 percent of all respondents said their No. 1 challenge in application security is that they find out about the problem too late in the process. Nearly half (46 percent) of organizations without a DevOps practice do not have application-level credentials encrypted. Half of respondents (50 percent) with a cloud infrastructure said they rely on their cloud service provider to secure their IT environment, and 28 percent of respondents admitted they do not protect secrets such as passwords, API keys and certificates.

    The core issue most organizations need to focus on first is to firmly establish a DevSecOps mindset, said Dawson. Much progress has been made in driving adoption of DevOps practices. Now those principles need to be extended to include automating the implementation of security controls as applications are being built and deployed. The survey noted that 63 percent of organizations that have elite DevOps practices are now informing developers of cybersecurity issues directly within the tools provided to the DevOps team. Armed with that information, it becomes much easier to incorporate security fixes within the overall application lifecycle management process.

    It may be a while before best DevSecOps process are widely implemented. But as cybersecurity issues continue to be incorporated within the quality assurance process, it’s now only a matter of time before applications become much more secure.

    — Mike Vizard

  • DevOps Chat: AppSec and DevSecOps with Contrast Security’s Jeff Williams

    DevOps Chat: AppSec and DevSecOps with Contrast Security’s Jeff Williams

    I have known of Jeff Williams in the security industry for more than several years. He is a well-respected thought leader in AppSec and OWASP. I finally got a chance to catch up with Jeff and talk with him about Contrast Security, the company he co-founded and how it is helping.

    In this DevOps Chat, Jeff and I discuss the state of application security and how AppSec fits into the larger DevOps realm. Jeff’s a great interview with lots to share.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Today’s chat has a decidedly security bent. I’m happy to be joined by Jeff Williams, CTO and co-founder of Contrast Security. Jeff, welcome to DevOps Chat.

    Jeff Williams: Thanks, Alan. Good to be here.

    Shimel: Hey, my pleasure. So, Jeff, you know, as we were talking off mic, this is the first time we’re kinda interviewing anyone at Contrast. Why don’t we—I think it’s only fair we start off with sort of, let’s give our audience a little background. Who and what is Contrast Security?

    Williams: Sure. So, I mean, you know that many enterprises struggle with application security. You know, there’s been an application security industry for like 20 years. I helped to start OWASP back in the early 2000s and I wrote the OWASP Top Ten, and organizations are still struggling with the same problems.

    So, Contrast targets exactly those problems. We are kind of a radically different approach to doing application security. We’re very compatible with DevOps kinds of processes. And basically, we find vulnerabilities so you can shift left in the development and fix them. We analyze open source code, so you can make sure you’ve got safe versions of the components you’re using, and we protect applications in production. And we do it all through dynamic binary instrumentation. So, very much like a New Relic or an AppDynamics, but for security, not performance.

    Shimel: Security prudent security monitoring—excellent. And Jeff, you mentioned, though I don’t know if we’ve spoken like this before, but I’m certainly aware of you for a long time within the security community. This isn’t your first rodeo. [Laughter] You were instrumental in OWASP. You know, we’ve seen application security not—it’s evolved, yes, but it’s still, at the end of the day, it’s about the application, right?

    But yet, you know—look, it used to be, application security meant some kind of app firewall, which—

    Williams: Yeah.

    Shimel: – I’m not saying a WAF isn’t a great tool, it is. It’s changed the game in a lot of ways, I think, in what—

    Williams: Not really. [Laughter] I don’t think so.

    Shimel: Well, it’s made a lot of people a lot of money and it’s taken a lot of venture capital, let’s put it that way, right?

    Williams: Well, that’s not my measure of success. [Laughter]

    Shimel: Yeah. But has it made us safer?

    Williams: Not really, no. No.

    Shimel: But one can argue we’ve done a lot of things and not a lot of them have made us safer, right?

    Williams: That’s right.

    Shimel: You and I have both been in security for 15, 20–plus years, Jeff. And the latest buzzword is DevSecOps, and being that I’ve transitioned to DevOps five, six years ago, and I run devopsy.kinsta.cloud and I’m involved in Security Boulevard, I’m all about DevSecOps, and I’m not here to say it’s snake oil or bull or anything like that. But as we were talking about, it means a lot of different things to a lot of different people.

    Williams: That’s right, that’s right.

    Shimel: Why [Cross talk], what do you think it means?

    Williams: Well, you know, to me, DevSecOps is a way of viewing security the way that folks viewed software development through a DevOps lens.

    Let me back up. So, software had a ton of problems 15, 10, 20—I was a developer for a long time back in the early ‘90s and so on. And, you know, software development back then had tons of problems. It was late, it was very error prone, long feedback cycles, slow release times. I worked on one government program for three years, and it never was fielded. [Laughter]

    Shimel: Mm-hmm.

    Williams: So, that kinda thing plagued software. But, I think, DevOps has really revolutionized that, you know, basically just focusing on getting work flowing, creating short feedback loops and creating a culture of innovation of learning. Like, those things transformed the way that software is produced. I love the factory analogies and all that.

    Now, if you look at security, we have exactly the same problems. Security doesn’t really deliver a tangible result. Like, you never know when you’re done. So, the work isn’t defined. That means the work isn’t flowing. You know, we have these tremendously long feedback loops. I did a bunch of work for a major financial institution. They were on a system where some apps got a one year pen test, some apps got a two year pen test, and some apps got a triannual pen test. So, every three years, they would take a look at security. It’s crazy.

    And, you know, so we need to make tighter feedback loops, and security has this culture problem. It’s not a culture of innovation and learning, it’s a culture of enforcing rules and compliance and gates and guards and bottlenecks. And that all can change. If we apply the lessons of DevOps to the problem of creating security in an enterprise, we can define the work, we can create shorter feedback loops, and we can create a culture of innovation and learning. That’s really the challenge. In my opinion, that’s why security continues to struggle is, it’s just not delivering what we want it to deliver.

    Shimel: Yeah. You know, and—look, truth be told, Jeff, that’s what attracted me to DevOps. I thought it was an opportunity for us to kinda reshape the playing board and maybe change the rules and finally deliver—nothing’s perfect, and I don’t think anything is, I’ve seen enough so-called silver bullets to know none of them—

    Williams: Sure.

    Shimel: – [Cross talk] full of crap. But I thought, at least, it shifted the game pieces in such a way that we could, it was a more even playing field, or a better situational playing field for us.

    Williams: Yeah. Done right, I think DevOps can have a tremendously transformative effect on organizations building software. I’ve seen it in a bunch of large enterprises and small companies, you know, and we’re a DevOps shop here at Contrast as well. You know, we’re deploying six, seven times a day, and I have a huge amount of confidence that that makes us deliver much better software.

    And so, my challenge—

    Shimel: Much better software, or much—but is it also more secure? Because shouldn’t that be—I mean, that’s something I strive for, right?

    Williams: Right.

    Shimel: That security becomes synonymous with quality.

    Williams: Yeah. That’s right, that’s exactly right.

    Shimel: Is it more secure?

    Williams: Absolutely, it’s more secure. But you do need some better tools. So, I think, you know, to do security in a DevOps way, you need accurate, real time feedback on the code that you’re building. If you don’t have that, then you have to have experts involved. So, there’s a fundamental relationship. If your tools are producing inaccurate results, then you have to have experts to dig in and resolve the false positives and find the false negatives and, you know, it’s a ton of human expert work.

    That’s not compatible with DevOps. So, you need these accurate tools in order to give real time feedback right to developers. But that’s where instrumentation comes in. If you can get inside the code that you want to test for security or protect against attacks, that’s where all the context is. That’s where the information is. And so, using all that information, you can make really accurate decisions about whether something’s a real, exploitable vulnerability, or whether something’s a real, viable attack. And then you can give that instant feedback, you can create tight feedback loops, and you can deliver security.

    And I’ve seen it work. Companies have transformed themselves from the way they used to be with a big backlog of security vulnerabilities, they’re running scans every six weeks or six months or whatever. They’re piling up vulnerabilities, they’re not really fixing anything, and that’s a very unhealthy way to be. They transformed from there into an organization where they’ve worked off the backlog and now they’re in what I call the new normal. They’re just dealing with new vulnerabilities as they come in, as part of the normal workflow. And it’s massively more cost effective, because they save all that downstream work of tracking and classifying and risk creating and all this stuff. You know, it’s super expensive and doesn’t produce anybody any value.

    Shimel: Yeah. I mean, just, even from the security guy’s point of view to work in that scenario where I don’t have that technical debt, if you wanna call it that—

    Williams: It is—security debt.

    Shimel: Security debt. That’s a great word for it, right? Without that hanging over my head, how much easier and better is my life? And it’s so true. And the other thing, Jeff, is—honestly, until you’re at that point, I don’t think you can talk about automation and velocity and speeding up this whole thing, because when you’ve got all that dreck hanging in your background, you know, you can’t do it, right? You can’t—

    Williams: Well, that’s right. Traditional security is very destructive to modern software development. If you have to involve those bottlenecks and get experts involved, I’ve seen it just wreck DevOps—you know, organizations are trying to do DevOps, but they’re hamstrung by their legacy security teams and processes and technologies. And I wish it wasn’t that way, because security has potential to be a great force for innovation.

    Shimel: Yeah.

    Williams: If you can give people a fantastically secure platform, they can roll out awesome applications and awesome functionality at super high speed. Do things that normally you wouldn’t think you could do, but if you have the platform, you can really make crazy things secure.

    Shimel: Absolutely.

    Williams: It’s just—

    Shimel: I mean, and, you know, I was talking to my friends, John Willis and Damon Edward, they’ve both presented at Dozen, and the notion is, you can have it all. You can have faster applications, better, more secure applications, higher quality—all three, right? You could have two out of three ________, you could have all three doing DevOps and DevSecOps if you’re doing it right.

    But here’s another thing I want to touch on, Jeff, and that is, I don’t know whether it’s shiny trinket syndrome or single-mindedness or we can’t multitask, but just because someone says DevSecOps can do, can make your life better, can do all of the things that you and I are talking about doesn’t mean that we throw everything we learned about security out the door, right?

    Williams: No, no—of course not.

    Shimel: Well, for too many people, they’re like, “Hey, we don’t—okay, man. You know what? Screw that AppSec stuff, we’re just shifting left,” even though shifting left is, you know, fundamentally AppSec. “We’re just shifting left and we don’t have to worry about all of these other CIA things that we learned about, right, traditionally in security.”

    I don’t think anyone’s saying one necessarily replaces the other, or that it—

    Williams: No, I think really it’s more about being extremely clear about the outcomes that you want to achieve with security, and then putting in place a highly tuned machine that can produce those results continuously and repeatedly over the course of a project. Shifting left is a weird term, to me.

    I love the idea of doing security earlier in the process, but many people see that and say, “Oh, well, developers just do security now,” and they wash their hands of kinda the old ways of doing things. And unfortunately, that’s a recipe for disaster. I think you need to empower those developers with technologies that can let them do their coding and not introduce security vulnerabilities.

    And it’s not just about shifting left, because in QA and in staging and CI/CD environments, you want to verify that everything is secure before you push to production. So, you’re really not losing that step. You need to do both, shift left and where it is now. And frankly, I think a lot of organizations should also consider shifting right and doing more protection in production. Because so many organizations that I talk to—I was just talking to a massive technology company here on the West Coast this morning—they’re really pretty blind about what’s going on at the application layer from a security perspective.

    So, to me, it’s not really about shifting left, it’s actually about extending left and extending right and using a DevOps process to produce the outcomes that you really want.

    Shimel: Yeah. I don’t disagree there. The reason I brought it up, though, is, you know, we could point fingers all around, but sometimes the security industry is its own worst enemy, and the cynics and the cynical within—well, we’re consuming ourselves with other stuff right now, but the cynics and the cynical folks would then say, “Oh, it’s just another buzz word, and it’s just something meant to take your eye off the ball, and we have got to hold this thing in our cold, dead hands and not let go.”

    Williams: Yeah, yeah. It’s a fair point. I mean, DevSecOps is a little buzzwordy, and frankly, I’m sympathetic to the folks that say, “No, it’s just DevOps, and security is a part of it, of course.”

    Shimel: Now, that’s my—so, that’s where I am.

    Williams: Here’s how I think about it, though. Let me try and change your thinking about it—it is just DevOps, but there’s a view of the DevOps process that emphasizes the security pieces. It’s very much like a blueprint for your house. You know, you’ve got the elevations, then you turn the page and it’s got the plumbing plant, and then you turn another page and it’s got the electrical plant and so on.

    It’s a little bit like that, for me. DevSecOps is the security view of DevOps. It just emphasizes the security aspects of the DevOps process so that you can see what’s going on and actually understand it in a little different way than if you were just viewing the whole thing all mashed together. It doesn’t really help to just smash it all together and call it all quality. So, that’s how I think about it, it’s just a view of the normal DevOps process.

    Shimel: I don’t necessarily disagree. I think there’s only one DevOps, but I think—I know, I mean, so this year, at RSA, for instance, for the fifth year on the Monday of RSA week at the Moscone Center, we’re gonna be putting on DevOps Connect: DevSecOps Days. And over the course of the five years, we’ve called it DevSecOps, we’ve called it Rugged DevOps.

    Williams: Yeah.

    Shimel: Just don’t call us late for dinner.

    Williams: [Laughter]

    Shimel: And it’s kind of the security community that has driven the DevSecOps name, because they wanna make security is kinda in the middle, I guess. But—hey, whatever. If that’s what it takes to get people on board and doing things to make this more secure, so much the better.

    Jeff, we started talking and I wanted to talk more about Contrast, though. Share with our audience—so, you guys are involved in AppSec, you’ve got a bunch of things going on. Any new news, anything, you know, we are coming into RSA season, everyone always has some sort of news around that. Anything you can share or talk about?

    Williams: Well, I think the big thing for us this year is launching what we call run time exploit prevention, which is sort of our next generation attack detection. And the reason that it’s, I think, so compelling is because it leverages our deep experience in instrumenting applications at run time.

    And so, instead of just trying to block attacks by looking at HTTP traffic and saying, “Oh, well, that’s got a SQL injection in it” or, “That’s got an XXE in it or something.” Instead, we’re instrumented deep within the code, and using that position, we can access a lot more contextual information. We can make really smart decisions about what an attack really is.

    And this is interesting—we’re essentially defusing all forms of SQL injection and deserialization problems and XXE and expression language injection and so on by sandboxing powerful components inside the platforms.

    So, I can give you an example. All these struts and spring vulnerabilities from over the last year and a half or so? They all involve sending untrusted data to an expression language and evaluation engine. So, what Contrast does is, we sandbox those evaluation engines to prevent dangerous stuff from happening while they’re being executed. So, you know, when you’re evaluating an expression, you don’t expect to be starting native processes and accessing files and opening socket connections and stuff like that. So, we prevent all those things from happening during expression language evaluation and restrict the program to only evaluating a normal expression.

    It’s a very powerful technique for ruling out not just known vulnerabilities like in struts and spring, but we’re ruling out all forms of expression language injection, even ones that nobody’s discovered yet. So, I think that’s very exciting and puts you in a really unique position for dealing with new CVEs that are coming out every week.

    Shimel: Yep. Absolutely, and that’s huge. I mean, in spite of everything and in spite of the cynicism, the pessimism, and everything else, it actually is an exciting time to be in development and security, right? We are—

    Williams: I love it. [Laughter]

    Shimel: Yeah. You know, we’re making progress where good things are happening in spite of, you know, every day we still hear about another breach or another, you know, incident.

    Williams: Well, I’ll say this—I think it’s time that every application has the ability to detect if someone’s attacking it, and respond appropriately.

    So, forever, we’ve—basically, our policy around AppSec has been, “Well, let’s build a wall around it to try to keep out the bad stuff, and then let’s scan it to see if we can find where any holes are.” And both of those approaches, I think, have sort of gotten less and less useful over the last seven or eight years, to the point where, today, they’re not really very helpful, particularly on modern applications that are built using APIs, they’re deploying containers in cloud and they move around and all sorts of things. Those approaches just don’t work any more.

    So, fundamentally, building that protection into the applications itself is very compelling to me. It works at scale, it’s accurate, it’s very fast, it’s much faster than building barriers around stuff. And so, there’s just a number of advantages, and I’ve seen it transform organizations from the kind of organization we were talking about before with the huge security backlog, security debt. And they’ve, over the course of a year or a year and a half, they’ve transformed themselves across thousands of applications, to the point where they’re just dealing with the new stuff coming in. They’re in that new normal.

    Shimel: Yep, absolutely. Alright, man. Hey, Jeff, we are—we’re well over our 15 minutes.

    Williams: [Laughter] Awesome.

    Shimel: Yeah, so, we’re gonna have to call it a break on this one. But you know what? Between now and RSA, maybe we can get you back on here, we can talk a little bit more about this. It’s a hot topic, it’s—

    Williams: One quick point, if you want to try Contrast or expose yourself to IAST and RASP, you can use Contrast community edition for free. It’s fully powered, free for one app, and you can just sign up and start using it today.

    Shimel: Where do you get it?

    Williams: It’s at ContrastSecurity.com/ce.

    Shimel: CE. Alright, excellent. Hey, Jeff Williams, CTO of Contrast Security, thanks for being our guest on this episode of DevOps Chat. Until next time, everyone, this is Alan Shimel, have a great day, for devopsy.kinsta.cloud, DevOps Chat, and Security Boulevard—take care, everyone.

    — Alan Shimel

  • DevOps Chat: Repos and Nexus Firewall Access, with Sonatype

    DevOps Chat: Repos and Nexus Firewall Access, with Sonatype

    There are really only two repositories of any scale for software components today: the Nexus repo managed by Sonatype and the Artifactory artifact repo managed by JFrog. Up until now they were separate and apart, and working with one was independent of another.

    In a big move toward keeping DevOps open and secure, the Sonatype people have released a plugin that will allow their Nexus Firewall to work with Artifactory as well as Nexus.

    This means that users of both repos can now use the Nexus firewall to make sure that components or artifacts they download are in compliance with the policies they have set up. They can make sure there are no known vulnerabilities to the version users are downloading to use. This is really a big deal and kudos to Sonatype.

    In this DevOps Chat we speak with Wayne Jackson, CEO of Sonatype, and Brian Fox, CTO and co-founder of Sonatype, about what this means for the DevOps community.

    Transcript

    Alan Shimel: Hey, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat is breaking some big news from our friends at Sonatype. I’m really honored and happy to be joined by Sonatype Wayne Jackson and Sonatype CF – CTO, Brian Fox. I hope I didn’t mess that up, guys. Wayne, Brian, welcome.

    Brian Fox: Thanks.

    Jackson: Thank you, Alan. Great to be with you and great to be speaking again.

    Shimel: Yeah. Well, Wayne, you and I go back just a couple years.

    Jackson: [Laughs]

    Shimel: Let’s not go and do a history thing. Let’s get right to the breaking news today, and that is kind of a major addition to the Sonatype – I know it’s a firewall. Do you still call it Nexus Firewall or is there a different name for it now?

    Jackson: Yes, we – yeah, that’s correct.

    Shimel: It is the Nexus Firewall. So before we talk about what the major addition is, let’s lay a little groundwork here. What is the Nexus Firewall? Brian, you’re the CTO, let’s give that one to you.

    Fox: Alright, sure. Nexus Firewall is a set of capabilities that allow us to do analysis of components as you pull them into your supply chain through your repository and be able to match that against your policies to enforce things like architecture, quality, license, et cetera, and so specifically it’s intended to be able to stop components from coming into your supply chain when they’re known to be against your policy right up front. So you can stop developers from pulling in a component that has a known vulnerability or pulling in a component that has a incompatible license, those types of things. So that’s the role Firewall plays in the overall portfolio.

    Shimel: Perfect. And, you know, let’s be clear; that – you know, a Nexus Firewall, if it’s in place the Equifax breach never happens for all intents and purposes.

    Fox: Well, that might – what it doesn’t do – you know, it’s not gonna go back and take out the things you’re already input.

    Shimel: You’ve already put in, you’re right.

    Fox: Right. Certainly. If – you know, we still see lots of cases – I think we’ve done some of the studies recently that show organizations are still downloading the same thing that got Equifax attacked, right?

    Shimel: Absolutely.

    Fox: It’s the same version of Strut. So, Firewall would definitely stop that behavior, no doubt, and be able to prevent it from further propagating through your supply chain.

    Shimel: And just a little shout out, Equifax is now a Nexus – a Sonatype Nexus customer, correct?

    Fox: Yeah, that’s correct.

    Jackson: Yes, that’s correct.

    Shimel: So hope – well, at least it’ll prevent the next one, hopefully. So – but guys, so we understand what Nexus Firewall is now, and again, to put in context the importance of today’s announcement, Nexus Firewall worked when you were pulling components out of the Nexus repository up until now. Am I right or am I off base here, guys?

    Jackson: No, that’s correct.

    Shimel: And so the big news today is you’re expanding beyond the Nexus repository to offer protection from artifacts and code and so forth from other repositories.

    Jackson: That’s right. It’s – you know, it’s an acknowledgement, and it may be the first one in this category, that just acknowledges that the DevOps world is heterogenous. You know, there are bunches of vendors and, you know, people within organizations make different decisions and we just acknowledge the need to provide universal protection.

    Shimel: Absolutely. So Wayne, work with me here. It’s the Nexus repository, and with this new release out today you guys are also announcing support and protection for the Artifactory repository, correct?

    Jackson: That’s correct.

    Shimel: And –

    Jackson: And between those two, you know, I’m not sure what the coverage is but it’s gotta be in the 90th percentile of implemented repositories.

    Shimel: I would agree with you. I think between Artifactory and Nexus it’s gotta be I would say high 90’s even, right? We’re not talking 91 or 92 percent. I think it’s probably way up there, and it’s certainly in the billions when you look at the amount of whether it be code or components or artifacts that are contained between the two of them. And Wayne, you hit on it before about the heterogenous nature of today’s DevOps world. It really is; it’s become Artifactory and Nexus as the two big ones.

    But there’s another aspect to the heterogenous nature of today’s DevOps world and that is this whole notion of the software development life cycle, managing the software pipeline, the modern software factory; different companies are calling it different things but it all refers to kind of the way that software is being both written and assembled in – by, you know, modern IT departments today. Why don’t you guys expand on that a little bit.

    Jackson: Yeah, I – it’s been fascinating to watch. As you know, I came from the network security world before Sonatype and had no grasp of just how much software was being written. As I’m sure you know, you know, one of the assets that we manage in the ecosystem is this thing called Maven Central, and last year we served 142 billion download requests, and so – and that’s just in the Java ecosystem and, you know, other ecosystems like NPM are just as big.

    Shimel: Yeah.

    Jackson: And so as we started looking at the patterns in these download requests we started to see this weird disconnect. You know, the disclosure of a vulnerability had almost no impact on usage patterns, and that led us to thinking about, you know, why that might be and how we might think about solving these problems more systematically, and it dawned on us that we had a massive supply chain problem. You know, where the producers of things didn’t have a very effective mechanism for communicating to the consumers of those things because there were just millions and millions of projects that had to be monitored. And so, you know, we started looking at the works of Edwards Deming, who was the guy that transformed Toyota from being a textile manufacturer to the world’s most efficient automobile producer, and it really wasn’t all that complicated. You know, you have fewer, better suppliers, you use the highest quality parts, maintain transparency throughout the system, and don’t pass defects downstream.

    If you can do those four things, lo and behold, [laughs] producing cars becomes a lot easier. And, you know, we concluded that those exact same principles applied perfectly to software where, you know, to your point, you know, now all of a sudden these software development functions, especially in the more modern organizations, look like a software factory, and so let’s use fewer, better projects, let’s use the versions of those projects that don’t have security defects, that have the kind of license that matches our  distribution model and, you know, let’s build a model where we know [laughs] what’s in the system. And if along the software factory assembly line we discover that there’s an issue, stop it there. You know, don’t pass it downstream.

    So anyway, so it’s a model – you know, I’m a little bit of a car guy so it [laughs] certainly works for me, but it feels like a model that’s right.

    Shimel: I agree. It absolutely does. And even before you mentioned Deming, and of course it’s obvious, I was thinking third-party suppliers just like we do see in the automobile industry. But what’s interesting is as you referenced, the sheer magnitude of the numbers here – you know, 142 billion – think about what that means. I mean it’s just an incredible, incredible amount of downloads of usage and everything else and, you know, it doesn’t take many bad apples to spoil the party for everyone, obviously. You know what’s interesting though, guys? Again, getting back to the DevOps community, the DevOps market today, Sonatype is very much – you know, who you are and what – it seems to me anyway – you know who you are, what you are, where you play and how you fit into this.

    And I think that’s in contrast to – you know, we’re in a little bit of a time of upheaval in the DevOps spaces as the market matures and vendors are jostling and trying to – I think some of them might, you know, even be going through an awkward teenage phase, you know, where they’re trying to figure out who they are and what they’re gonna be when they grow up. You know, what – Wayne, you’re the CEO there – what’s the vision for Sonatype? Are you kind of comfortable in your own skin now and what is that role?

    Jackson: Yeah. I think we are comfortable in our skin. I think this embrace of software supply chain management is who we are, it’s who we’re going to be, it’s sort of a unique position to take in the DevOps category, and it allows us to play very nicely with the vendors that are all a part of the assembly line, you know, whether it’s Artifactory or CloudBees or any of the other vendors. And so being able to produce information that gets translated into knowledge that, you know, automates decision-making with regard to supply chain integrity, I think is a good spot for us.

    Shimel: I agree. I mean and not only is a good spot I think it’s a pivotal role to play at this – you know, as we see the continued maturation of the market and, you know, it’s all wrapped around the digital transformation and everything going on. Brian, you know, your background, you were an early chair of the Maven Project. You’ve been in this opensource, you know, world for some time, and Wayne did too coming from the Sourcefire Snort folks, but what’s your take as we see this, you know, maturation? I mean at some level it’s gotta be – I would imagine it’s gotta be encouraging to see cross – like, you know, being able to protect across different repositories, whether it be Maven and Java or Artifacts or what have you, right? It’s gotta feel like we’re making progress. What do you think?

    Fox: Yeah, I think so. I mean our approach since we kind of went down this path, what, 2012 or so is to take an approach that sits above all of the tools, because we recognize from the early days when we were doing a lot of Maven training and consulting and we had the privilege I guess to go to companies and see lots of horrifying processes and all the ways in which attempts to make this better inadvertently made things worse, and we recognize that it requires a sort of across-the-life cycle approach, which means you can’t solve the problem just by adding features to, you know, the repository or the CI. And frankly, given that we were building Nexus Repo Pro back then – I mean we still are, but that was our main product back then – adding it as features on top of the Repo would’ve been the most natural thing for us to do, but we understood through all of that learning that that wasn’t going to be sufficient.

    It required integration to the Repo and to the CI and to the build and to the release automation tools, et cetera, et cetera, right, to be able to most effectively nuance the process of the components that flow through that, because you may choose to respond to a policy violation differently when something is about to actually be pushed into production versus something that’s just happening in your – you know, on every commit CI build. And so for that reason, being able to integrate into all of these tools, including all of the different repos, is just natural. It’s a natural evolution of the approach we’ve been taking the whole time.

    Shimel: Got it. So, I guess the next question is now that we have – you know, between the two repositories we’ve got high 90 percent of the market – how do we get 90 percent coverage with this Firewall product, right? I think we’d all sleep better. You know, what is the key, guys, to getting more people to realize this is kind of a no-brainer that they need to get done here, right? I mean what do you think is preventing us from really seeing this?

    Fox: Culture. Culture and history. I think there’s a history of application security tools specifically that, you know, are prone to false-positives just by the way they worked and led – and a history of bad approaches, like I was talking about before, that tried to force bad tools onto development that ultimately led to rebellion or disuse and gear grinding, and so in some ways the security tribe I think has become a little bit afraid to engage development in a lot of organizations, right? So they very much try to work at the end of the process, try to produce lists. We know that those things tend to get ignored, that they don’t usually have a profound effect on what’s happening, and so the organizations that are really successful are the ones that, you know, can set all of that history aside and still work together in a DevSecOps type of way and, you know, look at the problem holistically and understand that, yeah, actually it makes sense. If we can stop the bad things from coming into the process to start with we don’t have to chase them out later.

    The security guys don’t have to track it in the list and the Dev guys don’t have to go rework it, right? And so, you know, that’s kind of the approach that we’ve been trying to take, that all of these different constituents have an important job to play in the success of a business and it works best when [laughs] they’re all working together, not working against each other and throwing grenades over the walls.

    Shimel: Absolutely.

    Fox: And so really, you know, the biggest hurdle to adoption in most places just simply is that culture and the history of disdain and things like that.

    Shimel: Yeah, I agree, Brian. And guys, I’m gonna tell you something. Here’s a private theory that I’ve been working on and I’m gonna be speaking about it in the months ahead. You know, we’ve worked really hard – Sonatype more than most any other vendor I can think of – to advance the cause of DevSecOps. You know, Derek and Mark on your team and myself have been putting on DevSecOps events at RSA for the last five years now, and we do it in Singapore at RSA and we go all over the world with this DevSecOps thing. And recently, in the last couple months, I’m starting to see sort of a bifurcation in how security is dealing with DevSecOps, right?

    I’m seeing some companies that are embracing the Dev sides of things, and let’s call that DevSec. They’re working with developers to make the code more secure and make sure that pre deployment and everything is tested, everything is secure, and we release really tight, good quality, right? Security is synonymous with quality, and let’s call that DevSec. Then there’s another group of vendors, Brian, that are dead into what you’re talking about, right? They’re almost afraid, intimidated, or just fed up with dealing with developers, and they’re really focusing on the post deployment aspect of things here, right, and let’s call that SecOps, because they want to work more with the Ops folks, post deployment, you know, monitoring and that kind of thing.

    And I’m not saying that there’s not a reason to do that or it’s not right to do that – it absolutely is – but when we start looking at it as DevSec and SecOps, we’re committing the same mistakes that we did to begin with and we’re losing that it is DevSecOps for a reason. It’s Dev and Ops and Sec all working together. We can’t say, “Oh, we’re gonna work with the Ops guys but not the Dev guys or vice versa.” It’s gotta be everyone’s in it to win it. And I –

    Fox: Completely agree.

    Shimel: But I’m – yeah – but I’m seeing security vendors now kind of, you know, taking sides here on this. I’ve recently done a few podcasts – and some of them are new companies that are launching or coming out of stealth and RSA, and they’re growing this distinction that they’re SecOps, not DevSecOps, or they’re DevSec, not Dev – and I think it’s a huge mistake, a huge mistake.

    Fox: I think that’s largely led by the constituent. If you go and talk to the security guys, that’s what they’re gonna tell you that they want, right? It’s part of that history.

    Shimel: Yeah.

    Fox: You know, so if you allow yourselves to be pulled directly in the direction of what people want based on their perceived understanding of just how things work and that’s the way it’s always gonna be, that’s I think where you end up, so you have to buck that trend a little bit and say, “Guys, it doesn’t have to be this way. It can be better.” But we have to work together to do it, right, and we have to think about things a little bit differently. You know, and I have many conversations – you know, it’s happening more and more as AppSec and OPSEC is becoming more generally aware of the opensource component, you know, risk. They’re starting to come at the problem, but unfortunately they’re just trying to add more data to their existing process, and I have to remind those guys all the time that developers are picking new components all the time, they’re picking new versions of those components all the time.

    They’re not only doing it because you handed them a list of vulnerable components or a list of CVEs and said, “Fix it or else,” right? So wouldn’t it be nice if you had a process and a set of tools that could support them in that behavior so they don’t come on your list later? [Laughs] Right? And a lot of times that is like a shocking realization to that tribe, right, and that’s that culture that I was talking about. It’s a big challenge.

    Shimel: Agreed. And look, our work is not done, right? That’s what that means to me. We still have more work to do evangelizing DevSecOps and making sure people under – take a whole holistic aspect to it, and it goes back, Wayne, to what you were talking about in terms of the pipeline and the software, you know, automation and pipeline kind of thing, is it’s not bifurcated at the pre deployment versus post deployment juncture or junction. It – DevSecOps is about the whole thing from end to end.

    Jackson: Yeah, the organizations that can think about this holistically are just bound to be more effective and more efficient and, you know, to your point about evangelism, I mean one of the things that we’re going to see, and I think we are seeing, is that the most highly-performing organizations are the ones that are getting it.

    Shimel: Yeah.

    Jackson: They’re the ones that are gonna be leveraging software to more effectively differentiate their business. [Laughs] And at some point, unless you want to lose, you’re gonna have to start thinking about the ways that these, you know, forward-thinking, advanced organizations are doing what they do to make themselves better every day.

    Shimel: Absolutely. And you’ll have winners and losers, and look, that’s capitalism and that’s the market dynamics at play, right? You can adapt or die or not, right? I mean it’s up to you. Guys, we’ve spent a lot of time talking, you know, about this at a macro level. Brian, if you don’t mind, I’d like to get a little geeky on you and ask if you can explain to our audience at a nuts and bolts level really what’s going on with the Nexus Firewall.

    It’s software, right? It’s not an appliance, per se. Where does it sit, how does it intersect, how do you set policies in it? You know what I’m saying? Let’s give our audience a little bit of a…

    Fox: So our Nexus platform is kind of composed of maybe three parts. At the core is a piece of software that you run on prem or in your cloud that we call the IQ Server, and this is the thing were you define your policies, it’s the database of all of the components and which applications they’re used in, the dashboarding, the reporting; you know, all of that type of stuff occurs within the IQ Server. The IQ Server works with services that we have in our cloud to provide the real-time information around the components and the security and the licensing and all that type of stuff, right? So that’s a real-time feed, it’s not a data dump that you have to download periodically.

    And then there’s all of the plugins, the plugins that go into all of the places I mentioned before; your build, your IDE, your CI, your repository, your automation tools, et cetera, right? And so what we’re talking about here is we’ve added a new plugin that plugs into JFrog Artifactory. So when a component is being proxied from an external repo, such as Maven Central, the plugin will do the analysis of the thing being requested, it will understand what it is, work with the IQ Server to understand if it’s in compliance with the policy or not, and the depending on how the policy is configured it can either allow it, it can quarantine it, or it can just outright block it, right? So that’s the same capability that we’ve had for a couple of years now inside of the Nexus repository, so it replicates that functionality for our JFrog users.

    Shimel: Fantastic. Wayne, how are we going to market with this?

    Jackson: I get that question asked to me a fair bit, and we have a very multifaceted go-to-market model. You know, we still have folks that are very senior out in key regions that are evangelizing, because this is still an immature market, but increasingly as the market’s maturing are starting to lead with product and product capabilities in our marketing function. So, a mixed model, but one that we think aligns with where the market is in terms of its maturity, you know, that will change over time.

    Shimel: Understood. Guys, we’re almost out of time. If it’s okay I wanted to return back to the DevOps market in general. Wayne, you know, you and I kind of saw the security industry mushroom, right, from let’s say early 2000’s through even 2008, ’09, ’10, you know? I – and we now have both – and have both seen the DevOps market mushroom, you know, from 2013, ’14 to today. It’s only been four or five years. And, you know, we touched on it earlier with companies trying to kind of jostle for where they are, what they do and how they fit into this brave new world. You know, put on your visionary hat, if you will. Where’s this going? Where is it – you know, is there a logical sort of conjunction of security in the DevOps? And if so, what does that mean for the broader market? What do you think?

    Jackson: I disagree with you a little bit in that – with regard to DevOps having mushroomed. I think we in the industry kind of feel like it has because now all of the sudden people are starting to use our words back at us, but I think in terms of, you know, DevSecOps being a mainstream thing that’s just a part of how people work is still a bit away, and I think, you know, the work that you’re doing, I think the work that we’re doing and other vendors in this space is still enormously critical because even organizations that aspire to DevSecOps still need help. It’s not an easy thing to embrace and implement, as you know, and so there’s still some work to do, which I think is cool.

    Shimel: Yeah. Well, it keeps me going every day and gets me up. And you’re right, you know, we tend to forget that we live in a bubble. When you’re a hammer, everything looks like a nail, right?

    Jackson: [Laughs] Right.

    Shimel: When you’re talking DevSecOps all the time people tend not to look at you and say, “What are you talking about?” So, you know, we kind of breathe our own exhaust, if you will. But there is, there’s a lot of work to be done, even – forget DevSecOps – even in the basic DevOps level, right? When you – a lot of companies have dabbled in DevOps but how many are truly end-to-end DevOps, right, and that number I’m gonna guess is well – is below 20 percent, probably closer to 10 percent.

    Jackson: I think you’re right, I think you’re right.

    Shimel: Yep. So our work is still in front of us. But hey, you know what? It wouldn’t be fun if it wasn’t, right? I mean that’s what keeps us –

    Jackson: [Laughs]

    Shimel: Anyway, guys, when is this new plugin for Nexus Firewall available?

    Jackson: More or less now.

    Shimel: Okay.

    Jackson: I think the official release date is March 1, but yeah, happy to show it to anyone who’s curious to see and very proud of the technology.

    Shimel: Absolutely. And they can get more information at Sonatype.com?

    Jackson: That’s right.

    Shimel: Fantastic. Wayne Jackson, Brian Fox, CEO and CTO, cofounder of Sonatype, respectively. Thanks for being our guests on this episode of DevOps Chat.

    Wayne Jackson: Thank you. It’s been our pleasure.

    Fox: Thanks for having us.

    Shimel: Always a pleasure. Always a great time, guys. Okay, this is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat. Have a great day, everyone.

     

    [End of Audio]

    — Alan Shimel

  • DevSecOps Implementation Process and Road Map – Security at Every Step

    DevSecOps Implementation Process and Road Map – Security at Every Step

    DevSecOps is changing our perspective toward security and is equipping us to deal with its challenges in an intelligible manner. The systematic approach of DevSecOps helps us add value to our business processes while ensuring security.

    Here’s a summary of the key inputs and a recipe for a successful software development project. Implementing DevSecOps with the primary goal of enhancing security requires a step-by-step procedure.

    It requires the unification of culturally disparate teams of Security, Operations, Development and Test for the sole purpose of building a product marked by quality and backed by security.

    The DevSecOps process will require effective planning, design and release, which will be put together with a collaborative toolchain of technologies to bring about a common goal.

    Furthermore, as organizations continue to rely on automated delivery, avenues are created for testing opportunities beyond traditional bugs. In-house experts will be able to identify potential loopholes, design errors and even code weak spots.

    Being able to identify weak spots and flaws well in advance helps organizations maintain a competitive front in the market and trustworthiness before its target audience.

    DevSecOps Implementation Process and Road Map

    DevSecOps Implementation Process and Roadmap

    1) Planning: Planning is the first approach to any task at hand and the core focus of DevSecOps—security—begins from here. In the planning stage, DevSecOps professionals must go beyond creating feature-based descriptions. The focus should also be on security and performance, acceptance test criteria, application interface and functionality and threat-defense models.

    Tech terminology: Acceptance Test Criteria is used by DevSecOps professionals to understand user preferences and behavior to a software application behavior.

    2) Developing: Developers should approach DevSecOps with a “how to do it” approach, rather than a “what to do” approach. It is important for developers to bring together available resources for guidance, have reliable practices and a code review system in place for themselves and for others in the team to follow.

    3) Building: Automated build tools can uplift the whole DevSecOps implementation process tremendously. These tools ensure test-driven development, standards for release artifact generation and utilize tools to ensure the design aspect is in alignment with the team’s coding and security standards through statistic code analysis.

    They can also be used to identify vulnerable libraries being used in your application and replace them with new ones.

    4) Testing: Automated testing in DevSecOps should utilize strong testing practices including front-end, back-end, API, database and passive security testing.

    Tech Terminology: Passive Security Testing is a developmental stage testing where security testing is not conducted directly on the target.

    5) Securing: Traditional testing methods always remain in place in DevSecOps exercise. However, somewhere down the line, there is a tendency to identify issues toward the end of the development process.

    Through advanced practices such as security scanning, we tend to become more aware of the issues and can determine if the threat is a serious one or not.

    6) Deploying: Automated provisioning and deployment can fast-track the development process while making it a more consistent one. Infrastructure-as-code tools can perform the aforementioned audit properties and configurations and ensure secure configurations across the IT infrastructure.

    7) Operating: Regular monitoring and upgrades are the Operations team’s important tasks. DevSecOps teams ensure to deploy infrastructure-as-a-code tools to update and secure the entire organization’s infrastructure in a quick and efficient manner with no scope for human error. Operations personnel have to be especially watchful of zero-day vulnerabilities.

    Tech Terminology: Zero-Day vulnerabilities are a software breach that remains unknown to software productions personnel and can eat away at a computer program and other components such as a network.

    8) Monitoring: Constantly keeping a watch for irregularities in security can save an organization from a breach. Hence, it is essential to implement a strong continuous monitoring program with real-time to keep a track of system performance and identify any exploits in their early stages.

    9) Scaling: Gone are the days when organizations spent precious hours and money on the maintenance of large data centers. With the introduction of virtualization solutions and the cloud, organizations can scale their IT infrastructure or replace it in the event of a threat, which would be impossible to do with a traditional data center.

    10) Adapting: Continuous improvement is key to any organization’s growth. An organization will only be able to achieve the desired growth of it evolves in its practices including DevSecOps practices—security, functionality and performance. Therefore, an organization should adapt to continuous improvement and external changing trends.

    The DevSecOps is in itself a process of innovation that substantially adds value to an organization.

    Point to Remember: Security is everyone’s responsibility.

    — Veritis

  • Fail Fast: How Shifting Security Left Speeds Development

    Fail Fast: How Shifting Security Left Speeds Development

    How DevSecOps can help organizations increase security, move faster and save money

    With developers under constant pressure to create more software in less time, the last thing you need is for your code to fail at the end of the development lifecycle. No developer wants to create inoperable or insecure code.

    We know that most software products reach the market with flaws or vulnerabilities. On average, more than 85 percent of all software applications have at least one vulnerability, and more than half of flaws remain unaddressed for one to three months after first being discovered.

    The sooner a developer can identify, view and correct a flaw, the more efficient it becomes to fix in the software development life cycle (SDLC). That is the underlying philosophy of DevOps. Despite the somewhat negative connotation, failing early in development can be beneficial in deploying software to market more quickly.

    The most advanced organizations today employ a DevSecOps model, which tends to incorporate more frequent security scans, incremental fixes and faster rates of flaw closures into the SDLC. More importantly, it allows security teams to shift left to test software products against security standards earlier in the development process.

    According to Gartner, more than 80 percent of development teams will implement DevSecOps by 2021. In 2017, that number was around 17 percent.

    In Veracode’s latest “State of Software Security” report, we discovered companies that adopt a DevSecOps approach to development are addressing software vulnerabilities more than 11 times faster than companies that use a more traditional software development method. In the process, DevSecOps companies are innovating faster, saving money and becoming more efficient in how they identify and resolve new risks.

    By integrating developers with IT operations and focusing everyone on making better security decisions, DevSecOps can help deliver safer software with greater speed and efficiency.

    Introducing security earlier in the development process creates a sort of blueprint for teams to build within the specifications of major IT regulation and helps reduce risk by fixing vulnerabilities before they can be exploited. Think of it like building an apartment complex according to city codes with inspectors integrated in the construction crew.

    In practice, DevSecOps can add some friction and hinder the development process. Traditional tools for testing code and assessing application security risk simply weren’t built for the speed that DevOps testing requires.

    To make DevSecOps successful, development teams need to start with automated testing tools, as relying on manual processes can’t possibly keep pace with accelerated development timelines. Tools that can be used in an integrated development environment (IDE) are key, as they allow developers to integrate security into their workflow rather than having to launch a new environment whenever they need to test code. Solutions that check for flaws during the coding process enable developers to address vulnerabilities early on when fixes are the most cost-efficient. And because DevSecOps is equally concerned with security when software is in production, development teams need tools for testing applications after release. Development teams, meanwhile, must be comfortable with changing the way they work.

    Business leaders must recognize the importance of integrating security with development and communicate that priority to development teams. New regulations such as the EU General Data Protection Regulation (GDPR), which can fine companies up to 4 percent of their revenue for failing to disclose processes related to data breaches, are now in place. All businesses must be motivated to operate with a security-first mentality that permeates through the business, including within development teams. Veracode data shows that customers taking advantage of DevSecOps’ continuous software delivery are closing their vulnerabilities more quickly than the typical organization.

    DevSecOps doesn’t always require security personnel to be physically involved in the development process. Companies can and should train developers on basic security techniques and offer security resources to help developers become responsible for the security of the software they build.

    As the DevOps movement has unfolded, security-minded organizations have recognized that embedding security design and testing directly into the continuous software delivery cycle of DevOps is necessary. This is the genesis of DevSecOps principles, which offer a balance of speed, flexibility and risk management for organizations that adopt them.

    — Mark Curphey

  • How Software Outsourcing Can Empower Digital Transformation

    How Software Outsourcing Can Empower Digital Transformation

    Businesses are constantly readjusting themselves to become more agile and innovative while maximizing their opportunity in today’s digital economy. This is especially true for up-and-coming businesses with limited budgets that need to think ahead of the curve to find additional resources to fuel their digital transformation. Software outsourcing is no longer perceived as a choice or a strategic decision to be made, but rather an operational duty of the IT leaders trying to transform their organizations.

    Software outsourcing businesses often adapt better to the evolving digital landscape. Why? Because they aren’t afraid to look outside an organization to fulfill all the requirements needed to run a thriving business and cater to customer’s needs. Software outsourcing is seen by business leaders as an effective means of finding a balance between constant budgetary constraints and the need for a digital transformation. But what are some of the more prevalent outsourcing trends and how can they help empower your business’ digital transformation?

    Emerging Technologies

    The widespread adoption of emerging technologies adds another dimension to our everyday lives—artificial intelligence and machine learning, blockchain and IoT, automated SIEM software and the advancements in cloud computing capabilities. These technologies are skewing the already-blurred lines between our digital and physical worlds and are helping companies bring highly advanced solutions to the fields of business automation, customer management, risk and security orchestration, to name a few.

    Keeping an eye on such trends is one thing, but incorporating them into an existing business structure often requires outside expertise. Software outsourcing companies are, by definition, businesses that help other businesses with the development, design, maintenance and testing of their software application and solutions. As such, leading providers in software outsourcing are constantly looking out for the latest tech advancements the market has to offer and craft their much-needed expertise accordingly.

    Outsourcing providers represent the important link between the customer’s growing demand for technologically driven solutions and services and the companies trying to provide them. It seems that every business nowadays wants and AI or machine learning-powered answers to their problems. Instead of having to hire a full-time specialist to help them execute a specific task, companies can simply outsource the needed expertise and use their resources on core competencies.

    Data Privacy and Security

    Advanced software solutions such as AI and machine learning require massive amounts of user data to prove effective. Collecting user data is one thing, but guaranteeing data privacy and security is a whole different ballgame. As the number of cybersecurity breaches increases over time, so does the demand for data loss prevention, data security automation and advanced threat intelligence. The only way for software outsourcing companies to satisfy this demand is to fully comply with security regulations and industry standards.

    The General Data Protection Regulation, or GDPR, has standardized the data protection law in the EU, imposing strict rules in regards to the collection, control and processing of personally identifiable information. Outsourcing vendors are now obligated to conduct their security audits regularly and use that information to update their security strategies and meet the new security requirements.

    Doing this allows them to determine the most effective policies for data protection and guarantee availability, responsibility and quality of their service-level agreements.

    A successful outsourcing agreement cannot be made if your potential partner doesn’t follow the latest security standards or doesn’t have a clearly defined security policy. The best way to protect your business against potentially hazardous data breaches is as simple as looking for outsourcing providers that have security testing in their service offerings. Agency listings and repositories are an excellent place to start, as they tend to provide the much-needed reviews and rankings of potential providers.

    Increasing Talent Shortage

    Labor markets are having a hard time keeping up with the rapid pace of tech development. Talent shortage continues to be the No. 1 challenge even in the booming areas of the world such as the UK and the United States. A large number of tech-oriented startups enter the market each and every day and staying above the competition requires expert help with highly specialized skill sets.

    To combat the increasing difficulties of finding expert help locally, businesses are turning toward less dynamic regions for their software outsourcing needs. Eastern Europe, for example, is far less saturated with tech startups when compared to the United States, yet manages to provide a sizable talent pool, as well as a large number of outsourcing providers to choose from.

    Digital Transformation and the Benefits of Software Outsourcing

    Businesses outsource expert help when dealing with parts of the digital transformation process for which they have little to no expertise whatsoever. This allows them to close any gap they might have had regarding their digital capabilities and focus their efforts on core transformation objectives. Collaboration is a vital part of outsourcing and, as such, provides valuable information regarding the latest business insights and disruptive technologies.

    Outsourcing software leads to a successful DevOps journey. It allows businesses to find providers specialized in the digital transformation process. Some providers offer a multidisciplinary expertise that encompasses AI and machine learning, big data tools, digital mobility applications, scalable cloud solutions and more. Working with distributed engineering teams who already have the necessary domain-specific expertise can result in a faster time-to-market and increased customer satisfaction.

    Digital transformation comes with many challenges and software development outsourcing should not be viewed as the go-to solution for every problem. It is one of many crucial parts found in the larger digital transformation framework. Business automation, emerging technologies, the latest security practices and value-added services—these are the cogs in the software outsourcing-fueled machine that is digital transformation.

    — Natasha Lane

  • Study: CISOs Need to Take Charge of DevOps Security

    Study: CISOs Need to Take Charge of DevOps Security

    A new report from CyberArk looks at the complexity that goes into securing emerging DevOps environments, and why CISOs need to take charge to protect them.

    As digital transformation is pushing more enterprises to adopt DevOps to address their needs for better software delivered faster and more frequently, a huge issue lingers over this strategic business shift: security.

    While businesses pay a good deal of lip service to cybersecurity, the rush to churn out new software and update those applications means that security is often skipped in the name of speed and innovation. At the same time, InfoSec is seen as a cumbersome barrier to what the DevOps team is trying to achieve.

    Despite these attitudes, it’s imperative that security is part of DevOps conversations, and it’s the company CISO who needs to lead that charge.

    In a report released last month, CyberArk polled 1,000 CISOs across the globe to assess how to make DevOps more secure and to ensure that the cybersecurity team is talking to the CIO and other executives overseeing the DevOps process to solidify good cybersecurity.

    The report, “Protecting Privileged Access in DevOps and Cloud Environments,” actually skips the more trendy term of DevSecOps in favor of a more holistic approach that bakes the security component into the very beginning of the application development cycle.

    Brian Kelly, the head of Conjur Engineering at CyberArk, believes that the DevSecOps term limits the ability of CISOs to offer ways to secure application development at the beginning of the process and ensure that updates embrace good cybersecurity practices.

    “Some organizations embrace it, while others refuse to use it,” Kelly wrote in an email about the debate over the DevSecOps term. “We do not use the term because it implies that security is a ‘gate’ or ‘phase’ that can be done after development is finished—but before the apps go operational. Security isn’t just a bolt on to DevOps, and this mentality can lead to a lot of broader issues for operation and development teams.”

    This means ensuring security is a part of every DevOps conversation, including making it part of hiring, training, road map creation, feature design, architecture, coding standards, code review practices, continuous integration/continuous delivery (CI/CD), operations, monitoring and maintenance.

    The CyberArk report makes clear that many of the tools needed to make DevOps successful within the business are a tempting target for cybercriminals looking to burrow deeper into the corporate network. For example, cloud access keys—whether for AWS, Microsoft Azure or Google Cloud Platform—can open a wide range of company data for threat actors to steal.

    The Uber data breach of 2016 started when the company’s AWS access keys were compromised.

    Other targets include CI/CD tools for configuration management, including Puppet, Chef and Ansible, as well as tools for running automated tests and builds and this can include Jenkins and Bamboo.

    Another red flag for security teams and CISOs is GitHub, since developers tend to have multiple accounts, and can sometimes mix code from personal and corporate projects. A cyberattack using brute force methods can sometimes leave code exposed. Since many developers cook some secrets into the code, such as database credentials, this can expose company and customer data.

    “[GitHub] hosts most of the world’s code for modern projects (and almost all open source projects) so any security mistake they make will have wide-reaching consequences,” Kelly wrote. “Up until now, they’ve been able to sidestep many issues by just being a hosting provider for repositories and leaving the responsibility to their customers for what they push up there. But they’ve since added more features for collaboration and CI, which naturally make their users want more of a safety net: automated scanning of third-party libraries for CVEs or watching for things like AWS keys being checked in, for example.”

    With all of these difficulties, what can the IT and DevOps teams do to increase security? How can the CISO help make security a central part of the app development process? Kelly offered some practical steps enterprises and their leadership can take:

    • Engage security teams early in the development cycle. This helps identify security issues early in the process.
    • Use a security-policy-as-code approach to have the Dev, Sec and Ops teams communicate efficiently and unambiguously. This means that new applications or microservices would declare their security policy requirements within code. It gets checked into source control and is as much a part of the application’s code as its internal implementation.
    • Decomposing large applications into smaller microservices, each with their own security policy.
    • Reducing the “batch size” of changes as much as possible, enabling the security team to work on a smooth, predictable flow of small items.
    • Getting end-to-end early to mitigate the risk the ongoing upgrades of components and modules.

    At day’s end, while CISOs need to lead the security charge when it comes to application development and delivery. At the same time, DevOps isn’t a fad, and will remain part of the enterprise for a long time. Security leaders need to do some embracing of the trend, too.

    “If CISOs want to remain relevant, they will need to see DevOps as a model that they have to align with, not against,” Kelly wrote. “Recent history shows us that large, org-wide DevOps initiatives rarely get shut down once they start, so a successful CISO will build bridges to the Dev and Ops groups and work with them to apply visibility controls and security oversight in ways that don’t cripple their speed. A failing strategy would be for the CISO to resist that sea change and instead try to be a gatekeeper and hold up inevitable progress. The only progress they’ll likely see will be in the speed of their replacement getting hired.”

    — Scott Ferguson

  • Salt Security Unveils Platform to Secure APIs

    Salt Security Unveils Platform to Secure APIs

    Salt Security, fresh off raising an additional $10 million in funding, announced a platform that promises to advance the state of DevSecOps by making it possible to detect when application programming interfaces (APIs) are being probed by cybercriminals looking for weaknesses to exploit.

    Salt Security CEO Roey Eliyahu said the Salt Security API Protection Platform employs machine learning algorithms to first establish a baseline for how APIs are being invoked across an IT environment. The software-as-a-service (SaaS) platform then monitors activity to surface any anomalous behavior indicative of cybercriminals engaging in reconnaissance of API traffic flows, he said.

    Armed with that analytics, DevOps teams can then prioritize fixes to any potential security hole cybercriminals might be able to exploit. That approach advances DevSecOps because the Salt Security technology makes it possible to feed requests to address those security issues directly into a continuous integration/continuous deployment (CI/CD) platform—critical, he said, because all too often developers are unclear regarding what cybersecurity professionals are asking them to fix whenever a cybersecurity issue arises.

    Eliyahu noted that, in today’s business environment, security has become a major concern. According to the Open Web Application Security Project (OWASP), nine of the top 10 vulnerabilities in its current Top 10 report include an API component. Insecure APIs were ranked as the third most severe threat to cloud computing in 2018 by the Cloud Security Alliance (CSA), and Gartner predicts that by 2022 API abuses will be the most frequent attack vector resulting in data breaches for enterprise web applications.

    The challenge organizations face is each API is unique to each application and the organization that builds them, which means each has unique logic and, by extension unique vulnerabilities, said Eliyahu. Existing cybersecurity tools lack granular understanding of these because they are designed to protect organizations from known attacks. Attacks that target API logic go unnoticed by these tools because they appear to be authenticated use cases, and then employ subtle methods to probe each for unique vulnerabilities, he noted.

    To thwart those attacks, the Salt Security technology automatically discovers all APIs and associated functionality, said Eliyahu. That’s important because it’s not uncommon for organizations to lose track of the many that might have been exposed over the course of an application’s lifetime.

    APIs in general are often overlooked because much of the focus in any organization tends to be on business logic. But as the number of applications and services continue to proliferate across the enterprise, the number of APIs being exposed has increased dramatically. Those numbers will increase more as organizations embrace microservices to build applications that are more easily updated.

    The issue, of course, is how to secure APIs that often are developed and maintained by teams that weren’t involved in the integration of the original application. Because of that issue, API management has emerged as a discipline unto itself within many organizations. The challenge now is finding a way to ensure those APIs are employed as intended, versus becoming an avenue for data exfiltration that no one is aware of until it’s long too late.

    — Mike Vizard

  • IoT, Not People, Now the Weakest Link in Security

    IoT, Not People, Now the Weakest Link in Security

    Do a quick search on “people weakest link” and you’ll see a raft of articles in which cybersecurity experts and computer scientists point to employees or end users as the biggest vulnerability. No doubt, people do silly (or outright abusive) stuff and open the door for a variety of enterprise security problems. Spoiler alert: There’s this technology called the Internet of Things (IoT) and it’s a bigger security risk than people ever were. The new theme of this rapidly changing IoT security story is data integrity.

    Increased cybersecurity risk is due in part to the variety of environments IoT applications touch. Most at-scale IoT deployments use some form of a three-tier architecture, with edge, gateway and cloud components.

    • Edge devices are those connected sensors and actuators touching the real world. They are usually small, low-power devices often running a wireless protocol such as Bluetooth, Thread, ZigBee, Z-Wave, sub-GHz, low power wide area (LPWA) networks, cellular IoT technology, Wi-Fi or other protocol.
    • Gateway devices are hubs that groups of sensors connect with. One big role of the gateway is to translate the various protocols from edge devices into Internet Protocol (IP) for transmission into an enterprise network. Gateways also perform a key role in provisioning edge devices securely. Smartphones running Android or iOS often serve as a gateway for consumer IoT devices. For industrial IoT devices, multiprotocol gateways typically are built on a small form factor computer running a real-time operating system or Linux. Edge computing or fog computing architectures use enhanced gateways for more algorithm processing.
    • Cloud platforms are very familiar to most enterprise developers. In IoT apps, data from the edge arrives for processing, storage and presentation. Algorithms can run on a server cluster or in a distributed computing framework such as Hadoop or Apache Spark. Business intelligence and predictive and prescriptive analytics also reside in the cloud.

    In our practice, we see many IoT cybersecurity issues that can be mitigated with proper attention to two areas. The first is shutting down simplistic endpoint attacks by using basic connected device security measures. Avoid edge devices that ship with a well-known default password or PIN—compromising those defaults can be as easy as a battery pull and a factory reset. If a device uses encryption, make sure it doesn’t use a hardcoded key that, if cracked, compromises an entire family. Look for edge devices using over-the-air (OTA) programming allowing for security updates over a long life cycle. As more device developers gain IoT security experience and provide the right features, closing these basic weakest links is easy.

    Now, for the more startling weakest link. When the IoT application runs, is the data any good? According to a just-released survey of 950 IT and business decision-makers, only about 48 percent of companies are confident they can detect an IoT security breach. (BTW, don’t get me started on blockchain; it’s one tool, not a panacea.) A lot can happen before your people get involved. By then, it may be too late.

    Data integrity needs constant monitoring during at-scale IoT deployment, not just during pilot. An easy way into an unprotected IoT network is to add an unauthorized edge device at a gateway, then use it to access other devices. Gaps in end-to-end encryption are also easy exploits. Untrustworthy public cloud elements are also bad news—a big reason we recommend hybrid cloud architecture. A private cloud layer gives you more control over algorithm performance and data stream security. Presentation and archiving can be left to a public cloud layer.

    Bad data can come from either a compromised or faulty device. It propagates quickly across a system, and when an unwitting user at the presentation layer runs a business intelligence tool on it, the bad data could cause issues. How do teams hunt down vulnerabilities and faults that lead to corrupted data and results?

    • Hire a penetration tester, preferably a contractor removed from your day-to-day development who can objectively assess your architecture during pilot and reassess it during deployment.
    • Ensure your architecture can tolerate edge device or gateway failures without ripple effects in algorithms; in other words, protect the application from prolonged operation on bad data streams.
    • Before turning AI loose on automated decision-making, consider an AI-based IoT security analytics tool to spot anomalies and quickly bring people into the loop.
    • Retarget at least part of your cybersecurity experts to ongoing data integrity efforts and help them stay abreast of IoT technology and trends.

    This all sounds like a good job for DevOps, doesn’t it? You know what to do about people; now you’ll need to work magic with devices. The long-held security axiom that people are the weakest link is no longer true when IoT applications run unattended all the way to presentation. There are a few exceptions when people have more interaction at the edge, particularly in the medical device arena. Generally, we’ll see bigger and bigger IoT applications with more data, more processing and less interaction with people.

    If someone on the IoT says there’s a security hole you can drive a truck through, they may mean it literally. Data integrity measures will be critical for DevOps teams moving forward. Do you agree? What types of data integrity issues are you seeing in IoT applications?

    — Don Dingee

  • How to Turn Your DevSecOps Shift into Your ‘Pixar Moment’

    How to Turn Your DevSecOps Shift into Your ‘Pixar Moment’

    If you have worked in security as long as I have, you have seen that vulnerabilities persist, despite years of attempts to fix them without changing how the organization operates. One of my all-time favorite leadership quotes comes from the first stockholder meeting after Robert Iger, the CEO of Disney, bought Pixar. “The riskiest thing we can do is just maintain the status quo,” he said. This quote has stuck with me and I feel that the shift to DevSecOps can be many teams’ “Pixar moment.”

    In recent years, there has been a push to shift to a DevSecOps model that has the potential to make a drastic change in the way an organization operates. But unless these shifts are planned well, they often fall apart without having made a meaningful impact.

    The root cause is often the inability or unwillingness to do the in-depth planning and testing required to make sure everything will move to a DevSecOps smoothly. The failure to plan leads to underwhelming returns and low morale with the organization will slowly slide back to the old “status quo.”

    Moving to DevSecOps is often more about changing an organization’s cultural identity than any technical changes. I’ve have seen it happen successfully in several places. Here’s what they had in common:

    They Defined, Discussed and Documented the Old and New Build Process

    A successful move to an end-to-end CI/CD system normally starts with one thing: a whiteboard. Organizations bring representatives from every existing team (systems, networking, security, development) to form the new DevSecOps team and build an end-to-end diagram of what it takes to build and maintain the system immediately. For many, this meeting is often the first time they have seen a true end-to-end view of the system.

    Then the new team commits resources to discuss the standards and policies they need and want the new system to be built to. They discuss methodologies, deployment schedules, SLAs, business requirements and overall system architecture and security. This is where the team must come to an agreement on the right way to build and where the security team is likely to see their first big win on improving the “status quo.”

    This round ends with something that no one on the new team will likely enjoy, but is crucial to the shift moving forward: a document of all of the decisions made that can be easily shared within their organization.

    They Built a Strong Team and Platform

    The next step is normally everyone’s favorite part—at least at the start. The team gets to walk into a greenfield environment and move one application to their new DevSecOps flow. Essentially, each team member has the opportunity to bring their ideas and thoughts about modern security, architecture and deployment processes and see if they can apply them. However, the honeymoon period of this process often ends quickly and becomes the most challenging segment of the whole process. The switch from theory to practice isn’t as clear as many DevSecOps teams think, and it’s common for teams to struggle while working with new products with which they likely have not had much organizational experience.

    Buy-in from leadership is critically important here and without it, these projects can quickly go awry. I have heard executives complain that their DevSecOps team is “just playing around,” “wasting company resources” or “learning skills that will just let them get a better job somewhere” when a new system seems to take longer to be built than originally expected. Supporting this team throughout the build process is one of the most important leadership roles in a move to DevSecOps and plays a crucial part in aiding this team and reinforcing its culture within your company.

    Continual Incremental Improvements

    Once you have your first DevSecOps flow created, it is important to remember that you are not done, as you would be in a traditional build model. Of course, you want to celebrate this success, but you also need to start answering these questions:

    • What can we do to increase the deployment frequency and speed?
    • Can we do anything to lower the failure rate of the new releases?
    • Are there any steps that could be more automated?

    If you continually ask and answer these questions, you will never be done, but you will continue to make incremental improvements that will help your organization become more agile over time.

    Rinse and Repeat

    Once you have built your first DevSecOps workflow, you now have a good baseline on what to do (and not to do) when you move your next application to this model. Hopefully, you’ll be ready to move the DevSecOp culture that has taken hold in your organization to the next team.

    — Jerry Gamblin