devopsy.kinsta.cloud

Tag: devsecops

  • JFrog, Vdoo Securing SecOps

    JFrog, Vdoo Securing SecOps

    Earlier this summer, JFrog acquired Vdoo to deliver end-to-end continuous security from development to device—is this what DevSecOps looks like? JFrog CEO Shlomi Ben Hami and Natenel Davidi, CEO of Vdoo, speak with Alan Shimel about what the acquisition means and how this will change the way organizations approach DevSecOps. The video is below, followed by a transcript.

    Announcer: This is Digital Anarchist.

    Alan Shimel: Hey, everyone. Thanks for joining us here on a special segment of Tech Strong TV. I am really happy to be joined by two gentlemen, one coming to us all the way from Israel, Netanel Davidi from a company called Vdoo, and for those who don’t know, Vdoo is a Hebrew word meaning we understand. What?

    Netanel Davidi: Making sure.

    Shimel: Making sure. And then my second guest needs no introduction to our audience, it’s my friend, Shlomi Ben Hami. Shlomi, of course, is CEO and one of the Co-founders of JFrog, and he’s coming to us, I’m gonna assume, from the swamp in Silicon Valley today?

    Shlomi Ben Haim: You are correct. Great to see you again.

    Shimel: Shlomi, welcome. Good to see you, my friend. It looks like you’ve been in the sun a little—a little tanned. I’m glad to see they’re letting you out a little bit.

    But guys, we’ve got some big news to break today. Nati, you’re a new person—okay, I was gonna say, who wants to break the big news, but up to you, Shlomi.

    Ben Haim: Yes, I think I’ll go first and obviously, Nati—

    Davidi: Okay.

    Ben Haim: – will have far more information to share with all of you. Nati Davidi and the Vdoo team are joining JFrog. We are announcing the acquisition of this wonderful company that will complete our SecOps solution, not just for the DevOps and SecOps pipeline, but all the way to the edge, whatever the edge is, whether it’s a device, a data center, or any other destination.

    And Alan, you’ve heard me so many times saying that DevOps without security is half-baked and crippled, so the solution that we are now building together will take us another leap forward toward our vision of liquid software, and becoming the company behind all the software updates in the world. So ,we are obviously very, very excited to join Nati and the team to the JFrog family.

    Shimel: Congratulations. Thank you, Shlomi. Nati, as we say here in Boca Raton, mazel tov to you and the whole Vdoo team. So, tell our audience—and our audience, Nati, you should know is a very cyber savvy audince. Let’s hear a little bit about the Vdoo story. We know JFrog, but give us a little of the Vdoo story.

    Davidi: Sure. So, it all started almost four years ago when we were an initial team of people coming from endpoint security and a space of software vulnerability expert mitigation. Our previous company, we dealt with it as part of Palo Alto Network, they acquired my previous company, Cyvera, and another part of the group coming from embedded security and the space of reverse engineering and vulnerability research. And we joined together to cope with what we believed three or four years ago to be the biggest problem today in the security space, which is the connected device and embedded systems.

    We call it that way more technically because, clearly, there are very many other good companies out there doing more network security for IoT. We claimed and are still claiming that you need to take care of the source of the problem, which are the manufacturers and the creators of such devices, of such embedded systems, and for that, we established Vdoo.

    So, we did initially, we focused on that, and very quickly, we came up with a platform for product security, focused specifically on embedded systems and IoT, that allows developers and product security stakeholders to analyze automatically any kind of connected device. But when I say analyze, it’s not from the network point of view, but rather analyze the software stack in order to identify any security issue, any of the main buckets like third party issues, issues with your own code, the first party proprietary cloud that you are writing, issues with whatever in between, productization issues, configuration issues, hardening issues, architectural issues, things around cryptography, around how you keep your keys, how you configure things.

    So, we said we want to be the first player that allows everything, truly everything. Look at all of the aspects of security clearly, of course, supply chains, threats within it, and say to the manufacturers of devices, “Take this, and this will be your product security officer in a box, and a product security team in a box.” And it worked well.

    Now, the interesting thing is that, in order to do it, we had only one applicable approach—analyzing binaries. Why? Because in the embedded space, everything is around binaries. You have images of real time operating systems, third party compiled binaries and files and packages that you cannot really see into them what’s going on. You get them in the form of drivers from Qualcomm or AUTOSAR, whatever known library, and the manufacturers need to look into those, and they don’t have the source code. They have to be able to analyze them.

    So, we focused on binaries, and with that, again, we came with the platform and very quickly without even us knowing, our customers started to use us for purposes other than embedded security analysis. They started to analyze web applications, mobile applications, containers. Because when dealing with embedded, which is considered to be the most complicated and advanced or difficult things to analyze automatically, doing the rest is usually more about gaining more data but not developing more technology.

    So, we adapted, and we allowed our customers to analyze the applications that are talking with the devices and the web services that are talking with the devices. And we added more and more capabilities, and by then, we said, “Wait, why focus in on embedded systems if, through the binary analysis approach, we can serve the entire industry, we can provide security for whatever software artifact is out there.”

    And the next thought was, we just need to find the right partner who will deal with binaries. [Laughter] And the answer was, there is one such pioneer, which is known to everyone, which is JFrog.

    So, I asked Shlomi kindly to meet, to consider collaboration, so we can enjoy the many thousands of customers and huge community of JFrog and tell them, “No, use us to analyze your repository on top of Xray. Xray brings great capabilities, we enhance it with more capabilities for zero day analysis, configuration analysis. So, let’s do it together.”

    And that’s how our discussion started and today, we see where it is going and we are very, very excited about it.

    Shimel: What a great story. So, did you get the space two floors from them in order to meet, or were you already there? [Laughter] I’m kidding, I’m kidding.

    Seriously, I mean, my background is—look, I cofounded a company that really pioneered what we used call NAC, right, Network Access Control, and we did it for the U.S. government, for the DoD, right? So, this was not embedded systems, these were every endpoint network device coming on via, you know, 2.1x, we would test configuration vulnerability, et cetera. I know what a tough job that is.

    Once you go into the world of embedded systems, though, it’s like—anything goes, right? As you said, you’ve got Qualcomm drivers, there so much black box stuff. Knowing what’s secure and not is—I can’t even imagine, you know, how you do that. But now, once you’re taking binaries and artifacts, you’re right, there is only one company for you to go to, you know, it’s this man’s company. So, what a great match.

    Shlomi, he mentioned, Nati mentioned Xray. Xray’s a good product. But it’s a very specific product, right? If you’re downloading an artifact from the repository, it’s gonna check that as you’re doing it. This, of course, opens a whole different world of checking downloads and components and so forth. What’s the plan?

    Ben Haim: So, I’ll first start by saying, Alan, that I’m sitting here thinking that this would be probably the only interview in the world that you will have two CEOs that are so excited about binaries. [Laughter]

    Shimel: Yeah. [Laughter]

    Ben Haim: I’m enjoying it.

    Shimel: I think you’re right—you’re right, you win that.

    Ben Haim: So, listen—when we started, we built Artifactory to be the universal repository for all types of artifacts. And very fast, we identified the software package, the binary, as the first level citizen in your DevOps pipeline. There is no other asset that is more important. And why? Not because JFrog thinks so, but because of the fact that this is what you bring from outside, this is what you build inside the organization. This is what you test, this is what you promote, this is what you deploy, and this is the incremental update that you want to see at the end of the day on the edge.

    Now, with this in mind and the liquid software vision to be the company that changed the way software is being updated in the world, it was clear to us that SecOps cannot end on securing your repository. That’s great, that’s a great value. Xray can give you the composition analysis, the dependencies graph, secure your binaries—that’s great.

    But what happens when the Product Manager needs to take a binary? This is where the trust is broken. And we can—you know, every SecOps company, and you met all of them and you know all of them, Alan—every SecOps company will tell you, “We want to kind of build the bridge between developers and security guys.” It will not happen because you don’t use the same currency.

    And when it comes to binaries, both Vdoo and JFrog speak the same language, identify the same pains, and take it very seriously, not just on the development side or then on the testing side or then for the Product Manager side—all the way, all the way to the update, all the way to the deployment to production. So, obviously, we were very excited about what Vdoo had to offer, and it was again, just like everything else in JFrog, a binary question—are we competing or buying?

    And I’m very happy and very pleased to get to this moment now, speaking with you, knowing that the Vdoo guys are joining JFrog. Now, why this is so important from a culture point of view—and Alan, you know me well. You know how culture and the synergy is also about the people. We are bringing approximately 100 people that thinks and program and build their products like hackers. They know how the threat looks like. We are joining them through our hundreds of people that think like developers. What are the chances that this will not bring a better solution, a better blend to the market?

    Shimel: Sure.

    Ben Haim: And with that, I’m taking the next leap forward to fulfill the liquid software vision.

    Shimel: Agreed, agreed. And you know, frankly, it couldn’t come at a better time, right? Because wherever you are in the world today, and look, I’ve been in security 25 years—never has security gotten the attention, real attention, everyone always gave lip service, but real attention now. Whether it’s the supply chain or the ransomware or the whatever the attack du jour is, we are recognizing that cyber, cyber security represents probably one of the most serious threats to our continued transformation, right?

    And we saw this past year, unfortunately, without digital transformation and the move to a connected world software, where would we be, right? We would be in a lot worse shape than we were. And cyber security is the biggest threat to this. We need—we need to stop taking and do more doing, right, when it comes to building more secure software, right? And if people are building software like Shlomi and the team say, liquid software, right, without versions, it’s gotta be secure. And not only, it has to be secure, people have to be confident that it’s secure, right? Because that’s the biggest inhibitor—that’s the inhibitor, the lack of confidence.

    Davidi: And you can see this coming clearly, finally, from the regulators starting to draft bills around it, and you see demand from the end users—not necessarily consumers, but everyone, hospitals, manufacturers, they start to telling, “you want to buy from you, I want your software to be secure.” This is a demand, this is a requirement for RFPs, for RFIs. We see it everywhere. So, this is going to be a boon, because so far, the cyber security space was highly focused on the after the fact security, on the enterprise, care about, take care of it from the very beginning all the way to the network. And this is the only—

    Shimel: No, this builds up material, right, Nati? I’m sure you’re familiar, right? And there’s EEO, the bills of material order. Look, if this thing—you know, why did it take so long? I don’t know, but if this thing catches on that you need to have a bill of material for every software out there, for every app out there, people will, you know—go ahead.

    Ben Haim: I will just add to it, Alan, it also makes sense the way it happened. Look at the digital transformation. We are now facing the second wave of it, and we started to realize, everyone, every organization started to realize that being fast is not good enough. But you have to be fast first ________.

    Shimel: Yeah.

    Ben Haim: And then to build the security solution around it. So, developers delivered. They started to be faster than the security team, and now, security is catching up. But if you look at 99.9 security companies, they are not selling value, they are selling fear. They are telling you what will happen, what will happen if you will not do that. And developers hate that. Developers want to build, they want to have the freedom of choice and to be faster. And the security tools that are not focusing on the right pain have to be sold as fear and not as value. And this is the change that JFrog and Vdoo will bring to the market. Putting ________ aside, we focus on the community pain, as we did with Artifactory, as we did with Xray, as we announced just three weeks ago at swampUP with JFrog distribution. How can you distribute if it’s not secure all the way to the edge?

    Shimel: Okay. We’re running low on time, but let me bring together a little—I need some nuts and bolts, here.

    So, the deal was announced on Tuesday, today’s Thursday. Is it closed yet, was it—without getting into, I know you’re not gonna discuss the particulars, but is the deal closed? If not, when is it supposed to close? When are the Vdoo people, when are these hackers joining the developers, chocolate and peanut butter? When are we gonna see it?

    Ben Haim: Yeah, we hear this question again and again, first from our team, what are the first signs that we would like to see and what are our other plans?

    So, obviously, the definitive agreement is signed, and the closing is supposed to be in the next few weeks. We already have both sides, teams standing ready to merge the products, and the first step will be merging the infrastructure, making sure that this wonderful research that Vdoo is leading with vulnerabilities and database is also merging to Xray so our users can start enjoying that. We are thinking about the product philosophy, the hybrid cloud and on prem—all cloud, all regions, cloud native ready, the unified solution that will be scalable for our users. We have over 6,000 customers that are waiting for something like that.

    So, obviously, we will take the first leap and merge the assets and the low hanging fruit into Xray. And then, during 2022, we will build a unified platform that will include Vdoo’s capabilities into the JFrog platform.

    Shimel: Excellent. Excellent. Nati, just a question for you. I mean, obviously, all the people at Vdoo will stay on at JFrog. For people who may be very familiar with JFrog but have not heard of Vdoo, what’s the Vdoo website?

    Davidi: It’s Vdoo, V-D-O-O dot com.

    Shimel: Excellent. Alright. You can go find out more about it there. As I said in the beginning, Nati—congratulations, mazel tov on…you know, I learned from a mentor once, it’s kinda like a boat. The best two days are the day you start the company and the day you sell your company, so congratulations on that, it’s a beautiful thing.

    Congratulations to you, my friend, Shlomi, right? This is a piece of the puzzle that was missing and it’s important, and it’s gonna be more important every day going forward, so—good stuff.

    Ben Haim: It’s important, it’s a very, very exciting market for us. It’s increasing our addressable markets, and more than everything, we’re bringing over almost 100 people that have the same DNA and the green blood just like JFrog.

    Shimel: Look, getting 100 security experts at a shot—that alone might be worth it, because they’re hard to come by, my friend. Alright, Nati, congratulations. Shlomi Ben Haim, CEO—thank you, as always, my friend.

    This is Alan Shimel, we’re on Tech Strong TV. We’re gonna take a break. We’ll be back in a moment.

    [End of Audio]

  • Redefining Continuous Security for DevSecOps

    Redefining Continuous Security for DevSecOps

    In the mobile app development world, security often takes a backseat to developing features and delivering the app. In fact, the 2021 Verizon Mobile Security Index found that 45% of organizations sacrificed mobile security in order to “get the job done.”

    It really shouldn’t come as a surprise. Certainly, it seems counterintuitive that mobile app development organizations would spend so much time and money to create an exceptional Android or iOS app and then fail to protect it against rooting, jailbreaking, reversing, hacking and other kinds of malicious manipulation. But the average mobile developer releases 12 apps each year; a frenetic pace that requires development to take place in parallel, without ceasing. Schedules and budgets are tight, and competition is fierce. Coding security into an app is both expensive and time-consuming, increasing the risk of a delayed release or budget overages.

    In many organizations, if security is implemented into a mobile app at all, the process takes place during penetration testing. That’s too late, and it’s extremely inefficient. Waiting to implement security after development and delivery are essentially finished will anger developers because now, they have to dive back into their code to make complex changes to work they thought was finished. The code is no longer fresh, so it’s going to take more time than it would have if security implementation had taken place during the development process itself.

    But integrating security into the development process is no simple task either. Imagine two friends are spinning a couple of jump ropes. Jumping in the middle without stepping or tripping on either of the ropes while they are moving is difficult. Each time a security feature is introduced into a mobile app’s software development life cycle (SDLC), the person building the security could step on the rope. Building security features takes time, and they are hard to build and maintain.

    Our Oversimplified Model of DevSecOps

    To solve this problem, DevSecOps was introduced to resolve this conflict and overcome the challenge of integrating security into the mobile SDLC. The idea is that organizations can develop features and incorporate security simultaneously. So far, much of the emphasis in DevSecOps has been focused on the processes development, security and operations that teams use to build, protect and release apps. People have done heroic work creating cultures of security and secure coding practices, which has moved the industry forward toward more secure mobile apps for everyone.

    Let’s take the jump rope analogy a bit further. One friend holding the ropes is the development and engineering team, while the other is the ops/release team. The ropes each represent an iOS and an Android app. In most organizations, the ropes are moving at blazing speeds, as apps are churned out one after the other. Meanwhile, on the sidelines, there’s the security team, whose job is to make sure the ropes meet security objectives, jumping in where needed, all without stopping the ropes from spinning.

    The trouble is that each group has different skills and objectives. Developers aren’t typically security engineers, and security teams don’t typically have developers. Neither group has the resources or skills to meet the needs of the other, and whenever they try, one of them trips on the rope.

    Mobile DevSecOps, Meet Continuous Security

    The only way to keep the current breakneck pace of app releases going while simultaneously providing security is to introduce as much automation as possible. AI systems can fuse security to an app more cost-effectively and consistently, complete with validation that the features required have been implemented. It’s different from code scanning, which occurs after the app is built and leaves remediation to the dev team. I’m proposing that the implementation of security itself be automated.

    The growing threats to mobile apps are too significant for development teams to ignore, but so are the market pressures that force such short delivery timescales. The only way out of this dilemma is extensive automation. Otherwise, the dev and sec teams will keep continuously tripping on each other’s ropes.

  • CloudTruth Acquires Tuono to Advance Configuration Management

    CloudTruth Acquires Tuono to Advance Configuration Management

    CloudTruth, a provider of a unified configuration management platform, today revealed it has acquired Tuono, a provider of a cloud secrets management platform, as part of an effort to make it simpler to secure infrastructure provisioned using code. Terms of the deal were not disclosed.

    Greg Arnette, CloudTruth CEO, said misconfigurations are rife across cloud computing environments. IT organizations now need a self-documenting approach to managing configurations as the number of cloud services that organizations can employ continue to multiply. The CloudTruth platform will automatically keep track of all configuration changes made to an IT environment, Arnette said.

    The rise of Kubernetes and microservices is making things even more challenging, introducing a range of additional opportunities to misconfigure cloud platforms and applications.

    Fresh from raising $5.25 million in seed funding, Arnette said one of the least-appreciated aspects of the configuration challenge is how dependent organizations are on tribal knowledge that gets shared unevenly across DevOps teams. The lack of a centralized repository for managing configurations makes it challenging to onboard new members to those DevOps teams, he added, resulting in more opportunities for mistakes to be made.

    Tuono adds a cloud-native secrets management platform that can be deployed across multiple cloud services. The goal is to provide a configuration management platform that functions as a metadata wrapper compatible with configuration tools such as Terraform or CloudFormation from Amazon Web Services (AWS). That approach reduces the cognitive load on DevOps teams that would otherwise have to remember how and why each service is configured the way it is, said Arnette.

    Arnette added that an additional goal is to enable DevOps teams to put guardrails in place that reduce the opportunities for misconfiguration errors to be made while continuing to enable developers to build and deploy applications quickly. Each organization will need to decide where to strike a balance between those competing agendas, noted Arnette.

    The challenge organizations are wrestling with today is just how vulnerable software supply chains are—as a series of cybersecurity attacks have made all too apparent. Organizations are adopting DevSecOps best practices to better secure those supply chains. However, the rate at which DevOps teams can come up to speed on security isn’t fast enough to secure applications that are about to be deployed. At the same time, there are potentially hundreds of applications deployed in cloud platforms with varying degrees of misconfigurations. Cybersecurity teams are now being asked to review how well those applications are configured as part of an effort to address the security of the entire software supply chain.

    It’s not clear if a backlash against DevOps, in general, is in the making as cybersecurity teams review application development and deployment practices. There undoubtedly will have to be adjustments made to those processes, even as most organizations realize just how dependent they are on software. The issue is that deploying more insecure applications faster is, at the end of the day, counterproductive.

  • Aqua Security Acquires tfsec to Advance DevSecOps

    Aqua Security Acquires tfsec to Advance DevSecOps

    Aqua Security today announced it has acquired tfsec, an open source project that provides a static analysis scanner for infrastructure-as-code (IaC) that is designed to be integrated within a DevOps workflow.

    Amer Jerbi, Aqua Security CTO, said tfsec extends the security platform the company already provides in a way that advances adoption of DevSecOps best practices. In addition, to prevent developers from misconfiguring cloud infrastructure using tools such as Terraform, the scanner surfaces examples of code that provide developers with insights into how to properly configure infrastructure.

    Jerbi noted that tfsec is already integrated with Aqua Trivy, an open source tool that scans container images for vulnerabilities. Integrations with the rest of the Aqua Security portfolio will follow, added Jerbi.

    Tfsec co-founders Liam Galvin and Owen Rumney will join Aqua Security as cloud engineers. The challenge Aqua Security is trying to address is the need to enable organizations to proactively prevent cybersecurity issues from arising in production environments rather than only identifying vulnerabilities that need to be fixed, said Jerbi.

    Aqua Security tfsec

    The decision to acquire tfsec comes in the wake of a series of high-profile breaches when many organizations are scrambling to make sure software supply chains are secure. Cloud platforms are rife with misconfigurations mainly because developers often lack the expertise needed to ensure infrastructure is secure after they have provisioned it. Organizations are embracing DevSecOps best practices in the hopes of educating developers to assume more responsibility for application security. However, developers are not going to acquire that expertise overnight. The tfsec scanner provides a way to enforce security policies today while at the same time affording the time to teach developers how to avoid misconfigurations.

    It’s unclear how many cybersecurity events arise because of cloud misconfiguration issues. The cloud service providers have adopted a shared responsibility model that makes the organization employing the cloud responsible for both the applications deployed on those clouds and for how that infrastructure is provisioned. Many developers that provision cloud infrastructure themselves within the context of a DevOps workflow often assume the cloud service provider is doing more than it is to prevent misconfigurations. Cybercriminals, meanwhile, have become very adept at scanning for those misconfigurations.

    There are, of course, a lot of layers and nuances when it comes to DevSecOps. Arguably, Jerbi said, the most critical thing for most organizations is to simply get started. Tools that can be quickly and easily integrated within an existing DevOps workflow with minimal disruption are critical, Jerbi added.

    In the meantime, DevOps teams should expect cybersecurity teams to become more involved in their workflows, especially as government mandates aimed at securing software supply chains become stricter. Eventually, as organizations gain confidence in the ability of their DevOps teams to secure their application environments, those cybersecurity teams will refocus their efforts on hunting for threats. In the meantime, DevOps teams would be well-advised to make those cybersecurity professionals feel as welcome as possible, given the application security mandate most of them have been given.

  • 8 Security Considerations for CI/CD

    8 Security Considerations for CI/CD

    In the software development enterprise, CI/CD refers to the combined practices of continuous integration and either continuous delivery or continuous deployment. CI/CD enables organizations to bridge the gap between development, operation activities and teams by the use of automation when building, testing and deploying applications. 

    How do you maintain quality and security with frequent deployments? While CI/CD can improve the efficiency of an organization, there are many security considerations to take into account.

    To gain insights on the top security considerations for CI/CD, I asked the speakers and sponsors for the upcoming SKILup Day as well as several DevOps Institute Ambassadors for their thoughts. Here’s what they had to say in part one of this two-part series:

    Speaker, Grant Fritchey, Product Advocate, Redgate Software

    “There are a lot of security considerations when it comes to CI/CD. As a person focused on data and data management, I’m going to say that the top security consideration is ensuring that you have compliant data for your non-production environments. Just the sheer number of people who will have access to the information means that you have a huge number of possible vectors for a breach if you’re exposing protected information.”

    Speaker, Anders Wallgren, VP of Technology Strategy, CloudBees

    “Secure your software delivery pipelines themselves, not just the software that you deliver with those pipelines. Everyone should have only the level of access they require in order to perform their role.

    Maintain a Software Bill of Materials (SBOM) so you know what you have in production. When a new vulnerability is disclosed, you will have a much easier time deciding whether and how to mitigate it if you don’t have to chase down what you have in production. Your orchestration software should do the lion’s share of the work here.”

    Tracy Ragan, CEO and co-founder, DeployHub

    “CI/CD tools are driven mainly by one-off scripts. There is absolutely nothing secure about one-off scripts. From build through deploy, we need to start thinking of implementing automation and policy-driven tools and dump the one-off scripts.”

    Tiffany Jachja, Technical Evangelist, Harness

    “Supply chain management is a major security consideration for CI/CD. If an entity gains access to a CI/CD resource or component that they shouldn’t, this can lead to vulnerabilities, downtime or even malicious code. For example, in the SolarWinds hack of 2020, attackers legitimized their software malware by injecting it into the SolarWinds build process. This build pipeline produced trusted software artifacts and obtained digital certifications before being released to over 18,000 customers worldwide. After the hack, SolarWinds took action, further restricting access to its build environment and reviewing its build process, but not before it was too late. It’s not only about automating developer and operations workflows but also how we treat and handle CI/CD pipelines.”

    Jamal Walsh, Technical Product Owner, The Very Group

    “You must make sure you implement security tooling within your pipeline; it’s not enough to just use CI/CD to build and deploy applications. Steps in your pipeline should include security testing tools like SAST, DAST, dependency checks, etc.”

    Martin Chan, System Analyst, Global Executive Consultants Ltd. 

    “The most important thing is to define the access control list and rules to control the access in the CI/CD pipeline so that the audit log can easily trace issues. Also, the system should require authentication and define password policies for all users.”

    Bryan Finster, Software Engineer, DoD Platform One

    “Security must be automated as part of the pipeline. Just like any other quality gate, the pipeline must be the single source of truth for security. Any manual process after code is committed increases the effort to deliver. Increased effort increases the size of each change. Larger changes are harder to check for quality and fail more spectacularly. Manual security is just security theater and is easily bypassed or forgotten. That effort is better spent improving the ability of the pipeline to use security as-a-service.”

    Dheeraj Nayal, Global Community Ambassador, DevOps Institute

    “Follow the three security best practices for CI/CD. We usually divide security practices into three parts that you can address with different kinds of solutions. These are:

    1. Secure pipeline configuration
    2. Code and Git history analysis
    3. Security policy enforcement

    All three aspects are equally important.”

    If you’d like to learn more about the latest in CI/CD and similar topics, check out the upcoming SKILup Day schedule. Or, learn more about the benefits of becoming a DevOps Institute Member. 

     

  • Fugue Aims to Simplify Securing Infrastructure-as-Code

    Fugue Aims to Simplify Securing Infrastructure-as-Code

    Fugue today unveiled a 1.0 release for Regula, an open source policy engine for infrastructure-as-code (IaC) security that comes with prebuilt libraries for implementing hundreds of policies that validate configurations on Amazon Web Services (AWS), Microsoft Azure and Google Cloud services.

    Regula is based on the Open Policy Agent (OPA) software being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) and is compatible with both Terraform and AWS CloudFormation tools for configuring cloud infrastructure.

    Developers can also build custom rules on top of OPA using libraries that Fugue created for the Rego programing language that is part of the OPA specification. Regula supports output formats such as JUnit, Test Anything Protocol (TAP) and JSON to make it easier to integrate Regula with other tools and frameworks that make up a DevOps workflow. Input formats supported include Terraform HCL, Terraform plan JSON, AWS CloudFormation and Serverless Application Model templates.

    Regula also provides out-of-the-box support for the CIS Foundations Benchmarks in addition to other policies defined by Fugue, such as dangerously permissive identity access management (IAM) policies, Lambda function policies allowing global access, volumes with encryption disabled and untagged cloud resources.

    It is deployed as a pre-packaged binary that includes a command line interface (CLI) through which Regula can be incorporated within a DevOps workflow and can be installed using tools such as Homebrew or deployed as a Docker image.

    Fugue CEO Josh Stella said Regula provides DevOps teams with an extensive library of rules that check for common security and compliance violations as well as advanced multi-resource misconfigurations. That latter issue is especially challenging because developers typically don’t have much visibility into dependencies that can inadvertently provide cybercriminals with access to, for example, an S3 cloud storage bucket that otherwise appears to be configured properly. Regula will also identify any required resources that might be missing, as well, added Stella.

    Stella said Regula 1.0 provides a simpler approach to securing cloud infrastructure. Cloud infrastructure is frequently misconfigured simply because a developer made a mistake. Unfortunately, cybercriminals have become especially adept at scanning cloud platforms for these misconfigurations, noted Stella.

    It’s not clear to what degree a backlash might be building against IaC in the wake of recent high-profile breaches of software supply chains. Organizations have embraced IaC tools to make developers more productive. However, each security incident involving a misconfiguration of cloud infrastructure resources makes it all too apparent that developers lack the expertise required to securely provision IT environments. Rather than creating a series of cybersecurity reviews that would reduce developer productivity, Stella said Fugue is making a case for a compliance-as-code approach that developers can readily understand and implement.

    One way or another, cloud infrastructure has to become more secure. Business leaders are growing weary of security incidents that, from their perspective, are caused by careless mistakes. Their first instinct is to empower cybersecurity teams to resolve those issues once and for all. The only issue that needs to be resolved now is just how cumbersome those security reviews need to be if developers are provided with the tooling required to secure cloud platforms themselves.

  • JFrog Acquires Vdoo to Advance DevSecOps

    JFrog Acquires Vdoo to Advance DevSecOps

    JFrog today announced it has agreed to acquire Vdoo for $300 million in cash to gain a set of analytics tools that discover vulnerabilities in application binaries.

    Vdoo’s scanning tools, infused with machine learning algorithms, will be fully integrated with the JFrog Xray vulnerability detection tools along with the rest of the JFrog continuous integration/continuous delivery (CI/CD) platform in 2022. In the meantime, the Vdoo scanning tool will continue to be made available via a software-as-a-service (SaaS) platform that Vdoo built.

    The Vdoo platform is already integrated with the JFrog Artifactory repository and JFrog Pipelines. Vdoo’s platform also is integrated with DockerHub, Jenkins, GitHub, GitLab and Azure Pipelines via REST application programming interfaces (APIs) that make the Vdoo scanning tools accessible via a command line interface (CLI).

    JFrog CTO Yoav Landman said acquiring Vdoo is critical because when it comes to implementing DevSecOps best practices, the only meaningful place to discover and remediate vulnerabilities is in the binaries deployed in production environments. As such, the Vdoo platform provides a superior alternative to both static application security testing (SAST) and dynamic application security testing (DAST) tools that scan for vulnerabilities in source code, added Landman.

    Developers require accurate intelligence that can be quickly acted upon to secure applications running in production. They can quickly take action once they know how a specific vulnerability impacts a binary, versus being told to update source code that could take days or weeks to complete, noted Landman. The Vdoo platform also makes it possible to leverage machine learning algorithms to detect zero-day vulnerabilities, malware, exploits, backdoors, supply chain risks and other threats before they become commonly known. Those vulnerabilities can be detected in everything from application binaries to firmware running on embedded devices. Vdoo is also recognized by the Mitre Corp. that oversees the Common Vulnerabilities and Exposures (CVE) database as a CVE Numbering Authority (CNA) for discovering vulnerabilities.

    JFrog Vdoo

    As responsibility for application security continues to shift left toward developers, many organizations are finding the tools that cybersecurity teams employed to discover threats don’t lend themselves to the workflows that developers have created to build applications. As a result, many of these tools are being replaced by developer-friendly alternatives that developers can invoke via a CLI as part of DevOps workflow. The goal, now, needs to be reducing the level of noise created by security tools to enable developers to focus on the vulnerabilities that specifically impact their code, noted Landman. Otherwise, developers are simply overwhelmed by a massive number of alerts generated by security tools that often don’t appear to be especially relevant, Landman added.

    It’s not clear how quickly responsibility for application security is shifting left. However, in the wake of a series of high-profile software supply chain breaches, the urgency surrounding adoption of DevSecOps best practices has increased considerably. The challenge, as always, is getting the right tools into the hands of developers at the right time.

  • TraceAI : Machine Learning Driven App and API Security

    TraceAI : Machine Learning Driven App and API Security

    API security

    Modern applications are mobile first and are built around cloud-native distributed microservices architectures. These architectures have become the basic building blocks for complex and reliable distributed web and mobile applications. Many of these distributed APIs expose the business logic directly over the web; hence the attack surface and attack vectors are very different for these next generation applications. These next-generation applications demand next-generation application security solutions that need to stitch together a distributed application’s activity using techniques such as distributed tracing and then use next generation ML techniques to solve important application security problems.

    Proactive anomaly detection

    Anomaly detection approaches are a practical way to discover unseen strategies of attackers. However, these approaches are prone to very high false positive rates, thereby defeating their very purpose. Most anomaly detection systems flood analysts with false alarms resulting in a cognitive fatigue. Traditionally, the pitfalls of anomaly detection approaches have been addressed via false-positive workflows, better user interfaces and user experience tools. Analyst feedback is taken as a reinforcement on the algorithm and the algorithm tunes itself. However, the engineering cost of such an approach is very high and the product gets very complex leading to reliability and flexibility issues. Secondly, it still requires analysts in the loop to tune the back-end algorithms. Most practitioners think the issue lies with the anomaly detection algorithms, but in reality there is nothing much that the underlying mathematics powering these algorithms can really do in a cyber security setting. These very algorithms have been proven in domains other than cyber security.  At Traceable, we believe that the problem lies elsewhere. Our understanding of the nature of data shows that we need to support anomaly detection algorithms with something else. We need to marry specific application security nuances with the mathematics powering these anomaly detection algorithms. This understanding led us to build TraceAI.

    TraceAI and API

    TraceAI is the core engine that powers the application security functions of the Traceable Security Portfolio. The foundational principles behind TraceAI are:

    • To be able to dissect the AppSec requirement into the constituent entities that are root causes for application vulnerability
    • To be able to holistically observe the interaction behavior among these entities
    • To be able to discover anomalous patterns in this  behavior

    Using these guiding principles TraceAI implements a complex behavioral anomaly detector. To power this behavioral anomaly detector, we have identified five entities that interact with one another to result in security vulnerabilities. They are:

    • APIs – the basic building blocks of the distributed applications
    • API interaction – how these APIs are wired in order to provide the intended functionality
    • Actors – users, IP addresses or client-side applications such as mobile apps that use APIs to benefit from the intended functionality or in a malicious case, subvert the intended functionality. The actors may be assigned different roles such as admins, clients, managers etc…
    • API Data – inputs from actors required for the APIs to come to life. Outputs from APIs in response to the input.
    • Resources – back-end data or compute functionality requested by actors by calling APIs

    TraceAI combines APIs, API interaction, API data, resources and actors holistically to build an actor-centric and API-centric behavioral anomaly product. As a result, common behaviors, outlier behaviors, automaton behaviors (bots), and attack behaviors are discovered from trace data. These behaviors are API-centric as well as Actor-centric.

    False positives are eliminated by introducing additional security concepts commonly referred to as Trust-and-Risk models. TraceAI automatically identifies API risk and Actor-trust by observing data relative to a baseline which is again automatically built. The baseline in itself is not a piecemeal integration of various unconnected baselines, but is a holistic combination of various observations modeled using modern machine learning tools. We do not need teams of data scientists and security engineers to support the system as the underlying algorithms automatically learn from data. Once in production, the algorithms run in a self-drive mode, automatically building baselines and generating ML models.

    Machine learning algorithms under the hood

    The foundation of any machine learning is the depth and breadth of the dataset relative to the number of features used for detection purposes. Traceable agents, deployed inside your application, API gateways, and Kubernetes cluster, automatically collect all the necessary data and build distributed traces that form the data-layer foundation for TraceAI. Traces are continuously collected to become a learning set on logic and data flow from Edge APIs, to internal APIs to backends and third party services and thus generate the features that represent the application context. Having addressed the data challenge via the tracing platform our next challenge was to choose appropriate machine learning technology.

    The biggest challenge for machine learning in cybersecurity is having to deal with high-dimensional categorical data of sequential nature, combined with the need for explainability, causality, and attribution. Because the attackers’ strategy constantly changes, supervised learning has its limitations. Most popular ML algorithms fail miserably while simultaneously dealing with these two requirements. Taking these factors into account, we have engineered ML-based solutions by building algorithms ground-up (instead of fully relying on libraries) and adopting a self-supervised learning framework. Our unique way of representing multidimensional categorical information allows us to perform ML-based detection even on certain forms of encrypted data as well.

    A key component of the ML-based solution is the ability to discover the API endpoints, and to automatically generate the API spec via data analysis. As a result the expected request/response headers, body parameters and query parameters are not only identified, but are also characterized. This helps build the API spec, violations to which are flagged as anomalies. This completely automated process without the need for manually annotated data is feasible owing to the richness of data captured by the core distributed tracing platform.

    Complementing the ability to detect API data anomalies, TraceAI also detects anomalies in API interaction, and anomalies in users accessing these APIs. The User Behavior and Business Logic representation modules capture, represent and build baselines for regular user behavior and expected business logic. Unsupervised ML techniques are employed because these techniques are the only scalable alternatives. Once the baseline models are built, business logic abuse and behavior deviations are captured and surfaced as alerts.

    Extending behavioral anomaly detection to predictive threat detection, TraceAI introduces a novel exploratory learning paradigm for API security. This approach harnesses the fundamental principles behind reinforcement learning, adapted uniquely to application and user behavior representation. Using such an approach, we are able to generate potential anomalous patterns even before they occur. By comparing users’ activities against these generated patterns, we can identify users who are beginning to tread on a dangerous path. Hence, we can flag these users even before a full-blown attack is launched. As a byproduct, we are also able to quantify known and risky behaviors without manual intervention. Some of the machine learning techniques that we have used in order to power TraceAI are MinHash based embeddings, hierarchical user behavior clustering using LSH and OLAP-style sub-clustering, Bi-Directional RNN variants for time-series anomaly detection, and use of random walks with evolutionary algorithms for explorative learning.

    Anomalies in user behavior in the context of business logic

    Understanding application behavior and user behavior helps in:

    • Identifying violations to known user behaviors
    • Discovering novel behaviors
    • Grouping users based on their behaviors to create user cohorts
    • Determining how exactly APIs are being used in order to build a web application

    One can represent user cohort behavior as a summarized flow-graph as shown below.

    sample application flow
    Sample application flow.

    Each node in the graph represents an API that was called during an active user’s session. Two  nodes are connected if there is a transition from one API to another, and the flow between two nodes represents various statistics such as how many users exhibit such a transition or how often such a transition occurs across user sessions and so on.

    In the above figure, there are around 26 different nodes, each representing an API, and the flows connecting these nodes indicate paths of API access  based on monitoring users’ API call graphs. For a human analyst, this map is very difficult to comprehend and more so to detect that a particular user’s behavior has changed compared to other users’ behavior or to detect that a particular user’s behavior has changed compared to a baseline. Only machine learning algorithms can automatically interpret these kinds of representations and that too at the scale that we have to deal with.

    Behavioral clusters

    The figure above shows how TraceAI was able to create user behavior groups based on the pattern of API access. In essence TraceAI has peered into the complex flow graph shown above and then identified groups of users based on their respective API call flow behavior. The gray circles represent users who fall under commonly occurring behavior groups. These groups are low priority for an analyst as they are population characteristics. The red circle-A represents a user whose behavior is very similar to the gray circle-B. This means the user in circle-A is accessing the same APIs as users in  circle-B but managed to attack one or more APIs.  This further implies that the user in circle-A is following the same business logic as many other users but has managed to compromise one or more APIs. This is interesting information for an analyst, because one can now understand what led to the compromise in addition to knowing what was compromised.

    Tracking user behavior to detect API attacks

    Here, the figure above shows the user’s behavior and where exactly the attacks took place. There were authorization bypasses detected in two of the APIs (nodes) colored in red. The analyst now knows where the attack took place and how they got to this stage. The APIs leading up to the attacked API can now be analyzed for security vulnerabilities and code design flaws. In essence TraceAI has isolated and surfaced interesting behaviors from many possible behaviors so that security analysts can investigate further. By cutting down on possible candidates, TraceAI has reduced cognitive load and investigation fatigue by many orders of magnitude. TraceAI can also detect outlier behavior to flag groups of users who are not explicitly responsible for a known attacks, but are exhibiting suspicious behavior and not being like the rest of the users. Analysts can also dig into the outlier groups shown as “blue” circles, analyze few of these users, and then as a batch put all these users under a watch list. By working at the level of a group, multiple users can be tagged/flagged/watched without having to deal with each user separately.

    Summary

    Traceable combines the power of Distributed Tracing and TraceAI technologies to protect next generation attacks on Web Applications and APIs. By choosing the right machine learning technology, and focusing on addressing API security issues Traceable is pushing the boundaries of API security.

    We would love to talk to you further and demonstrate how our technology addresses API security issues in your environments.

  • Dynatrace Applies AI to Surface App Vulnerabilities

    Dynatrace Applies AI to Surface App Vulnerabilities

    Dynatrace has enhanced the security module to its observability platform that leverages its Davis artificial intelligence (AI) engine to automatically identify the software libraries and open source packages that represent the greatest security risk.

    Ajay Gandhi, vice president of product marketing for Dynatrace, said the Davis Security Advisor, being added to the Dynatrace Application Security Module, makes it easier for IT teams to understand which vulnerabilities need to be remediated first.

    Davis Security Advisor aggregates vulnerability data in real-time and prioritizes remediation based on the number of vulnerabilities, severity, impact to sensitive data, public exposure, how widely known the vulnerability is, and whether the code impacted is facing the internet. That approach enables Davis Security Advisor to monitor all software libraries used in preproduction and production environments in a way that sharply reduces the number of false positives that would otherwise be generated, noted Gandhi.

    Dynatrace

    As application environments become more complex—in part due to increased adoption of microservices that have lots of dependencies—it’s become impossible for IT teams to implement DevSecOps best practices in workflows without some form of AI augmentation, added Gandhi.

    In fact, a recent Dynatrace survey found 89% of chief information security officers (CISOs) noted cloud-native architectures and container runtime environments, used primarily to construct microservices, have made it more difficult to detect and manage software vulnerabilities.

    In theory, application developers are taking more responsibility for remediating security vulnerabilities within their applications. The challenge is they often inadvertently use an older version of a library that has known vulnerabilities. Hopefully, that issue gets addressed before an application gets deployed. There are, however, plenty of cases where, for one reason or another, a library with known vulnerabilities gets deployed anyway.

    Making matters more challenging, many vulnerabilities are discovered after an application has been deployed. Developers don’t always have access to a software bill of materials that would make it easier to determine what libraries have been employed in what application or, for that matter, which libraries are dependent upon one another.

    Gandhi said the Davis Security Advisor resolves that issue via continuous topology mapping of dependencies to identify those potential security issues. Once identified, the updates that need to be made can then be slipstreamed into a DevOps workflow.

    Analyzing code for vulnerabilities is, of course, not a new idea. Training an AI model to perform that task on behalf of DevOps teams does promise to greatly accelerate the process at a time when organizations are under more pressure than ever to secure their software supply chains in the wake of a series of high-profile breaches.

    It’s just not clear yet who inside organizations might drive adoption for AI platforms capable of identifying vulnerabilities in a way that helps prioritize remediation efforts. In some cases, cybersecurity teams have a vested interest in reducing the number of potential security incidents.

    The one thing that is apparent is shipping insecure code faster only leads to more negative outcomes. There may not be such a thing as a ‘great’ application that happens to be insecure. Instead, the assumption will be that any applications with known vulnerabilities, no matter how great, are too flawed to be deployed given all the security risks most businesses currently face.

  • AppSec Marketing in the Age of DevSecOps

    AppSec Marketing in the Age of DevSecOps

    A while back, I had a conversation with a friend I went to school with (currently a senior member of the engineering team at a large retail chain) who was tasked with the job of identifying potential application security partners (he addressed vendors as partners, which I personally liked) to collaborate with on various areas as part of their product security initiative. The following piece emerged as an extension of my immediate thoughts when he shared his views of what could have made his experience of interacting with front-line sales and marketing folks better.

    In the context of DevSecOps, much has been said about the need for engineering to speak security, security to speak code, DevOps to speak security, etc. But as a technology service provider (TSP) riding the current wave of application security, it’s almost mandatory for the sales and marketing teams to also speak relevant tech!

    Application Security Is Not One-Size-Fits-All

    Application security, as a practice area, is dynamic. No two applications are the same, even if they belong in the same market domain, presumably operating on identical business use cases. Some (of the many) factors that cause this variance include technology stack of choice, the programming style of developers, the culture of the product engineering team, priority of the business, platforms used etc. This, consequently, results in a wide spectrum of unique customer needs.

    Take penetration testing as an example. This is a practice area that is, presumably, well-entrenched both as a need and as an offering in the application security market. However, in today’s age, even a singular requirement such as this could make or break an initial conversation. While for one prospect, the need could be to conduct the test from a compliance-only perspective, another’s need could stem from a proactive software security initiative. There are many others who have internal assessment teams and often look outside for a third-party view. Others who are further along the maturity curve could be looking to up their game through a hybrid approach of tool automation with a complementary method of manual assessments. I’m not even considering the added complexity involved in the nomenclature of such a service—is it called penetration testing, security testing, vulnerability testing, VAPT (which actually is a combination of two independent practices) etc.?

    Each of these unique needs emerges from buyer personas which emerge from varying degrees of informed decision making. TSP’s would need to retrofit their positioning accordingly. They often run the risk of underwhelming a mature buyer or overwhelming an early practitioner, especially in high variance offerings such as security tooling, security regression and threat modeling, for example. While some might argue that losing an overwhelmed prospect could be the result of their accurate customer segmentation, there are other reasons for this.

    Scoping questions, such as the ones below, can significantly help technology marketers strike the right chord with their prospects and elevate the experience of the initial interaction.

    • What is the motivation for the penetration test? Is it compliance regulation, internal validation, business drivers, their customers’ needs, etc.?
    • What are they specifically looking from a third-party partner? Is it external certification, a specialized approach, uncovering logic flaws, etc.?
    • What is the current appetite (measured in resource bandwidth, commerce) to take on your advanced offering? (Such as automation, regression etc.?)
    • How security aware are the developers? Can they take the findings to their logical conclusion through successful remediation?

    DevSecOps Is About the Journey, Not the Destination

    Ever since the surge of DevSecOps, marketers and practitioners have been vocal about the possibilities and advantages that smart automation brings with it. Think tanks, too, have statistically alluded to its benefits in terms of cost savings and bandwidth efficiency, among others. Though recent marketing campaigns have rather effectively communicated the ‘what of DevSecOps and AppSec automation, more awareness of the ‘how’ of DevSecOps is needed. TSP marketers need to design and propagate content on use cases focusing on the implementation challenges and suggested how-tos. Such content not only helps build trust and credibility but also allows segues for tech marketing to collaborate with security engineering. Some of these include practical guides on open source tool automation and sample automation scripts and libraries, data sheets on resource optimization through automation and handbooks on vulnerability remediation, just to name a few.

    This collaboration between marketing and sales and security would provide an opportunity for the former to get themselves well entrenched in the practical workings of the service or solution that they are responsible for positioning. Ironically, this also allows them to appreciate constraints that would prevent them from over- or under-committing business value to their prospects through their messaging. This is especially more relevant with the numerous myths that surround application automation and DevSecOps in general.

    The DevSecOps Rolodex

    In 2012, I had the opportunity to meet with one of the senior CISOs in the industry. After some initial small talk, I was introducing what we did and how we thought we could help his team. I was 70 seconds into what was my planned 180-second pitch when he respectfully stopped me, pulled out a rather impressive Rolodex from his desk and said, “I could point you to 15 companies in a 20-mile radius who could help me with exactly what you’ve offered me. I wonder if there’s any secret sauce?”

    Startled, embarrassed, I managed to gather my thoughts and moved to the final 30 seconds of the pitch, though with much hesitation. As luck would have it, he found little bits of the secret sauce. The meeting obviously did not go exactly as I had planned, but it didn’t go badly, either. However, it made me realize that our customers and prospects often know just as much—or even more—about our competition than we do. Everybody is selling, all the time. So, someone else has already made their 70-second pitch. Not everyone gets lucky enough to be given an opportunity for a pause! It’s up to us to find the secret sauce and make that close in the final 30 seconds.

    We are riding a very healthy wave of application security focus right now, and it’s paramount that technologists and marketers collaborate to identify and nurture their own secret sauce in their messaging and positioning. After all, this is what is going to keep the person at the other end of the table from reaching out to others in their DevSecOps Rolodex!