main

Application Security

Automation for NetOps and DevOps

August 14, 2019 — by Prakash Sinha0

automation1-960x446.jpeg

Many organizations use public cloud service providers, some in addition to their private cloud and on premise deployments. The right product mix not only reduces vendor lock-in and shadow IT, but is also an enabler for the constituents that includes IT administrators, network and security operations, as well as DevOps.

Maintaining application security and configurations across multiple environments is complex AND error prone and increases the attack surface. Careful testing is required to protect business-critical applications from hacking attempts, which may include denial of service, network and application attacks, malware and bots and impersonation.

A successful implementation will not only include the right cloud provider, the correct security, licensing and cost model, but also the appropriate automation tools to help secure the technology and security landscape consistently as applications are rolled out in a continuous integration and continuous delivery (CI/CD) process.

When Does Automation Become a Pressing Issue?

The reasons to automate may be due to resource constraints, configuration management, compliance or monitoring. For example, an organization may have very few people managing a large set of configurations, or the required skill set spans networking AND security products, or perhaps the network operation team does not have the operational knowledge of all the devices they are managing.

Below are a few benefits that automation provides:

  • Time savings and fewer errors for repetitive tasks
  • Cost reduction for complex tasks that require specialized skills
  • Ability to react quickly to events, for example,
    • Automatically commission new services at 80% utilization and decommission at 20%
    • Automatically adjust security policies to optimally address peace-time and attack traffic

[You may also like: How to Move Security Up the DevOps Priority List]

Automate the Complexity Away?

Let us consider a scenario where a development engineer has an application ready and needs to test application scalability, business continuity and security using a load balancer, prior to rolling out through the IT.

The developer may not have the time to wait for a long provisioning timeline, or the expertise and familiarity with the networking and security configurations. The traditional way would be to open a ticket, have an administrator reach out, understand the use case and then create a custom load balancer for the developer to test. This is certainly expensive to do, and it hinders CI/CD processes.

[You may also like: Economics of Load Balancing When Transitioning to the Cloud]

The objective here would be enable self-service, in a way that the developer can relate to and work with to test against the load balancer without networking and security intricacies coming in the way. A common way is by creating a workflow that automates tasks using templates, and if the workflow spans multiple systems, then hides the complexity from the developer by orchestrating them.

The successful end-to-end automation consists of several incremental steps that build upon each other. For example, identify all use cases that administrators take that are prone to introducing errors in configuration. Then make them scripted – say, using CLI or python scripts. Now you’re at a point where you’re ready to automate.

You’ll have to pick automation and orchestration tools that’ll help you simplify the tasks, remove the complexity and make it consumable to your audience. Most vendors provide integrations for commonly used automation and orchestration systems – Ansible, Chef, Puppet, Cisco ACI and Vmware vRealize – just to name a few.

Before you embark on the automation journey, identify the drivers, tie it to business needs and spend some time planning the transition by identifying the use cases and tools in use. Script the processes manually and test before automating using tools of your choice.

Read “2019 C-Suite Perspectives: From Defense to Offense, Executives Turn Information Security into a Competitive Advantage” to learn more.

Download Now

Application Delivery

Auto-Discover, -Scale and -License ADCs

June 5, 2019 — by Prakash Sinha0

ADC--960x591.jpeg

In the changing world of micro-service applications, agile approach, continuous delivery and integration, and the migration of applications and service to the cloud, ADCs (aka load balancers) are likewise transforming.

ADCs still make applications and services available–locally or globally, within and across cloud and data centers–while providing redundancy to links and reducing latency for the consumers of application services. However, due to where ADCs sit in the network, they have taken on additional roles of a security choreographer and a single point of visibility across the front-end, networks and applications.

Traditionally deployed as a redundant pair of physical devices, ADCs have begun to be deployed as virtual appliances. Now, as applications move to the cloud, ADCs are available as a service in the cloud or as a mix of virtual, cloud and physical devices depending on cost and performance characteristics desired.

Core Use Cases

Providing high availability (HA) is one of the core use cases for an ADC. HA addresses the need for an application to recover from failures within and between data centers. SSL offload is also a core use case. As SSL/TLS become pervasive to secure and protect web transactions, offloading non-business functions from application and web servers is needed to reduce application latency while lowering the cost of application footprint required to serve users.

[You may also like: Application Delivery Use Cases for Cloud and On-Premise Applications]

One of the ways organizations use cloud and automation to optimize the cost of their application infrastructure is by dynamically adjusting resource consumption to their actual utilization levels. As the number of users connecting to a particular application service grows, new instances of application services are brought online. Scaling-in and scaling-out in an automated way is one of the primary reasons why ADCs have built-in automation and integrations with orchestration systems. For example, Radware’s automation capabilities enhance and extend Microsoft Azure by taking advantage of Scale Sets to automatically grow and shrink the ADC cluster based on demand.

Automating Operations

Auto scale capability is important for organizations looking to automate operations – that is to add and remove services on demand without manual intervention for licensing and to reclaim capacity when no longer in-use. This saves costs, both in operations and well as in training. As organizations move to the cloud, capacity planning and associated licensing are common concerns. Elastic licensing is directed to cap the cost of licenses as organizations transition from physical hardware or virtual deployment to cloud.

[You may also like: Economics of Load Balancing When Transitioning to the Cloud]

Innovative elastic licensing benefits small and large enterprises, and enables then to protect against load balancing pricing shocks as the numbers of users and associated SSL transactions grow, while simplifying capacity planning. End-to-end visibility and automation further enable self-service across various stakeholders and reduce errors.

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

Application DeliveryCloud Computing

Economics of Load Balancing When Transitioning to the Cloud

May 22, 2019 — by Prakash Sinha0

adc2-960x566.jpg

One of the concerns I hear often is that application delivery controller (ADC) licensing models do not support cloud transitions for the enterprise or address the business needs of cloud service providers that have a large number of tenants.

Of course, there are many models to choose from – perpetual pricing per instance, bring-your-own license (BYOL), consumption and metered licensing models by licensing by CPU cores, per-user, by throughput, service provider-licensing agreements (SPLA), to name a few. The biggest concern is the complexity in licensing of ADC capacity. In a cloud environment, the performance profile for a particular instance may need to change to accommodate traffic spike. The licensing infrastructure and automation needs to accommodate this characteristic.

Traditionally, load balancers were deployed as physical devices as a redundant pair supported by perpetual pricing, a non-expiring license to use an instance, whether it’s hardware, virtualized or in the cloud. The customer has no obligation to pay for support or update services, although they are offered at an additional yearly cost. As virtualization took hold in the data centers, ADCs began to be deployed as virtual appliances and started supporting subscription licensing model – a renewable license, usually annual or monthly, that includes software support and updates during the subscription term. The license is automatically terminated unless it is renewed at the end of the term. Now, as applications move to cloud, ADCs are being deployed as a service in the cloud and consumption-based pricing is becoming common.

[You may also like: Keeping Pace in the Race for Flexibility]

Evaluating Choices: The Problem of Plenty

There are many licensing models to choose from – perpetual , subscription, consumption/metered, so how do you decide what to choose? The key is to understand what problem you’re trying to solve, identify the *MUST* have capabilities you’d expect for your applications, and plan how much of the capacity you’d need and then do an apples-to-apples comparison.

Understand the use case

Let us consider a cloud service provider (CSP) tenant onboarding as an example. The provider offers service to its tenants (medium and large enterprises), which consume their own homegrown applications and those offered and hosted by the CSP.

[You may also like: Application Delivery Use Cases for Cloud and On-Premise Applications]

For example, a CSP whose tenants are hospitals and physician networks offers patient registration systems as a shared SaaS offering among multiple tenants. Each tenant has varying needs for a load balancer – small ones require public cloud-based ADCs, whereas mid-sized and large ones have both public and private cloud solutions. Some of the larger tenants of the CSP also require their application services proxied by hardware ADCs due to low latency requirements. Self-service is a must for the CSP to reduce cost of doing business and so it automation and integration to support the tenants that administer their own environments.

Based on the use case, evaluate what functionality you’d need and what type of form factor support is required

CSPs are increasingly concerned about the rapid growth and expansion of Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform into their markets. Hosting providers that only provide commodity services, such as co-location and web hosting, have realized they are one service outage away from losing customers to larger cloud providers.

[You may also like: Embarking on a Cloud Journey: Expect More from Your Load Balancer]

In addition, many CSPs that provide managed services are struggling to grow because their current business is resource intensive and difficult to scale. In order to survive this competitive landscape, CSPs must have:

  • Cost predictability for the CSP (and tenants)
  • The ability to offer value-added advisory services, such as technical and consulting opportunities to differentiate
  • Self-service to reduce resources via the ability to automate and integrate with a customer’s existing systems
  • Solutions that span both private and public cloud infrastructure and includes hardware

For the CSP onboarding use case above, from a technical requirement, this breaks down to: Self-service, ability to create ADC instances of various sizes, automated provisioning, support for Ansible, vRO and Cisco ACI. From a business perceptive, the CSP needs to offer a host of solutions for their tenants that span cloud, private and hardware based ADCs.

[You may also like: Digital Transformation – Take Advantage of Application Delivery in Your Journey]

Plan Capacity

Once you understand the use case and have defined functional technical and business requirements, it’s time to review what kind of capacity you’ll need – now and in future. You may use existing analytics dashboards and tools to gain visibility into what you consume today. The data may be your HTTP, HTTP/S, UDP, SSL certificates, throughput per application at peak, connection and requests per second. Based on your growth projections you may define future needs.

Compare Available Options

The next step is to look at the various vendors for the performance metric that’s important to your applications. If you have a lot of SSL traffic, then look at that metric as a cost/unit across various vendors.

[You may also like: Are Your Applications Secure?]

Once you have narrowed down the list of vendors to those that support the functionality your applications MUST have, now it’s time to review the pricing to be within your budget. It’s important to compare apples-to-apples. So based on your capacity and utilizations profile, compare vendors on your short list. The chart below shows one example of comparison on AWS using on demand instances versus Radware Global Elastic Licensing subscription as a yearly cost.

As enterprises and service providers embark on a cloud journey, there is a need for simpler and flexible licensing model and infrastructure that eliminates planning risk, enables predictable costs, simplifies and automates licensing for provisioned capacity and enabled the ability to transfer capacity from existing physical deployment to cloud to realize savings.

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

Application DeliveryCloud Computing

Application Delivery Use Cases for Cloud and On-Premise Applications

April 23, 2019 — by Prakash Sinha0

ADC-960x548.jpg

Most of us use web applications in our daily lives, whether at work or for personal reasons. These applications include sites offering banking and financial services, payroll, utilities, online training, just to name a few. Users get frustrated, sometimes annoyed, if the applications – such as bank account access, loading of a statement, emails, or bills – are slow to respond. Heaven help us if we lose these services right in the middle of a payment!

data center, servers, application delivery controllers, ADCs, ADC
White and blue firewall activated on server room data center 3D rendering

If you look at these applications from a service provider perspective, especially those that have web facing applications, this loss of customer interest or frustration is expensive and translates into real loss of revenue, almost $8,900 per minute of downtime in addition to loss of customer satisfaction and reputation. And if your services are in the cloud and you don’t have a fall back? Good luck…

Traditional Use of ADCs for Applications

This is where application delivery controllers (ADCs), commonly referred to as load balancers, come in. ADCs focus on a few aspects to help applications. ADCs make it seem to the user that the services being accessed are always up, and in doing so, reduce the latency that a user perceives when accessing the application. ADCs also help in securing and scaling the applications across millions of users.

[You may also like: Ensuring a Secure Cloud Journey in a World of Containers]

Traditionally, these load balancers were deployed as physical devices as a redundant pair, then as virtualization took hold in the data centers, ADCs began to be deployed as virtual appliance. Now, as applications move to cloud environments, ADCs are being deployed as a service in the cloud, or as a mix of virtual, cloud and physical devices (depending on cost and desired performance characteristics, as well the familiarity and expertise of the administrator of these services – DevOps, NetOps or SecOps).

The ADC World is Changing

The world of ADCs is changing rapidly. Due to the fast changing world of applications, with micro-services, agile approach, continuous delivery and integration, there are many changes afoot in the world of ADCs.

ADCs still have the traditional job of making applications available locally in a data center or globally across data centers, and providing redundancy to links in a data center. In addition to providing availability to applications, these devices are still used for latency reduction – using caching, compressions and web performance optimizations – but due to where they sit in the network, they’ve taken on additional roles of a security choreographer and a single point of visibility across a variety of different applications.

[You may also like: Embarking on a Cloud Journey: Expect More from Your Load Balancer]

We are beginning to see additional use cases, such as web application firewalls for application protection, SSL inspection for preventing leaks of sensitive information, and single sign on across many applications and services. The deployment topology of the ADC is also changing – either run within a container for load balancing and scaling micro-services and embedded ADCs, or be able to provide additional value-add capabilities to the embedded ADCs or micro-services within a container.

Providing high availability is one of the core use cases for an ADC. HA addresses the need for an application to recover from failures within and between data centers themselves. SSL Offload is also considered a core use case. As SSL and TLS become pervasive to secure and protect web transactions, offloading non-business functions from application and web servers so that they may be dedicated to business processing is needed not only to reduce application latency but also to lower the cost of application footprint needed to serve users.

As users connecting to a particular application service grow, new instances of application services are brought online in order to scale applications. Scaling-in and scaling-out in an automated way is one of the primary reasons why ADCs have built-in automation and integrations with orchestration systems. Advanced automation allows ADCs to discover and add or remove new application instances to the load balancing pool without manual intervention. This not only helps reduce manual errors and lowers administrative costs, but also removes the requirements for all users of an ADC to be experts.

[You may also like: Digital Transformation – Take Advantage of Application Delivery in Your Journey]

As we move to the cloud, other uses cases are emerging and quickly becoming a necessity. Elastic licensing, for example, is directed to cap the cost of licenses as organizations transition from physical hardware or virtual deployment to the cloud. Another use case is to provide analytics and end-to-end visibility, designed to pin-point root a cause of an issue quickly without finger-pointing between networking and application teams.

ADCs at the Intersection of Networking and Applications

Since ADCs occupy an important place between applications and networks, it’s quite logical to see ADCs take on additional responsibilities, as applications serve the users. Application delivery and load balancing technologies have been the strategic components providing availability, optimization, security and latency reduction for applications. In order to enable seamless migration of business critical applications to the cloud, the same load balancing and application delivery infrastructure has evolved to  address the needs of continuous delivery/integration, hybrid and multi-cloud deployments.

Read the “2018 C-Suite Perspectives: Trends in the Cyberattack Landscape, Security Threats and Business Impacts” to learn more.

Download Now

Application Delivery

Load Balancers and Elastic Licensing

February 22, 2018 — by Prakash Sinha1

load-balancing-gel-960x472.jpg

Last week I met with a very large enterprise in finance that has adopted provisioning on demand. They spin up applications on demand, having virtualized most of their infrastructure and have developed tools to automate the provisioning of applications and servers for customers and internal application developers through self-service applications.

Application DeliveryWPO

Are ADCs Another Layer of Defense Against Cyber Attacks?

May 14, 2015 — by Yaron Azerual0

Application Delivery Controllers (ADCs) were once ubiquitous hardware-based appliances seen in data centers for the sole purpose of load balancing.  However, this role has changed and the use of ADCs has expanded beyond their original purpose in an effort to keep up with the needs of the today’s IT pros.

The result is that ADCs now operate in a much less narrow function.