For administrators of web security solutions, they know that claims of ‘any and all’ coverage is fraught with suspicion knowing there are always exceptions and the “devil is in the details”. In our previous blog, we addressed using a cloud API for managed apps and a proxy for app API traffic in secure web gateways for both managed and unmanaged apps, ending on the note vendors are likely to make the claim of ‘any app’ support for their solutions. The reality is apps are taking over URL filtering, and custom app API web traffic requires visibility and monitoring for granular policy controls in web security solutions.
Most organizations use over 1,200 apps on average, where more than 95% are unmanaged and in use by business units and users without IT administration rights. So, what are the ways a security vendor can claim they support ‘any app’ in their secure web gateway (SWG), cloud access security broker (CASB), or next-generation firewall (NGFW) solution?
First, is making the blatant claim in your presentation title, as done by one vendor at RSA in San Francisco and then beginning the presentation noting it is a lie and over exaggerates the solution’s capabilities. Minus one point for making the claim, however, plus one point for being honest it is not true.
Second, is providing basic ‘allow or deny’ app controls, which are coarse-grained and draconian at best. What if an employee has company and personal accounts for an unmanaged file sharing app noted in our earlier blog? Confidential data or malware can transfer between the two instances and simply ‘allow or deny’ control is not enough. Policy controls need to consider what user, device, app, instance, app risk, activity, and content at a minimum. To prevent cloud phishing, rogue account instances spoofing as company approved need to be blocked.
Third, is making the ‘any app’ marketing claim on vendor websites, event banners, and in sales collateral materials for prospects. The reality for these vendors is you have a tool that can learn any custom app API to create a template, however, there is no maintained library in the 1000s of these app API templates. So, the marketing claim is true, the solution just requires some assembly, monitoring, and regular maintenance by each customer. This sounds like adopting a new puppy dog and your current lack of adequate staffing, skill sets, and limited time does not allow it. But wait, what if we got lots of people involved using the tool, and that leads to the next concept.
Fourth, is launching an open community where customers can create their own custom app API templates and share them with other customers using the same vendor web security solution. This is the ‘internet as a sweat shop’ business model where you get other people to complete your work in the guise of being open and a good net citizen. Hey, it worked great for YouTube, why not security? The problem lies in maintaining the custom app API templates on a regular basis as app vendors update and change API formats, normally unannounced and during business hours (aka Murphy’s Law). Communities are great for static information contributions, however, not so good for dynamic app API formats.
Fifth, is addressing the problem with the required technology and resources for your customers. You are probably saying to yourself, “now that’s an innovative concept”. Run app discovery processes on a continuous basis to learn and prioritize apps for API templates. Today, Netskope covers approximately 36,000 apps in its Cloud Confidence IndexTM risk profiles. Next, develop an advanced custom app API proxy backed by a library of over a thousand app templates using both machine learning and humans to detect API updates and changes to publish timely updates for customers. Lastly, enable multiple deployment options for inline proxy app controls, including GRE and IPsec tunnels, forward proxy, reverse proxy, SSO/IAM integration, and traffic steering clients.
Again, recognize over 95% of apps are unmanaged with no IT administration rights or a cloud API for CASB API integration. Inline proxy controls within web gateways need to monitor unmanaged app API traffic just as effectively as URLs for web sites and this