devopsy.kinsta.cloud

Tag: WAF

  • We Will Control the World!

    We Will Control the World!

    One thing about centralizing control is that there always has to be someone in charge. That can be a very good thing or a very bad thing. In IT, it doesn’t even get far enough to be a terrible thing.

    Generative AI and increasing integrations have renewed the insistence from the crowd that it is certain they should control every little thing in your (virtual) data center. The idea that a given vendor should be the configuration and management point for a wide variety of tools – their own, competitors and nearby market tools – has been around forever. Vendors love the idea that they have that level of input into your infrastructure and, let’s be honest, many of us love the idea of having it taken care of for us.

    But there are several questions to ask here. First, what is the likelihood that vendor X will have a great level of support for the tools from other vendors in your infrastructure? I mean, before we even get into the idea that this desire for control is not at all altruistic (we’re not talking Stalin here, but we certainly aren’t talking Washington, either), there is the question of how AI will be able to learn about and configure/manage a competitor’s products. Watching wire traffic? Well, if the competitor’s systems are super-well-known and the format of configuration APIs/files are well known—maybe? But this leads us to the real problem.

    My advice to vendors would be to get their own products under control first. We work in a high-complexity field where the tools require a lot of specific domain knowledge to manage, and even more to manage well. Vendors have generally taken for granted that this level of knowledge would be available. Before making that level of knowledge unnecessary for competitors or spiderwebbing into competitor installs, make your tool(s) damn simple to use. That doesn’t mean you have to simplify it—you have the power of AI and are going to focus on configuration and management. So nearly eliminate configuration issues with your own products.

    Example: “Great Security Tool, I just added an API at https://devopsy.kinsta.cloud/rocks. Please lock it down so it is accessible only to users in the WeRule group, then generate a WAF rule to keep it from being used to access more than three records a day, and only allow GET and POST calls.” Most vendors across the industry aren’t even close to this level of simplicity, so why in the world would you trust them to configure/control other vendor’s products?

    There is a trend to make products cover more of the space they are in. This is very big in security right now, but you also see it in DevOps. CI/CD/CDD/VC/kitchen sink (KS)—I’m okay with that, as it does offer us simplified configuration and better cross-app communication. I think this is a better route than trying to serve as command-and-control for an entire tech stack that the vendor does not own. I still want point products and best-of-breed available, but a lot of us just don’t have the time and resources to implement five different products to get the job done—even if they’re “free,” as we all know, they are not free—so one vendor doing an entire chain is great for that use case, and often the shared information about the app, security, the network, etc. can work together better than the sum of its parts. So let’s stay in the “umbrella app” lane and not get carried away with trying to drive in the “manager of the entire world” lane.

    We’re busy, we’re tired and many of us are jaded. So don’t tell us how you can manage other vendors’ tools, tell us how you’re making it easier to manage yours. Thanks, from all of us in IT.

  • What the New OWASP Top 10 Changes Mean to Devs

    What the New OWASP Top 10 Changes Mean to Devs

    The open web application security project (OWASP) recently updated its top 10 list of the most critical security risks to web applications after four years. It represents the most radical shake-up since the list was introduced in 2003. The changes will undoubtedly have a big impact on how businesses address application security going forward and how developers and DevOps teams approach their jobs. This article will look at three of the most significant changes that have emerged in the new top 10 list.

    OWASP

    New Methodology for Current and Future Threats

    This time, OWASP took a more data-driven approach to their research to get better insight into current and future threats. Members provided more than 1.5 million data points on the security threats they see. OWASP categorized the data and assigned an impact score before deriving their overall ranking.

    OWASP also included survey data from security professionals about emerging threats. For example, the current incident rate of server-side request forgery (SSRF) vulnerabilities is low, but security professionals consider this attack very serious and expect it to increase significantly in the future. SSRF enables attackers to use vulnerable servers to request and receive data from protected internal sources, which is a very serious risk. So, SSRF became a new category (A10:2021) this year.

    With this new methodology, OWASP is now able to offer comprehensive insight into the most serious current and future threats.

    OWASP 10 Expands Security to the Left

    One key change in the new top 10 list is the inclusion of many categories (e.g, Insecure Design—A04:2021, Software and Data Integrity Failures—A08:2021) that recognize the industry has to start with better application design practices to improve security.

    Many application vulnerabilities creep into software because secure design principles are not followed from the outset. In the race for faster app development, corners are being cut. The CI/CD approach to application development is a major contributor to the use of plugins, libraries or software modules of dubious integrity. This problem is getting worse. Businesses must ensure that all their software components are from reputable sources and should use software supply chain tools to check for known vulnerabilities.

    Major Ranking Changes due to the Evolving Threat Landscape

    Injection attacks, which have been ranked as the number-one risk since 2003, are now ranked number three. While this is welcome news, we cannot claim victory just yet. Your valuable data is still very much at risk from vulnerable apps that allow bad actors to run unauthorized commands and access the sensitive corporate information your business depends on.

    Injection attacks have been replaced by broken access control (A01:2021). OWASP reported that in their data set 94% of applications were tested for these vulnerability types and 3.8% showed one or more weaknesses. A staggering amount!

    Due to the increased adoption of standardized authentication frameworks which are more readily available and easier to implement, identity and authentication failures (A07:2021) have plummeted in the ranking from number two to number seven as a risk.

    This shift demonstrates that as businesses have improved their determination of who can access applications, they have neglected to enforce controls over what an individual user, process or device can do in that application. It is crucial to consider authentication and authorization together for a better security posture.

    Lots of Work Ahead to Bring Left and Right Security Together

    The 2021 OWASP top 10 list is a big step forward. OWASP’s expansion of security to the left with the inclusion of new categories and significant changes to their rankings will require businesses to revaluate their application security posture. Addressing security earlier in the application development life cycle will likely prevent many of the more common attacks, but businesses must complement this with robust, proven and scalable security protections on the ‘right’ like web application firewalls. It is not just about shift left, it is about expand left. You need both left and right security for a better multilayered security posture.

  • Debunking Myths Around RASP

    Debunking Myths Around RASP

    Runtime application self-protection (RASP) has taken a fair bit of scrutiny over the last few years. Like many security technologies that pioneer new ways of tackling old problems, people inherently don’t like change. Several companies entered the space early and early adopters helped mature various RASP solutions on the market and the technology has advanced rapidly.

    When applications began to be the favored target of bad guys, tons of companies started to reposition their perimeter security products closer to the application. Web application firewalls (WAFs) are similar to IPS for the network, so easy mind shift for most security practitioners. The problem is they require you to know your adversary. That’s like asking a security guard to keep out a single troublemaker, while letting in their associated gang of thugs.

    As we saw recently with WebLogic, exploiting applications is a shell game. When one vulnerability is exposed and patched, another one, which shares the same modus operandi, comes out. When reports came out comparing the most recent WebLogic vulnerability to vulnerabilities found last year in CVE-2018-2628, CVE-2018-2893 and CVE-2017-10271, Oracle posted a blog explaining last year’s vulnerabilities had been patched. The problem was the underlying code mechanism that led to the above-mentioned CVEs (insecure deserialization) had not been fixed.

    Deserialization is a perfect illustration of why RASP is the Chuck Norris of application security. Instead of applying a patch (which in the case of Oracle’s WebLogic, blacklisting the exploit method via a patch), RASP looks at the totality of the code before it executes and says, “If it looks like a duck and quacks like a duck, apply a roundhouse kick to the entire enumeration.”

    It’s important for enterprises to protect their customers from insecure deserialization with RASP products. Further, it’s critical to consider learning and debunking some of the common misconceptions in the overall perception of runtime security:

    Performance Impact

    Evaluate an agent-based solution, which often makes app owners concerned it’ll impact the performance of their applications. When evaluating RASP providers, especially agent-based solutions, ask for agent size, performance benchmarks and certainly conduct your own performance testing during evaluation.

    Writing Secure Code

    With the DevOps movement, companies have ramped investments in training and programs around secure development practices. And while security is shifting left with this movement, programming still has a little bit of art infused, especially when developing applications that have been around for a long time and have seen variations in development resources. As is the case with WebLogic, application developers should create apps with security in mind, but they don’t have a crystal ball and exploits evolve just as applications do.

    My Developers Will Become Lazy

    Somewhere in these early days of RASP, the notion came about that RASP means you no longer need to remediate vulnerabilities in your application source code. Notably, the root cause of all vulnerabilities should be fixed as soon as possible. However, RASP can also function as an insurance policy allowing DevOps teams to better plan fixes and prevent derailing other projects focused on the business.

    Why Do We Need RASP If We Have a WAF?

    The WAF has become ubiquitous in most organizations and it is certainly valuable for organizations looking to take a defense-in-depth strategy. WAFs have become a significant strain on resources as they produce unmanageable amounts of false-positives that require constant tuning. In a recent survey by Ponemon, it takes most organizations 45 hours a week to address alerts and 16 hours per week creating or updating rule sets.

    Hopefully, this article illustrates more color to today’s RASP. We’ve seen a lot of advancements in the early days of this technology and hopefully that will mean a lot less headlines.

    — John Adams

  • Functional Programming: Island of Misfit Functional Programming

    Functional Programming: Island of Misfit Functional Programming

    The age of functional programming is dawning. The hype cycle has heated up, and IT departments are getting both real and perceived benefits out of the idea that a function runs on demand only.

    For some, the benefits are very real. Bursty processing, or things that are frequent and quickly resolved, see a benefit from being implemented on functional architectures, and the cost of functional architectures is arguably far better than the cost of cloud instances. I say “arguably” because you can always cram more onto an underused cloud instance, but you pay as you go—even more literally for functional programming, so additions each have an incremental cost. But it is incremental, and you have the power to choose whether functional is right for any given bit of the architecture.

    So why the title? Remember The Island of Misfit Toys from the much-beloved Christmas story, “Rudolph the Red Nosed Reindeer”? They were all just a little off. In a world flooded with perfectly good toys, they were left unattended and unwanted.

    That is a risk functional runs in the long run, also. The idea that you can pop a function out there, configure the access point (almost ubiquitously a web application firewall entry point, but things change so we’ll stick with the generic “entry point”), and start sending requests is great. The fact that you only pay for that bit of time when your request is actually being serviced is great, too.

    But this ideas assumes security is baked in at the functional level. If you are deploying this function anywhere with a public IP, it assumes hardcore security is baked in.

    And failure to have that security baked in is the first reason you might have a misfit toy.

    By definition, functional programming-based systems are complex systems. They are the ultimate evolution of microservices. They will suffer all of the headaches and heartaches associated with SOA and add on the issues with REST versioning, etc. There will be 50 or 500 functions, each clipping along and doing its thing, composed to make a single application (in a purist world, composed in a functional programming app).

    Some of these functions will become outdated and unused. You can’t leave them laying around, waiting to be abused. Indeed, a new form of financial attack might be to look for just such abandoned toys and start calling them repeatedly and rapidly.

    Imagine coming in one day and having Finance ask you why your bill at functional provider X tripled in the last month, only to find a function you left hanging around was being called for no good reason?

    But the complexity inherent in lots of small bits of code, each doing a specific task, pretty much guarantees there will be cruft left lying around unless you are very careful.

    And that, my friends, is (finally, I know) the point of this blog. Our monitoring tools today lean toward watching the performance of the application, but you need more than that before you go all-in on functional programming. You need build tools that can tell you when a given function is no longer called—from anywhere. That is a tall order which none of the previous distributed methodologies has managed to master, but it is more important in a world where you have functions sitting in various public clouds with public-facing IP addresses.

    There also needs to be a definitive source code scanner. Those are slowly getting better, but imagine if a library the build system pulls in and uses for 20 or 30 different functional programming microbits becomes compromised? We’ve seen enough instances of ignoring the problem is begging to be a victim, so scanning on build is more important with more systems using external libraries. Or more accurately, with external libraries being pulled into more microservices. There are companies/service providers that will validate your external dependencies and only let you load open source libraries they have certified as safe. I’ve never used one, but they’re worth looking into.

    A list of entry points and places they are accessed from is useful for internal-only applications. You can’t do that with a publicly exposed REST API that anyone can call, of course. I’m a developer and a D&D player, so I’ll use that example: Wizards/Hasbro cannot control where this API is being called from. The same is true for any web services APIs that exist to give others access. But internal APIs that are an integral part of internal systems and not called externally? Those you need an automated way to find references to them in internal source and keep a count. Much like garbage collection, you’ll want to take down ones whose count reaches zero.

    The thing is that in many ways functional programming reduces operational complexity. It certainly reduces operational overhead. But that complexity is replaced with a different kind of operational complexity; maintenance becomes a bigger issue, and the already occurring breakup of code into smaller chunks increases, bringing cross-reference complexity along with it.

    Keep that in mind. You will have orphaned functions, you will have security concerns, you will have changed operational complexity. Plan for these things from day one. They are not at all deal breakers, and the benefits of functional are already clear in certain verticals with more general benefits being discovered as I type. But they’re the new problems that will require answers in this new architecture.

    So, build in oversight and tools from the beginning and go see how functional programming could benefit your project. At this time, it isn’t the answer to every problem, but—like most cool new IT things—it is another tool to have at hand when solving problems for the business.

    And don’t let your functional programming microservices end up on the Island of Misfit Functional Programming.

    — Don Macvittie

  • It’s Time to Break Up with Your WAF

    It’s Time to Break Up with Your WAF

    If the only reason you have a web application firewall (WAF) is for compliance, you deserve better. It’s time to replace it with something that provides not only compliance, but real security value as well.

    In the land of web application security, there are a few not-so-well-kept secrets, arguably none bigger than this: The WAF survived not by being excellent, but by being mandated.

    The WAF is an antiquated technology that was created to help stem the rise of application security vulnerabilities, which had been overwhelming organizations with their frequency of discovery. Static and dynamic analysis tools dumped huge quantities of bugs onto development teams that had no possible way to fix so many code issues.

    Meant as a stop gap measure to address this problem, the WAF made it possible to filter out rampant SQLi, command execution and XSS attacks that were threatening to consume all of the development and security team’s available resources. The idea behind the WAF was that the application bugs and security flaws would be triaged for now, and then eventually fixed in the code at the root of the problem.

    At the time, a drop-in web application security filter seemed like a good idea. Sure, it sometimes led to blocking legitimate traffic, but such is life. It provided at least some level of protection at the application layer—a place where compliance regimes were desperate for solutions. Then PCI (Payment Card Industry) regulations got involved, and the whole landscape changed.

    PCI requirement 6.6 states that you have to either have a WAF in place or do a thorough code review on every change to the application. Given the unappealing nature of the second option, most organizations read this as a mandate to get a WAF. In other words, people weren’t installing WAFs due to their security value—they just wanted to pass their mandatory PCI certification. It’s fair to say that PCI singlehandedly grew the WAF market from an interesting idea to the behemoth that it is today.

    And the WAF continues to hang around, an outdated technology propped up by legalese rather than actual utility, providing a false sense of security without doing much to ensure it. If that isn’t enough for you to show your WAF the door, here are four more reasons why WAFs should be replaced.

    The Minimum WAF Rules Approach is Broken

    A common side effect of a WAF implementation is the blocking of legitimate traffic. In the application security business, we call these false positives. Don’t be fooled by this innocuous phrasing—what it means is that customers aren’t able to buy things they want, or upload their latest vacation photos or generally use the functionality of your applications. It’s the kind of experience that can quickly turn current customers into former customers.

    To combat WAF false positives, most companies run the bare minimum number of rules to get by. This means that only the most obvious and most egregious attacks are caught, while everything else just sails right past the filter. Simple rules mean easy-to-bypass rules, leaving you with an ineffective WAF.

    Learning Mode is Broken at Speed

    One way that WAFs try to cut down on false positives and avoid breaking valid traffic is through a “learning mode.” In learning mode, the WAF learns what normal traffic looks like versus what malicious traffic looks like and protects accordingly. A lot can be said about how tough it is to get learning mode right, even under perfect conditions, but let’s skip to the real problem we see in production environments.

    Learning mode takes time. WAFs that need to learn to recognize “normal behavior” require a certain amount of traffic review before they can actively block everything else. It may take a few hours to learn safe application traffic patterns.

    When you move from waterfall to agile and DevOps, deployment speed gets faster and faster. The application code changes weekly, daily or even hourly. If you deploy using anything close to a modern cadence, putting the WAF in learning mode on every code change means you are always in learning mode. Essentially, any kind of learning mode, when applied to modern application development techniques, just can’t keep up with the pace of production.

    Monitoring Mode Really Isn’t Compliance

    The fact that WAFs have survived due to legal mandates rather than effectiveness isn’t the only open secret in the business. You also won’t be shocked to hear that most companies never put their WAF into active blocking mode. After all, blocking mode has high false positive rates and breaks your legitimate traffic, so it’s the way to go only if you’re hoping to break your application.

    Instead, the WAF is run in monitoring mode, where it watches traffic and logs any event as an attack. When it’s time for audit, the WAF gets flipped on for a short bit, then back off again. In reality, of course, some auditors don’t even care if you have it in active blocking mode. Just having a WAF in place is good enough for them.

    Running your WAF in monitoring mode is not an effective control. All it does is add a false sense of security and additional overhead to the security team to evaluate logged events. In this scenario, you’re spending money where it doesn’t need to be spent while adding close to zero defensive measures.

    CDN-based WAFs Were for Convenience, not Effectiveness

    The last not-so-fun thing about WAFs is their daily care and feeding. Your WAF adds complexity to your network, and having to dynamically scale it in the cloud is not exactly easy. Enter the content delivery network (CDN). Since most shops are already using a CDN to offload web application woes, why not add a WAF at the CDN layer? This meets compliance (yay!) and we don’t have to manage it (double yay!).

    For many enterprises, this idea is the win-win that has allowed the WAF to persist even as its usefulness has been questioned. The problem with the CDN-based WAF, though, is that you end up running the WAF with a minimum set of rules again (see above or here), leaving the door open to all kinds of attacks. In fact, in my work at Signal Sciences, many customers use our web protection platform behind their CDN-based WAF and discover tons of real attacks that happily made it through the CDN.

    If compliance is your main goal, go ahead and use a CDN-based WAF. If you want real defense, look elsewhere.

    Achieve Compliance and Real Security at Speed

    If this article sounds a little too familiar—if all you’re getting from your WAF is compliance—then it’s time to replace it. There are new options for adding defense at the web application layer and achieving compliance at the same time—for example, using runtime application self-protection (RASP) or next-gen WAF to provide application-aware defensive coverage. This means that, instead of just checking a box for PCI, you can be actively defending against the OWASP Top 10, account takeovers, instrument business logic and fight off bots, all without interfering with legitimate customer activity.

    Don’t settle for compliance alone. You can achieve both compliance and real protection—and that’s what your business and your customers deserve.

    — James Wickett