devopsy.kinsta.cloud

Tag: dynamic analysis

  • Modern DevOps is a Chance to Make Security Part of the Process

    Modern DevOps is a Chance to Make Security Part of the Process

    I’ve mentioned before, and many of you have lived through, the slowly changing beliefs around DevOps versus security. We are past the days of “Security slows us down” and into “How can we bake security into the development process?” which is essential. Indeed, I would say it’s more essential every day as the number of threat actors and their use of automation to perform more attacks increases.

    So where can we slip in a little security to protect those sweet, innocent apps from the Big Bad Wolf? Let’s make a list, then chat about it.

    • Source code
    • Inclusions–libraries, shared objects, etc.
    • Container/cloud images
    • Network
    • Running applications and APIs

    This is honestly not an exhaustive or detailed list, but we’re writing a blog here, so let’s stop there so we have time to discuss.

    Source code security is greatly enhanced by putting in any of a dozen development security tools, which include static and dynamic security scanners along with a variety of other features.

    Inclusions are often nested and confusing. A mod that developers include relies on other mods and libraries—sometimes so many that the developer can’t even list them all. So, this type of security starts with software composition analysis (SCA), then uses the list that generates to pursue vulnerabilities—normally by looking for the included libraries in a vulnerability database. Several prominent source code security solutions bundle at least the SCA part, and some also help nail down included vulnerabilities. Check with your vendor if you’re just getting started here.

    Container images are akin to the “golden images” of old. Build one that has what most applications need, add on the security that an organization wants most applications to support and then have every project start there and only add what this specific app needs. That allows for scanning of the base image so all applications start out at least somewhat secure. Cloud images can be done much the same, but beginning at a higher level. Look into registry security or image scanning tools to meet this need. It is worth asking your source scanning vendor if they offer this functionality; some do.

    The network on which an application will be exposed needs to be locked down. While the access points into the org probably are protected, portability of applications means that the application itself should be locked down wherever it uses that network. Tools are specific to the platform and networking in use, so look into it—I can’t offer much more generic advice.

    Security has long tried to lock down running applications—generally with pushback from developers and even ops, a bit. Between web application firewalls (WAFs) and API security, we have the ability to stop a whole host of attacks on their way in … But you have to use WAFs and API security best practices. If you’re starting from scratch, consider tools in the application and API security space that protect against both the web UI and API attacks with a breadth of technologies. For those with a WAF, look at API security tools that protect APIs. For those with API security covered, consider a next-generation WAF.

    My usual encouragement applies. You are rocking it, and all of these tools are increasingly integrated into the DevOps toolchain, so it’s worth the time investment to get them set up and let them run. If you’re just starting out, start with source code security. Honestly. It will make the overall app more secure by tightening its source. But don’t ignore the ops side, as that is part of the attack surface. Protect those apps you built and/or maintain that are keeping the org running.

  • DevSecOps Tools: Hot Air Ahead

    DevSecOps Tools: Hot Air Ahead

    I, like most of you, don’t like hardcore marketing that hinges its statements on “Well, that’s technically true…” I also am not a fan of talking heads that spew predictions about the future. Sure, they’re right sometimes; that’s because we have so many people pontificating that random distribution means some will be correct. I am bringing all this up to warn you that I (basically a high-tech talking head) am about to talk about tools, the future of tools markets (one in particular) and what I think should/will happen.

    Sometimes, talking about the future of a given tech is done to make a name for yourself. I don’t play that game. My goal is simply to say, ‘This is what I would like to see, and why I would like to see it.’

    Enough spewing—let’s talk about DevSecOps tools. I jotted down this topic a while back when I touched briefly on it, and my ideas firmed up while working on a recent project.

    Let’s start easy. If you are not using what we currently call DevSecOps tools in your DevOps toolchain, go get them set up. Go ahead, we’ll wait. It’s that much of a no-brainer that we’ll sit here while you choose, purchase and install your choice. Seriously. “Here is a tool that will make development more secure and make developers more productive.” Go install it now. Choose what functions you want to use and work them into your toolchain.

    But don’t get too married to your vendor. Because for the very same reasons I just told you to go install them, I will say I don’t think they should be a standalone market. Here is a toolset that plugs into the IDE on one end, and runs stand-alone, integrated with CI/CD on the other. It is DevOps in many ways. And while code scanning is inarguably a security function, the spirit of DevOps overall is “Who cares?” Using these tools shifts quite a bit of security functionality left and also warns about bad coding practices. Note I did not specifically say insecure coding practices, though those are covered. I said bad coding practices. The largest of these vendors will let you know things like, “Hey, you sent that variable to this function and then never used it. Are you sure?” or “This loop looks like it never exits. Are you sure?”

    It should be, and I predict will be, part of the DevOps process. In my dream world, the functionality would get split and some would end up in IDEs, while the rest would end up in testing tools or CI tools. But that’s not normally how markets get split up when there are established vendors. Even though you can feel the difference in the functionality (a bunch of them plug right into the IDE; the rest don’t), it won’t get split up because existing markets generally merge through acquisition. So we’ll have to see how things fall out, but I’m betting on CI/CD vendors or system-wide security vendors moving into this market. Indeed, companies with a SOC will likely find these vendors appealing because most of them also operate SOCs for the dynamic scanning part of the system.

    Still don’t have DevSecOps installed? Go now. Choose a vendor.

    Because I’m being so forceful about telling you to install one of these toolsets, I’ll state very clearly: At the time of this writing, I do not have any kind of relationship with any vendor in this space. I say this because I use the tools and strongly believe that the pain points they bring as a layer in development are very much made up for by the benefits they bring to the application.

    And keep rocking it. This will just make your systems more stable, and the merges (that I see as inevitable, but is actually only a possibility) you can worry about when they come along.

  • Decoding the Modern Enterprise Software Spaghetti

    Decoding the Modern Enterprise Software Spaghetti

    Modern enterprise software architecture is growing increasingly complex. Organizations are jumping on the digital transformation bandwagon in growing numbers. They are striving to become more agile and continuously deliver new code, whether on-premises or to support cloud migration efforts. In the process, IT teams are amassing an ever-growing inventory of applications and databases, which generally includes a blend of custom code, open source and commercial applications.

    “Spaghetti code” is what some call a tangled mess of a program—one that is difficult to follow, poorly documented and almost impossible for anyone but the original developer to troubleshoot or upgrade. Even today, when managers and developers take a more structured and disciplined approach to implementing code, the enterprise remains a patchwork of technology, a kind of spaghetti that can be difficult to understand and detangle.

    Given these layers of complexities, it is imperative for organizations to be equipped with the right processes and tools to map out their IT assets. They need to understand how programs and databases interconnect and how a change in one can have implications across the network that imperil availability, performance or security and negatively impact employees and customers. Here are some best practices that enterprises looking for an easier digital transformation journey can follow.

    Gleaning the Impact of Enterprise Software Changes

    Implementing a software change or embracing a new application that has a puzzling code makeup has plenty of inherent challenges—not to mention potential long-term disruptions for multiple departments, functions and processes within an enterprise. Whether an organization is dealing with inherited applications from a merger or acquisition or simple system migrations, much depends on how it is coded. As a result, enterprises must familiarize themselves with the overall layout of the enterprise architecture, down to the code level. This comprehensive level of analysis aids organizations in identifying the full scope and impact of the desired changes or updates.

    This is especially important for software teams who are operating on tight budgets and strict deadlines. Some important factors to consider in a comprehensive analysis include:

    • Identifying the impact of a change request on the software development project or on a business’s IT infrastructure.
    • Determining which software resources must be modified to implement the requested change.
    • Calculating the cost, time and effort needed to perform the change request.
    • Ensuring that the requested change complies with internal and external regulations.
    • Eliminating or minimizing any security risks associated with the change.

    Decoding the Spaghetti With Automated Discovery and Code Mapping

    A study by research firm Enterprise Management Associates (Next-Generation ITAM) found that the average IT organization uses 11 or more different inventory and discovery tools—some even more than 40. However, none deliver the full picture and they can often contradict each other. As a result, the average IT organization spends 15 hours every week manually resolving discrepancies among its various discovery tools. These hours translate to hefty costs.

    Fortunately, new approaches to discovery blend static and dynamic analysis methods that can operate in real-time to decompose software dependencies down to the code level. These new tools provide significant improvements in discovery and mapping, eliminating the need for multiple, redundant tool use and wasteful manual deconflicting.

    According to a recent Forrester survey, 56% of IT managers don’t have a complete view of dependencies between applications or between applications and infrastructure. However, today’s evolving business landscape dictates that technologies must evolve to keep up with an organization’s shifting needs. Software changes, when implemented strategically, can help businesses be more productive, efficient and profitable.

    To ensure that software changes serve this purpose, IT project managers need to implement a solid software change assessment system. With the help of technology, checklists and processes, organizations can outline a path that yields efficiency. They can understand and decode that tangled mess of software called the modern enterprise tech stack.

    — Soumik Sarker