Signal Sciences for Azure App Services

We are excited to announce today that Signal Sciences can now be deployed on Azure App Services with an easy-to-use Azure site extension.  Already available for all customers, the Signal Sciences Azure site extension makes adding next-generation WAF protection to Azure App Services web apps quick and painless.

For those less familiar with Microsoft’s Azure and its set of services, Azure App Services is a PaaS (Platform as a Service) that provides multiple ways to deploy web applications and APIs to the Azure cloud – without requiring users to manage and/or patch the underlying infrastructure hosting the application or API.

PaaS offerings like Azure App Services are being widely adopted in organizations of all sizes for its clear security and cost benefits, such as not having to continuously ensure OSes are up to date on patches and whether the host is sufficiently hardened and free of vulnerabilities. Instead, the PaaS vendor manages those concerns. Azure App Services specifically has grown to be a popular choice with many of Signal Sciences’ larger customers who have historically developed on Microsoft’s stack and are looking for a simple way to move their ASP, .NET, .NETCore and other applications to the cloud.

At Signal Sciences, we strive to make our next generation WAF protection available on any application, no matter which platform it runs on. Signal Sciences’ flexible agent + module architecture is what makes this possible. Typically, when it comes to supporting a new application hosting platform, it’s only a matter of creating a new module or updating an existing one; however, Azure App Services presented Signal Sciences’ engineering team with a unique challenge.

For security reasons, Azure App Services imposes strict network restrictions to prevent processes from communicating with the localhost. In a Windows environment, the Signal Sciences agent requires a local TCP connection to communicate with the Signal Sciences module (usually installed on IIS or as a library in the web application code; on Linux, RPC is used for agent/module comms instead). The module intercepts and passes incoming web requests to the agent, which determines whether the request is malicious or not and then informs the module to block or allow the request to proceed.

With the security sandboxing in place in Azure App Services, a standard Signal Sciences agent and module installation would not work – there is no way for the agent and module to communicate! Through some clever engineering work, the Signal Sciences’ agent and module development team were able to overcome this challenge with a Signal Sciences Azure site extension.

Azure diagram

Site extensions in Azure add additional functionality to web apps hosted in Azure.  Adding a site extension to a web app is an easy process performed through the Azure portal with just one or two clicks.  With the Signal Sciences site extension, next-generation WAF protection can be added to Azure App Service web apps with that same simple process.  The site extension downloads and installs the Signal Sciences agent and IIS module to the application environment.  By controlling the starting and stopping of the agent from the IIS module running in the IIS process, the IIS module is able to communicate with the agent child process, thus overcoming the network restrictions that would otherwise prevent a standard agent and module installation from functioning.

Because the Signal Sciences Azure site extension is based on the IIS module, as opposed to a language-specific module or agent, Signal Science’s protection of Azure App Services web applications extends beyond just .NET and .NETCore applications.  Any web app run on IIS in Azure App Services can be protected with the Signal Sciences site extension, including .NET, .NETCore, Java, PHP, Python, and Node.JS applications.

In pilot testing the Signal Sciences Azure App Service site extension with Signal Sciences customers, users were impressed with the ease of installation as well as how deploying a WAF on the application simplified their overall networking architecture. A WAF in Azure is usually deployed as a gateway or service layer, requiring architecture considerations which can create delays in rolling out critical application layer protection. But because Signal Sciences WAF protection is deployed on the application itself with a site extension, there are no networking architecture considerations, which can also simplify networking troubleshooting as there’s one less component (WAF in this case) to worry about. Furthermore, the ease in deploying the site extension means application development teams will be more quick to adopt the protection and visibility provided by Signal Sciences.

Ready to learn more about how Signal Sciences can help you protect your Azure and other web applications?  Please contact us for a demo today!

The post Signal Sciences for Azure App Services appeared first on Signal Sciences.

*** This is a Security Bloggers Network syndicated blog from Signal Sciences authored by Alfred Chung. Read the original post at: