devopsy.kinsta.cloud

Tag: IAST

  • Security Across the SDLC

    Security Across the SDLC

    We’ve seen some interesting movements in the security space over the last couple of years. My focus is on application security, but one of the movements we’ve seen is the blurring of what is application and what is infrastructure security, so I do a fair amount of that also. And then, with the advent of WAAP, we have network security playing a role in AppSec… It’s a growing snowball.

    I will start with the mandatory happy declaration that DevOps no longer treats security as an annoyance. While we’re well past that, I think the shock of the whole “security is a problem, not protection” mentality that DevOps started with is still hanging with us, and some still actively believe that. But at this point, we’re well on the “Security is part of the process” trail we should be on.

    If you look at the top-level changes, static application security testing (SAST) vendors have grown to be development security, covering SAST, DAST, IAST, RASP and even a bit of data security. Meanwhile, load balancers and WAF slowly evolved into full-on web applications and API security that covers the production side with active protections for things like DDoS and DLP.

    Likewise, we’ve seen this with the growth of cloud workload protection and how the entire digital architecture is being pulled into CSPM.

    I’ve said it before – we’re in a consolidation phase. It looks like it will go even further than I thought, though. Now, we are starting to see an interesting development: WAAP vendors are starting to include some or all of DAST, SAST and RASP. Arguably, they always did some IAST because their focus was on runtime protection, but their emphasis is more on protection than test, so it will be interesting to see that bit expand also.

    And all of this includes an inconvenient fact. We don’t have any more people to do security than we ever did; in fact, we have less. That’s part of the reason that we haven’t shoved security everywhere – there aren’t people to do it. In true DevOps fashion, we have distributed the work across other teams – Dev is right there where code security and API security start, so we’ve implemented SAST and DAST bits right into the IDE, for example. Or Ops has always done some amount of security, and we’ve just upped the amount. But they don’t magically have more time, either. I’m sure you are feeling it if you are a practitioner; almost all of us are. AI promises to help with that, and in security, it will likely deliver. Another thing I’ve pointed out before is that security is one space that really does stand to gain from generative AI – in helping make more secure code, in helping make all the permutations of tests, in making rules based upon observed data and more. The time-saving benefits will deliver, in my opinion. But it’s still a lot of work, and some of it is straight-up additional work because we weren’t doing things like container security a few years ago.

    In the short term, if full SDLC security is applied, there will be more work. In the long term, the mega platform for security may well reduce this work as it limits notifications across tools. Maybe we should name the coming mega platform SecArch. Also in the long term, AI will help alleviate some of the load. Until then, buckle in. You’re not likely to get staff to cover new work. But it will be worth it. Just keep plugging along, and know when to say you just can’t add one more thing to the pile.

  • The Security Pipeline

    The Security Pipeline

    Over the last few years, the ability to secure our applications has grown, and deep integration into the DevOps toolchain has, too. There are more tools doing more security checks protecting more of the infrastructure and source than there have ever been. The key is putting them to use intelligently.

    We now have the ability to secure the image an app is based upon, the images that are derived from that original—complete with supporting software. We can get feeds to tell us which bits of our included open source components are insecure and how to protect them; we can scan the source, the assembled application, the APIs and the network. We can put runtime protections in place in front of web apps and in front of APIs. We can even track the long-tail attacks like slow data extraction that are becoming more common as security tools master more obvious attacks.

    That is a great set of security capabilities. And automation puts every bit of it within reach. Your job is to pick the bits you need to increase the security posture of your environment and get them worked into your specific toolchain. This is not all that difficult, but nothing is free, so you will need at least some implementation time and some staff time to work through results. After all, no matter how automated, current solutions do end with a list of changes that need to be made to increase security. Some tools will put a runtime fix in place immediately, but honestly, that is a patch—it only stays in place until you can fix the underlying issue.

    Integrating all of the great security tooling with each other is another aspect that will require some time. Some vendors cover a massive amount of the security testing needed across markets and technologies. These companies show us that even if an organization would rather use best-of-breed, there is a lot of benefit in increasing integrations. For an easy example, consider this: If the software bill of materials (SBOM) generated during the build steps shows that a given framework is included in an application, then active testing via dynamic or interactive application security testing can include extra tests specific to that library.

    Integrations will take effort, but once they’re in place they will enhance application security. There is no perfectly secure application, but the tooling is available to make a given environment less of a target because it is too much work to attack. And that is what you should be shooting for.

    I’ve said before that making security part and parcel of your DevOps practices is mandatory at this point, but that was in reference to the great DevSecOps toolsets currently out there. I’m suggesting now that we include it all–from design to GitOps runtime drift management. Because we can, and the result is reduced risk to the organization.

    And keep rocking it. Honestly, you’re maintaining something worth protecting–that alone means you are successful, even if you aren’t aware of every issue that crops up. Issues are why you’re there, and the systems keep running because you are.

  • Turning Off DevSecOps Noise for Functional Fidelity

    Turning Off DevSecOps Noise for Functional Fidelity

    Analyzing the DevOps and DevSecOps software marketplace demonstrates the high demand for tools and platforms that reduce false positives. As businesses and organizations adopt a rigorous, disciplined software development life cycle and ascribe to strict compliance frameworks, they quickly realize that automated tools can generate a substantial amount of noise, in the form of false positives, that pollute their efforts to maintain a lean and focused operation.

    True Positive Vs. False Positive Vulnerabilities

    Static application security testing (SAST) is fundamentally about using pattern recognition to identify vulnerabilities in code. The more aggressive the scan rules, the more likely a snippet of code will be flagged as a vulnerability; in other words, a “true positive” finding. Automated scanning is fundamental to effective DevSecOps. But if the scanning is too aggressive, it may generate findings that aren’t actual problems; in other words, false positive findings 

    You want your scan to return true positive findings—actual vulnerabilities that can be fixed and remediated. A false positive is a finding that isn’t actually a vulnerability. The ideal tool catches all the true positive vulnerabilities and returns a minimal number of false positives.

    Many platforms give their users granular control over which rules run and are applied to their code. This first layer of control is similar to allowing your team to tune their scans to focus only on certain frequencies while ignoring others. Often, this is used to increase the speed with which a platform might complete a scan. It can also be used to tune out “noisy” rules. It’s perfectly legitimate to use controls like these, but it’s important to recognize that those completed scans aren’t comprehensive.

    Speeding Up Can Slow You Down

    Positive findings, whether they are true or false, take more time and resources to evaluate and remediate. Investing resources to remediate true positives is worthwhile. It would be ideal if they had been caught earlier in the process, but catching a vulnerability before it hits production is the entire reason you are doing DevSecOps in the first place! False positives may not require actual remediation, but reviewing them and then manually confirming their false nature is directly counterproductive to the reasons an organization adopted automated SAST in the first place.

    SAST Plus DAST Keeps You Ahead

    The gold standard for effective security testing is to pair SAST with dynamic application security testing (DAST), sometimes also called interactive application security testing (IAST). This process will correlate the positive findings from the SAST scans and test them using simulated data in an emulated runtime environment. 

    DAST/IAST actually tests each bit of code that looks problematic because of a particular pattern and then tests whether the code is actually vulnerable. DAST provides an automated, testable, repeatable and provable method to test those positive findings for trueness and falseness. If you are only doing SAST scanning, then the noise-to-signal ratio from your platform is governed strictly by the intelligence embedded into their pattern-matching code. Depending on the quality of the tool being used, your actual mileage may vary.

    DevSecOps Is the Right Path

    Businesses and organizations clearly understand the problem of potential vulnerabilities. Guarding against a security breach is critically important to protecting proprietary information and the privacy of their customers. DevSecOps is clearly the right path to take to reach that goal. However, it is critically important that the vehicle(s) these teams use to get there (in this case, SAST and DAST/IAST) have built-in functionality to focus their efforts on real problems and not waste it on phantom issues.

  • Quick! Define DevSecOps: Let’s Call it Development Security

    Quick! Define DevSecOps: Let’s Call it Development Security

    For a good long while, DevSecOps referred specifically to vendors like Veracode that did static application security scanning, dynamic application security scanning, software composition analysis and some form of runtime monitoring (usually interactive scanning). Then we realized that DevSecOps was potentially a lot more than that and, like DevOps, we drove the word to encompass all things that shift security left.

    That’s where we are now. But that leaves the DevSecOps market confusing to a lot of people. I propose we rename the tools that specifically focus on code quality to Development Security—even though that name is not perfect and all-encompassing. It’s a better fit than terms in other spaces, like Password Management, which includes two-factor authentication (2FA), multifactor authentication (MFA) and, increasingly, passwordless and secrets management, none of which actually use passwords for the focus of their functionality.

    This way, we can all understand that DevSecOps is the mindset and methodology and Development Security is one piece of implementing DevSecOps.

    There are probably people smarter than I am who have come to this (or alternate) conclusions, and I’m happy to run with their solutions, too—this is just an attempt to make it less confusing for those who don’t live and breathe the security and DevOps markets. If a new person says, “I think we need DevSecOps,” they are in for a journey to actually figure out what they meant and if what they need is actually DevSecOps. We should strive to clarify that so, at the beginning of their research, it is clear that DevSecOps is like DevOps—an overarching term for policies, procedures, mindset and products while the tools that can help with DevSecOps, like those that make up the overarching DevOps toolchain, belong to a market segment named X. In my case, I proposed Development Security because it’s a close fit. What we actually call it is irrelevant, as long as new people understand it is a subset of DevSecOps.

    While you continue to keep the systems spinning and the organization online, when you research these products, use phrases like, “I’m looking for Development Security tools that fit with a DevOps environment.” Markets are largely named by vendors and pundits but, in the end, all these people want to talk in terms their customer base recognizes. So, if enough of you ask for Development Security, that’s what they’ll all start calling it. Effective immediately, that’s what I’m calling it. It is a distinctive set of functionality that all orgs who do internal development need, so let’s give it a distinctive name. And yeah, drop me a line if you have a better name. I’m tied to making it easier, not to a specific term.

  • DevSecOps Implementation: Interactive Testing

    DevSecOps Implementation: Interactive Testing

    This is the fourth installment in this series on DevSecOps. Read the first installment, on static analysis, here the second installment, on source composition analysis, here, and the third installment, on dynamic scans, here.

    Dynamic testing looks at the running application, poking and prodding to see how it reacts to known vulnerabilities. A complete dynamic scan watches a test runner as it runs against the application and tries all points of entry it can find, normally a highly automated process that takes a while.

    Where dynamic scans fall short is in pinpointing the problem within the application. Knowing that things went wrong when a given CVE was exercised against the app is one thing, but knowing what went wrong and where it went wrong is much more useful to make development teams productive. This is where interactive application security testing (IAST) tries to lend a hand. Using tooling in the application, interactive scans can offer the exact module/source file/shared library (etc) that caused the error.

    Generally speaking, interactive tests are best run at a targeted subset of an application, finding details needed to resolve issues the organization is already aware (or suspect) exist. In our test environment, we use interactive scans to zero in on issues that were detected by static and/or dynamic scans.

    It is likely that the interactive testing market will be the one to continue to move down the line to full-on security monitoring and/or it will encompass a growing list of environmental issues—it is, after all, designed for a running application to get exercised and find the issues. It is not a stretch to see these tools move in the above directions, and indeed you can see the beginnings of these moves in different vendors.

    But for today, the things-you-want-to-look-for list is here. My usual disclaimer applies … Through my (and others’) work for ASG, we’ve turned up a lot of information about DevSecOps tools and what to look for. We don’t have room in these blogs to delve into the depths of that research, but I’m offering an abbreviated hit-list of things to look for when moving toward this type of product. There is a lot to look for, and please be aware that this list is just to get your journey jump-started.

    • Language/framework support: It doesn’t need to be as tightly integrated as language-dependent static scans, but the tool still needs to support your specific development efforts. Support for Ruby/RoR, for example, is important if that is your dev platform of choice.
    • Source of vulnerabilities: Like other security tools, understand what interactive testing tools cover and how it is covered. Currently, most of these tools count on an external test running tool to actually run the test, while the dynamic scan watches what is happening inside the application.
    • Toolchain integration and support: Can the tool be called from your build/test toolset? Does it have integrations to feed results back into your build/bug-tracking systems? While these tools offer good interfaces to see what is going on, the explosion in tools that DevOps brought is making us dashboard-weary. Make certain your centralized code quality information store can be used as the single pane (or pain, depending upon implementation) of glass for initiating scans and reporting results.
    • Test tool support: As mentioned above, most of these tools are watchers that rely on another source to run tests. Make certain that there is some manner of coordination between these two so the test runner can be kicked off from the dynamic scan or vice-versa. More manual steps aren’t needed here and just slow the process.
    • False-positive rate: Interactive testing still struggles with false positives, though these tools are getting better. Have an understanding about average false-positive rates of the product in question, then ask about customization options to reduce this number in your given environment without reducing security posture.
    • Cost to configure/maintain: As is probably obvious, tooling an application to look inside of it is a step beyond normal production needs. Make certain the overhead of adding interactive testing to a project and the cost of integrating are worth the results to be had.

    Vendors call it “interactive” because it watches the interaction of the pieces of code inside the app as it’s running. Many customers call it “interactive” because the “tool” used to run apps for testing ends up being people “interacting” with the application. Both are somewhat accurate, though automation is coming apace, as it is for everything software testing.

    Choose a product that has enough automation today to suit your organization’s needs, and is progressing to wow you. Of all the security tools out there right now, interactive holds the greatest promise for wowing us. Since it is happening at runtime and can see inside the application, everything from environment to installed applications on the host could be covered, and that’s where some vendors are headed. An integrated environment security test tool with deep knowledge/reporting that includes knowledge gained from static scans and source code analysis is on the horizon—and, given the direction of all of DevOps, making that solution fully automated and reporting back to build systems is coming also.

    Interactive won’t replace the other steps in DevSecOps, but it will replace some of their functionality—or more often enhance some of their functionality. If a static scan notes a potential vulnerability, dynamic could verify if it is a real vulnerability before a human ever sees a report on the issue, for example.

    I’ll end this as I’ve ended the others: You all are kicking rear and taking names in a tough IT environment that exploded into near-100% remote for most of you. Keep kicking rear and don’t forget security. It is more important as your organization becomes geographically dispersed because now applications that were “secure enough” for the internal network are shared publicly. Even with infrastructure protections such as VPN in place, more caution should be applied to those applications simply because they are more exposed than “must be on our LAN” allowed for.

    Most users forget that in the end, someone is running those servers and keeping things working. So from me, for all those who’ve never seen the inside of IT, thank you. And keep rocking it.