devopsy.kinsta.cloud

Tag: software security

  • DevSecOps vs. Agile Development: Putting Security at the Heart of Program Development

    DevSecOps vs. Agile Development: Putting Security at the Heart of Program Development

    Despite most developers and managers being well aware of the concept of DevSecOps, it is still often confused with a number of related processes and concepts. This is particularly true for the Department of Defense (DoD) contractors because they have long been encouraged to use a related process known as agile development. 

    Since agile development has been around for more than a decade, there is a tendency for organizations to regard DevSecOps as an extension, or even a synonym, for it. In reality, though, the two approaches are distinct. The objectives of both approaches are similar: balancing speed and agility, detecting risk early and both focus on cloud-native security and performance. 

    However, while DevSecOps does build on some agile development principles, such as the continuous integration and delivery of software systems in cycles, its key emphasis from the beginning of the process is to integrate security features, while Agile only focuses on delivering software.

    In this article, we’ll look at the key differences between agile development and genuine DevSecOps processes, and how each complements the other.

     

    DevSecOps vs. Agile Development

     

    The difference between DevSecOps and agile development methodologies can be understood in reference to one aspect of software development: security. When, where and who implements security in software development varies between the two approaches.

    Agile development methodologies focus on iterative development cycles, in which feedback is continuously reintegrated into ongoing software development. However, even in mature agile development processes, security is still often added to software as an afterthought. This should not be read as blaming software developers for often underestimating the potential harm from malware or overlooking the importance of cybersecurity. 

    Rather, in many firms, it is simply not the responsibility of developers to think about the security implications of their code, because software will be passed to the security team before release.

    DevSecOps takes security and puts it on the same level as continuous integration and delivery. DevSecOps methodologies emphasize security at the very earliest stages of development and make security an important part of overall software quality.

    In essence, these approaches shift the program manager’s perspective away from making sure that software is in compliance or meets a specification or audit, to ensuring that the code is written correctly and securely and that it’s deployed in a repeatable manner.

     

    The Changing Culture of the DoD

     

    The adoption of DevSecOps methodologies is critical for DoD contractors because these methodologies reflect DoD’s own modernization strategy. Following high-profile vulnerabilities being discovered in all types of systems, DoD seems to have released that cybersecurity weaknesses are not just a potential threat to critical defense data, but also impose a significant operational bottleneck on the continuous delivery of functionality.

    At the moment, even those firms who possess a mature agile development framework can find that the multiple security checks and compliance processes that must be performed on software, prior to shipping, can detrimentally impact on their ability to deliver iterative software improvements. This is the issue that the transition to DevSecOps seeks to overcome, by attempting to shift organizations’ approach to cybersecurity away from compliance, and toward genuine security consciousness.

    At the same time, analysts are aware that shifting responsibility for cybersecurity onto developers will be uncomfortable, and potentially dangerous, for many DoD contractors. Developers working on the base code for military software do not have – and are not expected to have – an exhaustive appreciation of all of the contexts in which this will be deployed, and exactly which systems their software will be required to interface with.

     

    Automation and New Models

     

    In response to these concerns, DoD contractors are reappraising the DevSecOps model and thinking seriously about how it can be deployed in contexts where continuous service delivery is key. There are three key ways in which this is happening.

    The first is the rise of automation. The types of large-scale, multicloud infrastructures that most contemporary DoD projects rely on can often necessitate repetitive, ongoing maintenance and security assessment across both development and security teams. DevSecOps replaces these human checks with automated systems: Instead of requiring a person to go through checklists of hundreds of controls, this is done automatically as part of the software development and supply process pipeline. 

    The second key element in the transition to DevSecOps is endpoint security. The types of monolithic development processes that DoD contractors traditionally worked with are not suited to the contemporary deployment environment of many DoD projects. In these traditional methods, systems were built as discrete holes, with no expectation that data would be exposed as it moved between components. 

    This is now an obsolete approach: In DevSecOps processes, virtual private networks are used to provide security and encrypt data as it moves within a network, and the principle of least privilege reduces staff access to small portions of It environments. 

    Thirdly, a new generation of younger military and civilian personnel in the DoD, many of them trained in the commercial sector rather than entering the military directly from college, are bringing corporate approaches to the development of military software. This is seen in the exponential increase in the utilization of cloud services in DoD applications, and more dynamic and distributed managerial frameworks that distribute security responsibility across entire organizations, rather than having this as the sole remit of a dedicated security team.

     

    Get Support

     

    Moving to a truly DevSecOps methodology is likely to be a challenge for many contractors. However, just as in the last decade many firms have had to redesign their development lifecycles in order to be agile, now they will need to achieve secure development lifecycles in order to stay competitive.

    If you are looking to make this shift, you should also recognize that you are not alone. DoD is working actively with its partners in order to facilitate the roll-out of DevSecOps processes and to make commercial tools and techniques available and useful for military contractors because the department recognizes the value of this methodology for the software they commission. 

    This is seen most clearly in the recent updates to Microsoft Azure Government, though you should also be aware that many of the resources recently released by the Defense Logistics Agency are also focused on the transition to DevSecOps.

    In short, whilst the transition to DevSecOps may be challenging, it will be no more so than the earlier shift to agile development. To make this shift, however, firms should draw on the resources available to them, recognize the value of integrating security into their development workflows and build on existing agile frameworks.

  • DevOps Chat: Enterprise Multi-Cloud Backbone With Aviatrix

    DevOps Chat: Enterprise Multi-Cloud Backbone With Aviatrix

    Our podcast guest believes the world changed “on a Tuesday” six months ago when the enterprise move to the cloud became imperative, not just an aspirational goal. That eureka moment was enough to pull Steve Mullaney off the sidelines and back into the game as CEO of Aviatrix after successful executive gigs at Palo Alto Networks and Nicira.

    “Go build” might be a wonderful approach for cloud-native apps, but enterprises want the framework laid out ahead of their move to the cloud. Think enterprise cloud IT reference architecture, much like Cisco provided for enterprise IP networks, DEC mainstreamed for client-server and IBM established for mainframe computing. You have to bring the cloud to them. That enterprise cloud reference architecture is what Aviatrix targets, in the same buy-with-a-credit-card model that fueled customers’ unfettered move to AWS.

    On our DevOps Chat podcast episode, Steve Mullaney, CEO of Aviatrix, talks about what enterprises want in a true enterprise multi-cloud backbone to support their needs.

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

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Steve Mullaney, CEO of Aviatrix. Our topic today is enterprise multi-cloud backbone—meaty, good stuff.

    Steve, welcome to DevOps Chat.

    Steve Mullaney: Thanks for having me, Mitch.

    Ashley: Great, good to have you here. I’d like to start by having you introduce yourself. I know a lot of us know you from your background, you’re a fairly well known guy, but tell us about yourself.

    Mullaney: So, yeah, my name is Steve Mullaney, I’ve been in networking and security infrastructure for, really, the past 35 years. I actually started my career in the mid-80s as we were kind of evolving from, transitioning from the mainframe computing model into client server. I was actually an engineer on 10Base-T from the company called SynOptics. So, those of you who’ve been around long enough to remember when Ethernet was starting and—

    Ashley: I do recall.

    Mullaney: 10Base-T started, yeah. So, I spent most of my career in networking and security, I was a very early guy, actually, also at Palo Alto Networks, I was the first VP of Marketing there, employee number 25. And then was CEO of a company called Nicira, which was really kinda the beginning of a lot of this SDN craze and network virtualization. We were acquired by VMWare, and then I stayed at VMWare for a couple years and grew that business, which is now almost a $2 billion business and a ________ business.

    And then, for the last five years, I just, I kind of said no more operational roles and was on boards and I was content to just do that the rest of my life and very happy living the dream. And I saw the world change about six months ago, where enterprises have been talking about the movement to a cloud computing model—honestly, talking about it for the last 15 years, but I noticed really about 6 months ago is when mainstream enterprise really said, “Okay, we are doing this.” And I just looked at that opportunity and said, “My God.”

    And I was on the board of Aviatrix at the time, so I could see this happening up front and just said, “This is just gonna be too much fun not to be involved.”

    Ashley: So, what was it? What was it six months ago or so? When was the nexus point when you saw a change that pulled you out of retirement?

    Mullaney: Yeah. What was interesting was, I love to say, six months ago on a Tuesday. And it felt almost like that much—like, literally on a Tuesday. And that’s how enterprises move, right? They talk about it, they talk about it, they talk about it, they talk about it. It’s like going on a diet. You talk about it and, “I’m gonna go on a diet.” “Well, how about today?” You’ll say, “Well, you know—not a good day.” “Well, how about tomorrow?” “Well, you gotta start on a Monday,” right? And then, “How about next Monday?” “Well, that doesn’t really work, because I’m going on vacation.”

    I mean, there’s all these excuses, and enterprises, about five years ago, really said, “Alright, we are gonna move to the cloud.” And honestly, that’s when every enterprise vendor went, “[Gasps] We’re dead!” Right? “We’re dead. Everything’s gonna go into Amazon and we’re dead.”

    Ashley: Mm-hmm.

    Mullaney: And what happened was nothing, because the enterprises were just talking. They didn’t really mean it, right? So, everyone went along their merry way with quarter after quarter of record highs. Until about six months ago, I’m on the board of Aviatrix, a bunch of other infrastructure companies and I notice the logos are changing. This isn’t Netflix any more, this isn’t small to medium businesses, these aren’t early adopters. These are Midwest manufacturing, conservative companies. What the heck is goin’ on? They shouldn’t be doing this!

    And people think just because AWS is at a $30 billion run rate that we must have crossed the chasm by now. We haven’t. And I’ve noticed, across all of my infrastructure companies that I was on the board of, they’re seeing all the same thing. No one’s done anything different, it’s just, the market just changed. And the way enterprises go, they are a herd mentality. When the majority, you know, the early and late majority of customers all decide to do something, they all decide on the same Tuesday morning, and I saw that happen.

    We saw it with client server. I was at SynOptics at the time. Mainframe computing was the way you did enterprise computing, and client server—PC client server was treated as a toy, just fun and games. So, print sharing, right? PCs—that’s not real computing, right?

    Ashley: Mm-hmm, mm-hmm.

    Mullaney: And then what happened? All of a sudden, in the early ‘90s, on a Tuesday morning, everybody decides the Internet Protocol is the only protocol that matters. All the other protocols went away overnight, and PC client server is the way I’m gonna build up my architecture—and it happened overnight. I saw the same thing happen with cloud.

    Ashley: Mm-hmm. So, it’s really kinda going mainstream, you’re seeing a real—

    Mullaney: It’s gone mainstream. And I’ve been at the company now for three months as the CEO of Aviatrix and every day, I just see more and more evidence of that, that companies are burning the boat—meaning, the corporate data center, the corporate backbone that is dead. It is now an expense. I view it as an expense, and I view anything I do in the public cloud, leveraging the public cloud, as an investment.

    Ashley: Mm-hmm.

    Mullaney: And that means all my people are focused on that as well as all my expenses. And it shifts overnight, and it’s a herd. Every single enterprise around the world is now making that same decision on the same Tuesday morning.

    Ashley: Mm-hmm. I love your Tuesday morning analogy.

    Mullaney: Isn’t it funny? It’s really true, though—it’s really true!

    Ashley: [Laughter] It just seems like it suddenly happened.

    Mullaney: Yeah.

    Ashley: So, you’re on the board of multiple companies. What was it about Aviatrix that you said, “This is the one I’m gonna ride. This is the one I’m jumping on board, I’m gonna be CEO, take this baby where it’s gonna go”?

    Mullaney: Yeah, I think it goes—because it goes in terms of what we say our mission, our mission is to build the enterprise multi-cloud backbone.

    So, when you look at AWS and Azure and GCP and even AWS’ mantra to enterprise is, “go build.” Well, that’s great when you’re an early adopter and they hand you the power tools, and you—

    Ashley: Mm-hmm, the greenfield.

    Mullaney: Yeah and you are that innovative, you wanna go build. That does not go very well when you’re a Midwest manufacturing, conservative company. I’m gonna cut my arm off with power tools. I don’t want power tools. I want a house, I want furniture, I wanna walk in with it done. I don’t wanna build anything.

    Ashley: I want a landing strip, I don’t wanna build the runway.

    Mullaney: Absolutely. I do not wanna build. And so, I think this, honestly, has caught AWS off guard, too, right? Because they’re thinking—all of our customers love that, a “go build” mantra. Not the mainstream, right? Not when it flips. Not when you’ve crossed the chasm and now you’re in the tornado and everybody just, they’ve gone and said, “This is it.”

    And so, I looked at that, and I said, “My God, all of these enterprises are begging—begging—someone to define the architecture for them.” This is just like in the client server where they needed Cisco to come out and define the networking and security architecture for them. Give me the canonical architecture that everyone’s gonna do, and then I will go implement that.

    Ashley: And it’s proven, we’re not inventing.

    Mullaney: And that’s what people want, and they want a validated design. They wanna be able to go, “This is what everyone’s doing, we’ve all agreed, this is what you do. And oh, by the way, I can’t get that from Amazon, because Amazon’s trying to lock me into Amazon. I can’t do it—I can’t get it from Azure or Google. I can’t get it from the old world, I can’t get it from Cisco, because they don’t even understand this,” right?

    Being able to—it’s just like, you wouldn’t go to IBM or Deck for the client server architecture. This is a whole different computing model. You can’t—by definition, the leaders of the old are never the leaders of the new. So, who do I go to?

    Ashley: Yeah, and to the point of multi-cloud, you’re probably not gonna be in just one, yes? It might be appealing to be in Azure for some Microsoft apps, but you also have compelling reasons to be elsewhere.

    Mullaney: I have not met an enterprise that says they’re only gonna be in one cloud. They’re in at least three. Because then you’ve got, if you’re in China, you’re in Alibaba. Then you’ve got, you know, data sovereignty and GDPR and all these kinda other issues that I may have to have multiple providers in Europe, country by country, right? And not even AWS.

    And so—sure, absolutely, it is going to be, and it should be. Because not that you’re gonna move workloads between one to the other. Like, that’s not gonna happen. But what is gonna happen is, maybe the marketing team likes GCP for AI reasons or, you know, I started with Office 365 in Azure and so I’m moving off on that. Or I’m a big enterprise, manufacturing enterprise and Microsoft really understands me. Or I’m a retail and I will not have anything in AWS, right?

    Ashley: Yeah.

    Mullaney: Or I see, even, I’m a customer, I’m a company—a software company. I’m selling to other enterprises. I cannot have my infrastructure if I’m selling to retail. I cannot even have my own internal infrastructure on AWS because they don’t want that to happen.

    So, absolutely, it has to be across all this. And then the other thing is the “go build” mantra—so, even if you could say, “I can figure out how to go build on AWS,” the constructs in Azure and GCP are different.

    Ashley: Right, you’d have to go build everywhere.

    Mullaney: So, now I need to learn those constructs, and now I have to go build there, but with different tools that work differently—like, one’s in metric and one’s in an American system. It’s like—oh, my God, you know? And the tools don’t work. Like—okay, this is ridiculous.

    Ashley: So, you painted a picture of multiple compelling reasons somebody needs to lay the groundwork for me. I’ve gotta be multi-cloud, so I need that reference architecture that’s gonna work across multiple providers. I don’t wanna stick build any more, I wanna be able to walk in and plug my application into a framework, a reference architecture that I can use—that’s what Aviatrix is about?

    Mullaney: Yes. And then layering on top, leveraging the constructs, right? Leveraging the wonderful underlay, right? Of all—think of all the fiber, and the pops, and the data centers, and the regions, and all the wonderful stuff underneath that AWS Azure and Google provide, and growing.

    Ashley: All that infrastructure you don’t have to do.

    Mullaney: That is unbelievable, right? And guess what? I’m an over the top networking and security software player. So, when you think of guys like WhatsApp, you know, AT&T used to always get really mad because WhatsApp gets bought by Facebook for like 30 billion or whatever it was, and AT&T with all their fiber and all their different pops and all their right of ways and everything else like that—what’s their market cap? I don’t know. Probably not even much more than that. And you go, “Why is that? Like, I do all this stuff and I get no credit.”

    Ashley: Spend a lot more money getting there.

    Mullaney: And then WhatsApp with, you know, six engineers gets bought for $30 billion, where’s that? Well, yeah, because the over the top guys, that’s where all the value is. They’re leveraging it.

    So, in a sense, we are an over the top software player, but what we’re over the top of is not the internet on top of AT&T, it’s the new internet. It’s the hyperscalers. It’s AWS, Azure, Google, et cetera, all with massive bandwidth and the best latencies you can get in peering points to each other such that when we overlay these decoupled security services on top, the combination is an amazing architecture and network.

    Ashley: So, talk about those services. Talk about security operations, extensions, transit—all of those things that you need to take care of, orchestration—how does that work with ABHS?

    Mullaney: Yep. Yeah, so in this what we call the enterprise multi-cloud backbone, there are, you know, today probably seven or eight different services that a customer can start with. And the beautiful thing about this, again, you can use Aviatrix. We have over 300 customers right now and growing rapidly all over the world—customers all over the world. We don’t even know that, because this is low friction land and expand. A real true cloud model where they can actually start. It might be $500 a month. It might be $50 a month. It also could be $3,000 a month. They just start using it, and they might stop with one use case. “Let me try it out.” They get their credit card, it integrates in through AWS Marketplace or the other marketplaces, and all of a sudden, they just start charging. And guess what—next month, they add. Next month, they add. Next month, they add. And then they say, “Oh, I now need additional things,” right?

    So, they may start with a service we call user VPN. So, basically, we take OpenVPN and we add a lot of additional functionality to it, integrating it with SAML and other authentication means, add in some more security controls, and say, “Hey, I’ve got users, and I want them to VPN into the cloud, because I have resources in the cloud. I want them to be able to securely connect them to the cloud.”

    That might be the first use case you start with, and maybe you’re paying $1,000 a month, but from there, it’ll start growing where then you say, “Well, now I need transit networking,” right? Or, “I need egress filtering. So, guess what, I start going into the cloud.” Guess what, most of your VPCs and your resources in the cloud have to access things on the internet for build packages or et cetera, right? Because this is a very distributed, hybrid world. So, it’s not just all inside the cloud. Well, guess what? I wanna do filtering on that outbound, and I wanna do what’s called FQDN, fully qualified domain name, which, I don’t wanna do filtering based on an IP address or let them go anywhere they want. I wanna say, “You can go anywhere, yahoo.com or wherever you need to go for that build package.”

    Ashley: Mm-hmm.

    Mullaney: And that’s it. So you wanna be able to whitelist it, and you wanna be able to define it per user and per VPN. So, you wanna be able to have security policies of who can go where. So, that’s another use.

    Other use case is encryption. You know, right now, people say, “Well, you run”—you know, six months ago, when the cloud was kind of fun and games, “Hey, I’m putting workloads up there, it doesn’t really matter, it’s not my enterprise.” You know, maybe you didn’t worry about encryption. But now, you’re a retail or you’re a bank, you know, and all of a sudden, you care. So, you’re gonna wanna—

    Ashley: Yeah, if you’re gonna put in an enterprise application, you’re gonna miss encryption, security, it’s high [Cross talk].

    Mullaney: Yep, yep. You’re gonna wanna encrypt in flight, right? So, not only do we allow encryption, but we also allow high performance encryption, right, to 10 Gig, 20 Gig, 30 Gig and more, where—you know, and that’s important as people are putting PII data and other things. And also, from a security perspective, people know that—look, I’m just gonna encrypt everything. The data as well as in transit.

    And then, you know, as you talked, being able to do this across multiple clouds, right? So, I maybe can connect, I wanna be able to connect up multiple regions within one of the clouds, but then I also wanna be able to go to the other clouds as well and create one kinda common framework upon what we’re doing.

    And then I’d say another service is what we call firewall network service, and that’s another one, I can talk more specifically about that. But everybody that’s coming to the cloud—again, this isn’t fun and games any more, this is serious business. The first thing they say is what? Security and policy, I need to bring my next generation firewall policies into the cloud with me. And I need—so, if I’m a Palo Alto Networks customer, the first thing I wanna do is, I wanna take my VM series into the cloud. And when I try to do that, the construct of how AWS says you can connect your VM series firewall into AWS forces compromises in performance, scalability and visibility that are just untenable. And, with Aviatrix, we eliminate those trade-offs.

    Ashley: It’s certainly a fundamental component of where you’re gonna start to build out your infrastructure. If you can bring as much of your own network security into the cloud, all the better—that’s your strategy, yeah.

    Mullaney: Yeah. Well, you know, I think what’s important is, and I think guys like Amazon are realizing this, is when you have to deal with, when you’re dealing with the enterprise—and I mean, the enterprise. The Midwest, conservative, classic mainstream enterprise, right? You have to bring the cloud to them. You can’t make them go to the cloud, right? They’re looking at this and they’re saying, “Okay, I’m all in. I’ve burned the boat, I’m gonna get rid of my data centers, I’m all in.” But then they look and they go, “The grass ain’t as green as I thought it really was.”

    Ashley: Mm-hmm.

    Mullaney: There’s a lot of burned out spots, here. This “go build” mantra? Whoa, whoa, whoa, whoa—wait a minute. I thought I was gonna hit a couple clicks and be done. And oh, by the way, CEOs and CIOs of companies, they’re all bought in and said, “Hey, you know, we used to have hundreds of people managing this infrastructure when it was on prem, but I understand cloud. I only need tens now,” right?

    Ashley: Mm-hmm.

    Mullaney: So, the problem is, [Laughter] they go to the cloud, and again, I’m seeing this everywhere, every enterprise said, “We don’t really have enough people.” Like, we got kinda sold a bill of goods, here. Everyone kinda told us this was like click, click, click—you’re done. It ain’t that easy, right? And then you throw across, “Now, I’m gonna do it across multiple clouds—I don’t know how we’re gonna do this.”

    Ashley: Well, let me ask you, then, we’re coming up on the end of our time here, together—if you had one parting recommendation thought for those enterprises that are in that first six months window and really looking at moving to the cloud or are in that process, they wanna check out Aviatrix, they wanna maybe do a prototype or look at the reference, how they build a reference architecture on the platform—how do they get started? What’s the best way to do that?

    Mullaney: I mean, the first thing I always tell people, the best way to get started is actually just get started. The good thing about this modern world is, we don’t have to do a POC. We don’t have to—you can actually get started over the weekend, and that’s how many of our customers start. They just start playing around with our software, like on AWS Marketplace, it’s a great place to start. They just spin up a controller, they spin up a couple gateways, they—and we have quick start guides to show you how to do it in a very easy way. And people start playing with it and they go, “Oh, that’s pretty interesting.”

    And so, they start with kinda one use case, right, and a very small little bit and they effectively do their own little POC. And they say, “Okay, that’s pretty interesting.” Now, we can also do it for them, but that’s a pretty good way to start.

    And then I’d say the other thing is, what you really are gonna look for—I mean, there’s only one reason why people aren’t using Aviatrix right now is because they’ve never heard of us. As soon as they—as soon as we talk to people, they’re sold. Because they look and they go, “This is exactly”—people say, “That’s exactly what I’m looking for. I need someone to help me build out my multi-cloud, my enterprise—my, my, not someone else’s, my enterprise’s multi-cloud backbone, and all these networking and security services that go along with it. That’s what I need, and you guys are doing it for me? That’s exactly what I need.”

    Ashley: Well, great. I thank you so much for being with us. We’ve reached the end of another DevOps Chat podcast. It seems like there’s never enough time. I’d like to thank you, Steve—Steve Mullaney, CEO of Aviatrix for joining us.

    Mullaney: Great.

    Ashley: And thank you, you, to our listeners for joining us also, of course. This is Mitch Ashley with devopsy.kinsta.cloud. You’ve listened to another DevOps Chat. Thanks for joining us.

    — Mitchell Ashley

  • DevOps Chat: Mayhem Testing With ForAllSecure

    DevOps Chat: Mayhem Testing With ForAllSecure

    Secure software depends on people finding vulnerabilities and deploying fixes before they are exploited in the wild. This has lead to a world of security researchers and bug bounties directed at finding new vulnerabilities.

    As dedicated as security researchers are, there is a vast ocean of software in existence, waiting for someone to find and exploit the next security vulnerability for profit or nefarious uses. With autonomous vehicles on the horizon, is there an autonomous solution to finding and fixing software vulnerabilities?

    Enter DARPA Cyber Grand Challenge winner “Mayhem,” created by a team of researchers from Carnegie Mellon University who spun out security startup ForAllSecure. And they have a BHAG (Big Hairy Audacious Goal). “Our vision is to check the world’s software for exploitable bugs so they can be fixed before attackers use them to hack computers.” Mayhem has moved on from capture the flag contests to observing and finding vulnerabilities in DoD software and is working its way to corporate systems.

    In this episode of DevOps Chats we talk with David Brumley, For All Secure co-founder and CEO, and CMU professor about the technology behind Mayhem, how it observes software as it executes and injects changes to effect and observe new and potentially exploitable behaviors. More information about Mayhem is also available at www.forallsecure.com.

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

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by David Brumley, CEO at ForAllSecure. David is also a professor at CMU. He’s currently on leave. The topic that we’re talking about today is called Mayhem behavior testing—it ties back to David’s work at CMU. So, David, welcome to DevOps Chat.

    David Brumley: I’m happy to be here.

    Ashley: Great, we’re happy to have you on the podcast. Would you start by just introducing yourself a little more fully—your background, maybe a little bit about some of the research and how that led you to form ForAllSecure?

    Brumley: Yeah, absolutely. When I got out of undergrad, I was a computer security officer. My job was to chase intrusions on the Stanford network and try to help people fix them. And at the time, I got pretty frustrated with the idea that we were always behind attackers, that I couldn’t find vulnerabilities first or get the fixes deployed.

    I actually went back to grad school, got a Ph.D. and really made that my work since 2003 on how do we go about finding vulnerabilities before attackers and just as importantly, how do we get those fixes fielded? Because it’s not just about finding the vulnerabilities, it’s about how quickly we can get those in place.

    I’ve been working on that, I’m a tenured professor at Carnegie Mellon, and for the last three years, been working on commercializing it.

    Ashley: Excellent. Well, an entrepreneur and a professor, and it’s great to see that your research has led you to kinda bring this out to market. That’s exciting. So, tell us, what is Mayhem? What is Mayhem or behavioral testing?

    Brumley: Yeah, what Mayhem does, we call behavioral testing. So, behavioral testing is about watching an application as it executes and learning from that execution and then trying to come up with a new input that would cause the application to do something different. And you do this again and again and again, like hundreds of times per second, with the idea that if you can learn the behaviors of a program and you can start driving it to new behaviors, you’ll, one, come up with a test suite for the program, that’s important for the DevOps part and how you get things out quickly, and second, things like vulnerabilities and exploits that trigger vulnerabilities are just triggering a particular behavior. So, you can automatically generate inputs that trigger these. At one point, people were saying we were automatically generating exploits with this technology.

    Ashley: Interesting. I’m pretty sure that it’s not the same thing, but it sounds like a more thoughtful and learned approach to what we know as chaos testing from the Chaos Monkeys from Netflix, et cetera. But you’re really picking specific behaviors, building a profile of the application, and then looking for new behaviors that you can test against it?

    Brumley: That’s what we’re doing, and so, there’s really kind of two technologies people may have heard of. One is called fuzzing. So, fuzzing is about running the application again and again and again. And it uses heuristics to pick those inputs, and one of the things we built is a way to monitor that application as it runs and to inform the fuzzer on how to come up with new inputs that would get different behaviors.

    The second that we did is, we really took a page from surprisingly formal verification. So, the formal verification was trying to prove a program was safe. What we tried to do is use those same techniques to prove where a program is unsafe, and our proof creates an input that triggers the unsafe property.

    So, we use these two techniques—fuzzing, symbolic execution and a few others and a portfolio approach to try to come up with behaviors that are exploitable.

    Ashley: Interesting. Do you do this in a production environment, in a test environment, in both? How do you approach this?

    Brumley: For a product, we always do it in testing. We think it’s important to have these techniques out there in testing so that you can find them before attackers. We have done some simulations in production. One of the things we participated in was, DARPA had a big autonomous Cyber Grand Challenge. So, we fielded it there, but we think the market would be in the testing environment.

    Ashley: Mm-hmm. It would definitely make sense—makes more sense there. Say a little bit more about fuzzing and how that exactly works. Is it the software that’s doing the variations, or are you introducing variations to that from what you learn?

    Brumley: We’re introducing the variations, so the idea is, an exploit for a program is just an input.

    Ashley: Mm-hmm.

    Brumley: And, you know, test cases are just inputs. So, you run the program on an input and you watch how it executes. Like, you see it executes this system call, that system call. It covers these branches. And you use that to learn a new behavior or guess a new input. And then the fuzzer will use a heuristic to pick that new input, with the idea it should trigger a new behavior.

    Ashley: Step back just for a moment, you’ve talked a little bit about Mayhem and the technology behind it. You’ve stepped out of CMU to set up this company, ForAllSecure. How did you get that started? Are you working with a particular private sector, government sector? Sounds like something that might be interesting to the government side of things, too.

    Brumley: Yeah, we got started by really participating in this, as I said, DARPA project. So, they have Grand Challenges every so often. One was the self-driving car contest. This was, like, a self-driving car for a computer security contest. We won that and that gave us our first $2 million, so that was, like, seed funding from the government.

    Ashley: Excellent! Wow, that’s awesome.

    Brumley: Yeah. And so, we’ve been working to bring it into the government so it’s used in pretty much every service and in the IC right now to try to look for vulnerabilities in weapons platforms as well as in software the government might be using to try to fix it before attackers can break into it.

    Ashley: Mm-hmm.

    Brumley: About, oh, six months ago, we then went and raised money from NEA to help transition this from just a government tool to something in the enterprise section as well.

    Ashley: Mm-hmm, so you’re also beginning to work with the private sector, then?

    Brumley: Yeah, we’re working—starting to work with the private sector. It’s really kind of an interesting difference between the two.

    Ashley: Oh, there’s a lot of difference. [Laughter] Yes. Highlight what you see the difference as. I have some experience with both, also.

    Brumley: Well, I think that the private sector, it’s harder for them to put a value on finding a vulnerability and fixing it quickly while, in the DoD, it’s really easy. That mission didn’t succeed, which is a big deal.

    Ashley: Mm-hmm.

    Brumley: So, I think that’s one difference. I think the second difference as we see going to market is, in the DoD, they care a lot about checking legacy systems, because they still have to maintain them. And if you think about it, lots of vehicles, airplanes, trains—things like that. And in an enterprise, they care about things that were developed in the last two or three years only. And so, they’re just kind of products in different parts of the life cycle.

    Ashley: Yeah, interesting. You also have many layers of different parties involved in the government sector—contractors, subcontractors, primes, et cetera. So, you’re dealing with lots of layers of companies that are working as part of the government team.

    Brumley: Yeah, working with the government is definitely, it’s a chore until you get into the groove and you realize a lot of the, what you perceive are barriers, are actually just regulations put up to protect taxpayers from complete abuse. So, it takes a long time, it takes about nine months to get anything really going from start to scratch in the government. But once you kind of get that cycle, it goes forward pretty quick.

    Ashley: Yeah, that was my experience, too. It’s an investment, but once you get going, it’s great.

    Brumley: Yeah.

    Ashley: So, talk a little bit about where you are in the product life cycle? Do you have product in the market? Is Mayhem publicly available? Are you alpha, beta? Give us an idea of that.

    Brumley: Yeah. So, within the DoD space, we have Mayhem that you can buy starting in July this year—so, pretty close. So, we have a number of beta installs, people are happy, and we’re gonna be switching over to general availability pretty quick.

    Ashley: Mm-hmm.

    Brumley: In the commercial market, we’re taking it a little bit slower, because some of these differences I’ve discussed. They use different application stacks, they’re often concerned with much newer software than old software, they often use different languages.

    And so, that, we’re looking for design partners. People who wanna take Mayhem, what’s working in the DoD, what’s working in places like aerospace, and see if it works for them and figure out what we need to do to make it a really good fit.

    Ashley: Mm-hmm. So, you’re spending a lot of time with customers and potential customers really learning what the commercial sector is looking for or can benefit from.

    Brumley: We’re learning what they’re looking for. We’re also trying to understand, like you said, when you go to market, it’s kind of interesting in the DoD who the buyer and who the user are and trying to understand that in the commercial space. Like, it’s kind of fascinating to me in DevSecOps, it’s almost always the security team that’s the buyer but it’s the development team that’s the user.

    Ashley: Mm-hmm. Yeah, exactly. And that’s an interesting dynamic there, it’s, you know, the DevSecOps conversation, one that we helped facilitate bringing together through a lot of the activities at devopsy.kinsta.cloud.

    I’d love to hear a little bit about, so you said you’re not commercially available yet in the commercial or private sector, but you are entertaining companies to work with? Is that true?

    Brumley: That is. So, we’ve worked with a large aerospace vendor that makes airplanes. Can’t say much about that. We’ve been able to really help them find some flaws in some software that they use as well as build up test suites for them so that when the developer does push a fix, that can be more rigorously tested, working with a Fortune 100 company, and then some IT infrastructure people.

    Ashley: Mm-hmm. I could see, for example, data center providers being another place that it’s gonna really benefit from.

    Brumley: Oh, absolutely. Anyone who has something that’s extremely high value like a web server that, if it gets compromised, your entire business is at stake.

    Ashley: I’d love to hear your thoughts about how you fit this into the DevOps or the DevSecOps pattern or cycle. How does this happen? Where do you build it into?

    Brumley: Yeah, so, from what we can see in research right now in a lot of DevSecOps, it’s really kind of a primitive stage where people want to run a scan before they field software. To me, this is insane. I don’t know any attacker who runs a commercial product and a scan and then says, you know, “Here’s the new zero day” or, “Oh, better not go after that, the scan was okay.”

    Instead, what they do is, they’re always trying to break into that software. They’re always trying to learn from what hasn’t succeeded and come up with attacks and succeed. So, Mayhem is like that. So, the idea is, it’s more of asynchronous testing. You’re gonna push as part of your DevOps cycle through, you know, things like making sure you’re not using old versions of libraries. But then, you’re gonna launch a process that, for the lifetime of that product, tries to hack it in the background.

    I think that’s really kind of the conceptual shift that we think needs to be made is to stop thinking of security as a scan you do once, and actually expect it to work, to something that’s always going on in the background.

    Ashley: I’m gonna shift just like we do with testing, we’ve moved into continuous improvement, continuous testing do the same for DevSecOps where this is running maybe on multiple versions of the product and test environment all the time.

    Brumley: Absolutely, as well as all the dependencies. If you look at Google—so, Google runs fuzzing, one of the technologies that I talked about earlier, on Google Chrome. And they found 12,000 new vulnerabilities in the last three years, and each one was accompanied by a test case, so zero false positives. And one of the things this has allowed them to do is get ahead of attackers, because they’re finding those flaws so quickly with their automated, always on infrastructure that I’ve talked to people who try to participate in bug bounties. And by the time they report it, it’s already fixed.

    Ashley: Mm-hmm. I mean, aren’t the bad guys also doing fuzzing themselves, so you’re at a disadvantage if you’re not?

    Brumley: Absolutely. Every top notch hacker I know uses fuzzing extensively as one of their techniques. I mean, this is assuming you kind of do the base, like, did the person forget to set a password? Always check for that first, right? But after that, after that base level, you’re gonna do fuzzing, especially after high value targets.

    Ashley: Talk a little bit about where you see things going next. You’re kinda testing with the commercial market, you’re heavily engaged with the federal market. What happens next in terms of the product roadmap?

    Brumley: Well, the next question that we have in terms of the product roadmap is, how do we close that life cycle from finding a vulnerability to having a fix fielded. So, some app site companies, what they wanna do is always add on that next language support so that they can support a larger and larger set of languages.

    Ashley: Mm-hmm.

    Brumley: For us, we’re really looking at C, C++, Java, Python—the core languages used by infrastructure Go and Rust. And we want to be able to do deep analysis in these languages and then be able to help automatically suggest fixes and actually, for DARPA, we proved that the computers could automatically patch. So, it could automatically patch binary programs, and it could assess whether that patch would have any business impact, and field it, if not. And so, that’s really what we’re trying to do, and we’re going language by language as opposed to trying to cover all the languages at once.

    Ashley: Interesting. What’s your top pick in terms of languages you’re looking at first?

    Brumley: So, the top one that we started with is C and C++. And that’s been a bit surprising to people, because it’s an older language. I can tell you why we picked it.

    Ashley: Okay.

    Brumley: The reason that we picked it is, regardless of what language you choose, you’re gonna be calling out to C and C++ code. In Java, you have JNI calls. In Python, you have, you know, as part of TensorFlow, if you’re doing machine language, everyone goes to C/C++ or a compiled language when they want performance.

    And so, if you wanna analyze these applications completely, even if it’s Java or Python, you have to be able to analyze those components as well. So, we’re kind of working our way up.

    Ashley: Yeah, I was gonna say, it sounds like you’re working way up the stack into the scripting languages.

    Brumley: Absolutely. The second reason is, when you look at really critical infrastructure out there, it’s still primarily developed in C and C++. So, you know, I, like many people, have probably put up a Flask or Python website, it’s really quick to do, it’s online—you definitely don’t want it hacked. But when you start talking about a car or an airplane or a power plant—these are also on C/C++. And so, just from a safety point of view, you have to cover those.

    Ashley: Interesting. Do you foresee, looking kinda down the road—I’m not asking you to announce anything officially, but do you see that you might be working with either the patch management companies, the vulnerability scanning companies as a complement to them? Would this be something that potentially displaces them? How do you see that future unfolding?

    Brumley: Yeah, I think people who detect known vulnerabilities are complementary to us. So, the way I think of it is, there’s really two types of security companies out there. There are those who find new vulnerabilities, and there’s those who check for old vulnerabilities.

    So, you have, for example, Tenable, which is a network scanner that goes and looks for known vulnerabilities. You have software component analysis, which looks for known vulnerable versions of libraries and other things, right? So, those are pattern matchers in some sense.

    We’re not one of those companies. That’s someone that you would partner with. What we’re doing is, we’re finding new vulnerabilities. And so, this is more like a typical SaaS or DaaS type solution.

    The other sort of people that we’re looking to partner with are the patch management. So, one of the cool things that we can do is, when we find a vulnerability, we automatically are building a test suite as well, just part of the process. So, when there’s a patch we can replay it, and we can tell you things like, “Hey, have any of the previously passing test cases stopped working? Has performance dropped?” as well as, of course, where the bug’s fixed.

    Ashley: I definitely can see the partnership alignment there. If you had to paint a future of what success looks like for, both for you and ForAllSecure, what would that be?

    Brumley: I think we’re really motivated by this vision that we wanna automatically protect and check the world’s software. And so, we wanna close that cycle and make it autonomous. And we’re making, actually, pretty careful design decisions as we do that.

    So, I think a lot of people talk about, you know, big startups, billion dollar businesses—that’s not really our goal. Our goal is, we want to make it so the time from when we detect a vulnerability to there’s a patch that’s tested and ready to field is seconds. That, to us, is success.

    Ashley: The billions will come later, right? [Laughter] That’s if you’re passionate about that core problem.

    Brumley: I think so. Because this problem, we were talking about DevSecOps. Like, DevSecOps, the problems facing DevSecOps face every system administrator if we go back in the world. In Silicon Valley, we think of SREs and DevSecOps, but there’s this huge nation full of just system administrators who wanna know, “If I update it, is it gonna break? Do I need to update it?” And solving those problems for those people is what’s important for us.

    Ashley: Do you have any demonstrations coming up, either online or you’re gonna be at some conferences? Is there a way for folks to see this yet?

    Brumley: Yeah, so, we’re gonna be at Black Hat and we’re happy to demo it there. We’ll have a booth and a room. We also have a number of online videos. If you want to see the fully autonomous, in its splendor system, there’s definitely videos of the DARPA Cyber Grand Challenge as well.

    Ashley: Going back to the original challenge.

    Brumley: That was the original vision. I mean, when I talk to people about this technology, what really lights up their eyes is not finding security bugs, it’s that there’s not enough people to do the work. And by being autonomous and focusing on that value proposition, you’re really focusing on the pain point, which is, how do I do things that there’s just not enough highly skilled people to do.

    Ashley: Well, I applaud you for what you’re doing. You know, there’s yet another scanner, yet another anti-virus something. It’s great to see folks that are really doing some innovation, kinda thinking about the problem differently and really trying to solve it in a more systemic way, and that’s one of the things that I see that you’re doing. It isn’t just, we’re trying to test for these kind of behaviors, but it’s also in this ecosystem of how patches happen and things can happen dynamically, automatically.

    Brumley: Absolutely. I mean, we’ve had a number of customers who want us to support 10 different languages, but there’s no product in the world that can add 10 languages to support and also be really good at each one of them. For us, our main value proposition is, for everything we do, can we have zero false positives, can we make sure it’s actionable before we report it at all?

    Ashley: Awesome! Well, we’re—[Laughter] the time always flies by on these podcasts. Is there any last parting thoughts that you wanna share with us before we wrap up?

    Brumley: Well, thank you for having me and, as I said, we’d love to talk to you at Black Hat 2019.

    Ashley: Great, great. Well, I’ll be there as well, so we’ll get to meet up there. We’d love to have you on a future podcast as things develop and hear more about how things are moving along for you and ForAllSecure.

    Brumley: Thank you very much. Have a great day.

    Ashley: Well, another DevOps Chat podcast has flown by, as they always do. I’d like to thank David Brumley, CEO, at ForAllSecure for joining us today. Thank you, David.

    Brumley: Thank you.

    Ashley: And I’d like to thank you—you, our listeners—for joining us, of course. This is Mitch Ashley with devopsy.kinsta.cloud. You’ve listened to another DevOps Chat. Thank you for joining us today.

    — Mitchell Ashley

  • DevOps and Security: Be Ready to Shield Your Application

    DevOps and Security: Be Ready to Shield Your Application

    All of us have heard of continuous improvement/continuous delivery (CI/CD). There are many benefits to implementing CI/CD, as it helps seamless integration from end to end for development and deployment processes. CI/CD helps in rapid improvement, shorter release cycles and more, but it also helps with the challenge of handling security effectively at DevOps speed.

    Tools for Securing DevOps

    There are thousands of DevOps security tools available in the market that help us at HCL Technologies secure our software development at various stages of the CI/CD pipeline. There are new vulnerabilities rolling out daily, and so we must be alert and keep our applications safe and future-ready.

    These are the DevOps security tools we use (most tools are open source with an option of enterprise edition):

    1. OWASP SonarQube
    2. OWASP ZAP
    3. OWASP Dependency-Check
    4. OWASP Glue
    5. Anchore
    6. Clair-CoreOS
    7. FOSSA
    8. Cyberark Conjur

    Our DevOps Toolchain Diagram

    Securing CI/CD

    Let’s consider a job in which we check out the code from GitLab/GitHub with auto-commit (a Jenkins job will be triggered as soon as the developer makes any changes in the code). You can refer to this link for  more information about Jenkins GitLab automation.

    Now, in Jenkins, we can run a security test and present it in the form of reports and dashboard to meet our needs. To get started, we can use OWASP SonarQube for static analysis. OWASP SonarQube includes found bugs, PMD and several security plugins bundled out of the box. Next, for dynamic analysis and penetration testing, we can use OWASP ZAP, which presents reports in XML/HTML format that can be used to create Jira issues.

    In the above scenario, we can also use ZAP through custom tools integration. In our case, we have installed ZAP on our local machine. We can also use OWASP ZAP installed in a remote machine.

    Steps for Remote OWASP ZAP Connection

    Windows Command: C:Program FilesOWASPZed Attack Proxy>zap.bat -config api.disablekey=true -config api.addrs.addr.name=.* -config api.addrs.addr.regex=true

    Linux Command: Zed Attack Proxy>zap.sh -config api.disablekey=true -config api.addrs.addr.name=.* -config api.addrs.addr.regex=true

    OWASP Configuration in Jenkins

    The reports will be generated in .xml and .html format. Now, with the reports generated by ZAP, we developed a Java program to create Jira issues for every vulnerability detected and assign it to the concerned person.

    Next, we have OWASP Dependency-Check analysis on our project. To configure for Jenkins, follow these steps:

    First, we need the OWASP dependency-check plug-in (which I have already installed). This process may take several minutes, as it downloads from NVD server.

    Here are the next steps:

    Alternatively, we can use the OWASP Glue plug-in, which runs OWASP ZAP, OWASP Dependency-Check and other security automated tests.

    We have also used FOSSA in our projects for license audits and vulnerability management for OS dependencies. We can use FOSSA as on-premises, but it is available only for use on Ubuntu machines.

    At HCL, we are currently working on container security with Anchore and Clair-CoreOS. We have also integrated identity access management (IAM) to our CI/CD jobs. As for IAM, we are working on CyberArk Conjur and HashiCorp Vault.

    CyberArk Conjur

    The Conjur Jenkins credentials plug-in:

    HashiCorp Vault

    Conclusion

    I have worked on various tools for security with DevOps. Below is a quick comparison of the tools that can be used for application security.

    Now that you have an idea of which tools to use, embrace security instead of worrying about it. DevSecOps can help improve and increase the outcome and effectiveness of any organization.

    — Debarghya Pandit

  • 5 Practical Ways to Deliver Secure Software That Could Actually Work

    5 Practical Ways to Deliver Secure Software That Could Actually Work

    Almost every aspect of modern life is dependent on technology. As technology becomes even more advanced and pervasive, so, too, does the need for secure software.

    Today, even the tiniest breach at an organization could result in major loss of sensitive data. Therefore, it is crucial for both the reputation and proper functioning of the organization to have steady security measures in place.

    Below are five practical ways organizations can deliver secure software by prioritizing safety and maintaining a sustainable “security culture.”

    Organizations Build and Foster a Healthy Security Culture

    A security culture, just like any other culture, thrives when it is used actively. Effective security culture is a one-time investment that can reap major benefits. However, it requires effort from the organization.

    A viable security culture is based on four key features:

    • The security culture is disruptive in nature and brings about immediate change.
    • Security practices employed by the organization are engaging for everyone, not just the security department.
    • A proper reward system is in place for the people who actively take part in security regimens.
    • Investments made into the security culture are returned in one form or another.

    Ensuring that a proper security culture is in place takes care of the biggest problem in the development of software—humans.

    The establishment of a robust security culture helps humans in an organization more than it does the computers. It provides a proper framework through which employees at an organization can act to maximize security.

    Some ways to develop the security culture at an organization include:

    • Instill the belief into the employees that security-related issues are not just the headache of the security department; rather, the whole organization should work together to resolve them.
    • Focus on spreading awareness throughout the organization by providing employees the basic security knowledge.
    • Provide opportunities for advancements in security to team members who are more excited.

    Despite having a strong security culture in place, however, breaches may happen. A proper security culture can help the organization recover more swiftly.

    Acquire a Secure Developmental Life Cycle

    A secure developmental life cycle (SDL) provides a firm foundation to monitor the security practices in an organization.

    An SDL performs essential functions such as threat modeling, security analysis and requirements, and carries out security testing. The organization that acquires the SDL agrees to an in-depth study of their security on all the software and system releases.

    Microsoft, for example, offers a free SDL that consists of security practices that could help organizations regardless of their size or platform. This is especially useful to those organizations that have just started.

    Other benefits of having an SDL are:

    • Detects bugs in the software earlier in the development cycle, which is cost-effective.
    • Safeguards the interests of the stakeholders and investors, as it makes the business secure.

    Overall, an SDL minimizes the risks that an organization faces and helps in advancing it.

    Integrate Security Tests Into the Developmental Phase

    Organizations should introduce security tests in the developmental period; that is, when the code is being written or when the programmers check in on their codes.

    The introduction of security tests allows developers to correct their mistakes at an early stage, which effectively reduces the cost of resolving the problem. Developers actively get feedback, enabling them to design software with a smaller number of flaws.

    Moreover, tests conducted at the developmental stage save time and keep the disruption caused by the whole developmental process to a minimum.

    Have a Deep Understanding of What’s in Your Software

    Developers should work with security experts to understand the software and the applications installed.

    Knowing what constitutes applications—especially open source applications—is pivotal in patching any discrepancies that may arise.

    Along with a firm grasp on the software, developers must be aware of application security.

    Application security, or AppSec, teaches advanced lessons to the testers and developers within an organization and aids them in building secure products and services.

    Encourage Mentorship

    No security system is complete without a set of security experts who can train developers in specific methods and procedures. These mentors can be responsible for conducting security tests and furthering the advancement of secure software in an organization.

    Mentors can also provide a learning experience to the staff members and go the extra mile to make sure security is accessible for everyone.

    Conclusion

    Organizations need to maintain a standardized way of delivering software. The threats we face today, if  not dealt with, can have dire consequences.

    However, the solution starts at the very beginning and needs to be integrated into everything related to software, from education to the way employees interact with each other in the workplace. Only then can we rest easy knowing our software and data are protected.

    — Zehra Ali

  • API Security: A Key Part of the Bigger Plan

    API Security: A Key Part of the Bigger Plan

    Standing as the “fuel” powering the customer-driven platform revolution, application programming interfaces (APIs) are the new “it thing” amongst operating systems.

    APIs are responsible for how apps communicate with each other and have become key components in many digital transformation strategies. Serving as a set of tools for building software application, they have empowered many businesses to increase their value. However, as they have risen in popularity, concerns have risen over the adequacy of measures being put in place to ensure security for businesses using APIs.

    The Open Web Application Security Project (OWASP) is a global non-profit organization committed to improving application security and makes it a primary mission to ensure software security is a priority for all. OWASP regularly issues a top 10 standard set of rules that are applied to security policies across various platforms. The most recent list presents notable changes that reflect the increase in dependency on APIs, with a focus on how they can both help and hinder security efforts.

    Why Should Businesses Care About API Security?

    Every application needs APIs. It is difficult to find an organization today that doesn’t have its own app or uses an app to complete critical business activities. They contain programming standards, instructions and protocols that allow applications to communicate with one another. Essentially, APIs serve as a bridge that ensures proper and consistent communication between two systems.

    API security is a critical part of API development because millions of applications communicate back and forth daily. With the cyberthreat landscape constantly evolving and the cloud API market predicted to experience a 20 percent CAGR by 2022, it is easy to understand why it is so imperative that companies develop and continually implement thorough API security measures.

    Most APIs do have some governance from management tools, which can offer a range of control features aimed at making APIs more reliable, secure and controllable. However, security should also be top of demand in the design phase of an API and formulating controls that can be implemented across the organization.

    Arming Your Organization with the Right Security Tools

    Systems that host public APIs feel the impact of heavy traffic on a daily. Some of that influx is, unfortunately, not authentic. To avoid overburdening the legitimate users and protect their system, companies need to evaluate behavior to flag potential problematic traffic.

    API security works in the same manner by using rules and algorithms that evaluate client sessions. APIs ask simple questions that gauge how clients are behaving, what they are doing and whether there are unusual error rates or repetitive behavior in short time periods.

    Machine learning is often used to answer these questions and to identify and deter malicious API client practices. Standard web approaches typically don’t function properly with APIs, simply because hackers work to continuously be ahead of the game. They know that standard DoS attacks don’t work, so they distribute hacking attempts across bots that hide alongside legitimate traffic to sneak them through the system, undetected.

    To find these bad eggs and stay on top of the large amount of them, it’s necessary to set up a machine learning-based system that have a deep understanding of API traffic, with a thorough understanding of API keys, access tokens and what the typical request context is on any payload.

    How Can You Prevent Attacks Right Now?

    There are several actions you can take immediately to protect your system from potentially damaging attacks. Begin by using HTTPS, if you’re not already, to ensure proper authentication and authorization. Also, adjust your software development life cycle (SDLC) to include rigorous API security testing and validation with a primary focus on input validation.

    Also important: Make sure all network servers are running on regularly patched OS versions that are stable and include carefully configured security groups. Implementing role-based access control and VPC isolation across environments also can help improve responses to prevent attacks.

    Finally, having a pre-documented response policy for security incidents will help your company establish a secure development environment that is properly maintained at all times.

    Routine API audits and testing can help your organization continually improve the API development and ensure your business is protected against DDoS attacks and malicious bots, while still letting legitimate API traffic through. These techniques will help you validate API requests and sort through which are legitimate and which are not, to completely eliminate or reduce API attacks.

    — Eltjo Hofstee

  • Software Security is an Engineering Problem

    Software Security is an Engineering Problem

    We live in a world where those who sell products are generally held accountable for defects. Automobile manufacturers, pharmaceutical companies and toy makers are among the businesses that have been handed fines and tarnished reputations for distributing items that were later deemed ineffective or dangerous.

    One notable exception to this “consumer first” ethos is the traditional shrink-wrapped software world, where responsibility for product problems is hazy. The vendors that develop and sell software and the customers who purchase and install that software are in a constant battle to shift security liability. The vendors strive as best they can to reduce and remove product vulnerabilities and offer secure configurations while customers deploy, configure and operate the software in very different environments, with very different configurations, which can produce very different security outcomes. Because no customer can (or should) assume receipt of 100 percent vulnerability-free software, they must always take on the primary burden of protecting the environments where that software lives to offset the risks—which typically falls to the customer’s IT and security teams.

    Although there are excellent arguments for both sides, the current situation leaves both parties wanting—and needing—a higher level of assurance in both the development and runtime settings.

    Software Delivery Has Changed (Along with Security Responsibility)

    The good news for software customers is that software delivery is rapidly moving away from an on-premises install approach to a cloud-based subscription model where applications are delivered via the internet. Upfront costs for hardware and software, as well as the expense of personnel to install and manage that software, are replaced with business-friendly, predictable, subscription-based operational costs. Software is easy to launch, upgrades are uncomplicated and scaling to meet changing business needs is simple.

    Customer expectations are high for software-as-a-service (SaaS) solutions. Purchasers demand an elevated level of innovation and want new features more often. They assume built-in support of global information security and privacy regulations such as the European Union’s General Data Protection Regulation (GDPR) and various U.S. regulations, including the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and PCI Digital Security Standard (PCI DSS). SaaS customers also expect the vendor to take on larger responsibility for any potential software vulnerabilities that might negatively impact the customer’s data and operation.

    The new reality is that deploying software in the cloud significantly changes the paradigm of how software security should be treated at the vendor level. This means companies now have to think critically about security as an engineering problem as the balance of the liability burden shifts focus to the cloud provider’s engineering practices to ensure constant delivery of a secure and trusted cloud service, rather than just secure software.

    Now is the Time to Rethink Software Security

    Cloud-based application delivery brings together under a single company umbrella the ones that make the software and the ones who run the software. Informing software development of runtime behavior and vice versa can have significant advantages in enhancing the overall security of the software by offering a closed-loop system. In such a perspective, the rapid pace of software releases work in favor of enhancing security.

    Shifting security to an all-around engineering responsibility requires the elimination of traditional work silos. Geared-for-speed developers must receive precise information early, allowing them to correct security problems during the initial coding process. DevOps team members also must assume security responsibilities. And security engineers who understand the attacker mindset, security risks and compliance requirements must provide guidance at all points in the software development process.

    Change is never easy in any organization, so transforming disconnected teams into one in which security is an across-the-board responsibility is difficult. Managers must be careful to not alienate team members who already have full plates. And although we’re starting to see some shifts in the educational model to one in which professionals are taught early on how to seamlessly integrate coding and security, we have a long way to go.

    While we wait, the most effective way to overcome the chronic problem of heavily siloed teams is to provide the entire software engineering team with a means to quickly identify issues between software development, its deployment and runtime across all the components. These tools must give users the ability to:

    • Scan and provide real-time analysis that integrates source code analysis and its runtime behavior. After all, they are two sides of the same coin;
    • Obtain accurate and full visibility into the security impact of changes from build-to-build;
    • Ease the audit analysis process;
    • Reduce the number of false positives; and
    • Allow developers, DevOps, and Security to collaborate to enhance the security of the environment.

    The goal? An ability to fix software mistakes, weaknesses and vulnerabilities at the beginning of the development process instead of post-deployment, when liability, revenue and reputational risks are the greatest.

    Consolidating today’s siloed security practices into an integrated engineering effort is the only way to ensure the appropriate level of security at the appropriate time in today’s fast-moving cloud-based software industry. This sort of shift in thinking and processes will give customers less security worries and better products. Development teams will become more effective and efficient. DevOps will have real-time visibility into how each release impacts the infrastructure. And Security will know how each release impacts both security and compliance requirements. SaaS companies will reap the financial benefits that come with strengthened industry reputations for rapid innovation capabilities and high levels of software security. It’s a win-win-win for everyone.

    About the Authors

     Manish Gupta is founder and CEO of ShiftLeft Inc. He is a 20-year veteran of the security industry and has led product development, management and strategy at FireEye, Cisco Systems, Intel, McAfee and Redback Networks.

     

     

    Craig Rosen is vice president and CISO at AppDynamics. He has held leadership roles for more than two decades in the security industry, including at FireEye, Pacific Gas & Electric, TDI and CGI.