main

DDoSSecurity

Disaster Recovery: Data Center or Host Infrastructure Reroute

October 11, 2018 — by Daniel Lakier1

disaster-recovery-data-center-host-infrastructure-reroute-blog-960x540.jpg

Companies, even large ones, haven’t considered disaster recovery plans outside of their primary cloud providers own infrastructure as regularly as they should. In March of this year, Amazon Web Services (AWS) had a massive failure which directly impacted some of the world’s largest brands, taking them offline for several hours. In this case, it was not a malicious attack but the end result was the same— an outage.

When the organization’s leadership questioned their IT departments on how this outage could happen, most received an answer that was somehow acceptable:  It was AWS. Amazon failed, not us. However, that answer should not be acceptable.

AWS implies they are invulnerable, but the people running IT departments are running it for a reason. They are meant to be skeptics, and it is their job to build redundancies that protect the system against any one point of failure.  Some of those companies use AWS disaster recovery services, but if the data center and all the technology required to turn those fail-safes on crashes, then you’re down. This is why we need to treat the problem with the same logic that we use for any other system. Today it is easier than ever to create a resilient DoS resistant architecture that not only takes traditional malicious activity into account but also critical business failures. The solution isn’t purely technical either, it needs to be based upon sound business principles using readily available technology.

[You might also like: DDoS Protection is the Foundation for Application, Site and Data Availability]

In the past enterprise disaster recovery architecture revolved around having a fully operational secondary location. If we wanted true resiliency that was the only option. Today although that can still be one of the foundation pillars to your approach it doesn’t have to be the only answer. You need to be more circumspect about what your requirements are and choose the right solution for each environment/problem.  For example:

  • A) You can still build it either in your own data center or in a cloud (match the performance requirements to a business value equation).
  • B) Several ‘Backups-as-a-Service’ will offer more than just storage in the cloud. They offer resources for rent (servers to run your corporate environments in case of an outage). If your business can sustain an environment going down just long enough to turn it back on (several hours), this can be a very cost-effective solution.
  • C) For non-critical items, rely on the cloud provider you currently use to provide near-time failure protection.

The Bottom Line

Regardless of which approach you take, even if everything works flawlessly, you still need to address the ‘brownout’ phenomenon or the time it takes for services to be restored at the primary or to a secondary location. It is even more important to automatically send people to a different location if performance is impaired. Several people have heard of GSLB, and while many use it today, it is not part of their comprehensive DoS approach.  But it should be. If your goal with your DDoS mitigation solution is to ensure an uninterrupted service in addition to meeting your approved performance SLA; then dynamic GSLB or infrastructure based performance load balancing has to be an integral part of any design.

We can deploy this technology purely defensively, as we have traditionally done with all DoS investments or we change the paradigm and deploy the technology to help us exceed expectations. This allows us to give each individual user the best experience possible. Radware’s dynamic performance-based route optimization solution (GSLB) allows us to offer a unique customer experience to each and every user regardless of where they are coming from, how they access the environment or what they are trying to do. This same technology allows us to reroute users in the event of a DoS event that takes down an entire site be it from malicious behavior, hardware failure or simple human error. This functionality can be procured as a product or a service as it is environment/cloud agnostic and relatively simple to deploy. It is not labor intensive and may be the least expensive part of an enterprise DOS architecture.

What we can conclude is that any company that blames the cloud provider for a down site in the future should be asked the hard questions because solving this problem is easier today than ever before.

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

Download Now

Application DeliveryApplication SecuritySecurity

DDoS Protection is the Foundation for Application, Site and Data Availability

September 11, 2018 — by Daniel Lakier2

ddos-primer-part-1-960x788.jpg

When we think of DDoS protection, we often think about how to keep our website up and running. While searching for a security solution, you’ll find several options that are similar on the surface. The main difference is whether your organization requires a cloud, on-premise or hybrid solution that combines the best of both worlds. Finding a DDoS mitigation/protection solution seems simple, but there are several things to consider.

[You might also like: Should Business Risk Mitigation Be A Factor When We Choose Our Suppliers and Manufacturers?]

It’s important to remember that DDoS attacks don’t just cause a website to go down. While the majority do cause a service disruption, 90 percent of the time it does not mean a website is completely unavailable, but rather there is a performance degradation. As a result, organizations need to search for a DDoS solution that can optimize application performance and protect from DDoS attacks. The two functions are natural bedfellows.

The other thing we often forget is that most traditional DDoS solutions, whether they are on-premise or in the cloud, cannot protect us from an upstream event or a downstream event.

  1. If your carrier is hit with a DDoS attack upstream, your link may be fine but your ability to do anything would be limited. You would not receive any traffic from that pipe.
  2. If your infrastructure provider goes down due to a DDoS attack on its key infrastructure, your organization’s website will go down regardless of how well your DDoS solution is working.

Many DDoS providers will tell you these are not part of a DDoS strategy. I beg to differ.

Finding the Right DDoS Solution

DDoS protection was born out of the need to improve availability and guarantee performance.  Today, this is critical. We have become an application-driven world where digital interactions dominate. A bad experience using an app is worse for customer satisfaction and loyalty than an outage.  Most companies are moving into shared infrastructure environments—otherwise known as the “cloud”— where the performance of the underlying infrastructure is no longer controlled by the end user.

Keeping the aforementioned points in mind, here are three key features to consider when looking at modern enterprise DDoS solutions:

  1. Data center or host infrastructure rerouting capabilities gives organizations the ability to reroute traffic to secondary data centers or application servers if there is a performance problem caused by something that the traditional DDoS prevention solution cannot negate. This may or may not be caused by a traditional DDoS attack, but either way, it’s important to understand how to mitigate the risk from a denial of service caused by infrastructure failure.
  2. Simple-to-use link or host availability solutions offer a unified interface for conducting WAN failover in the event that the upstream provider is compromised. Companies can use BGP, but BGP is complex and rigid. The future needs to be simple and flexible.
  3. Infrastructure and application performance optimization is critical. If we can limit the amount of compute-per-application transactions, we can reduce the likelihood that a capacity problem with the underlying architecture can cause an outage. Instead of thinking about just avoiding performance degradation, what if we actually improve the performance SLA while also limiting risk? It’s similar to making the decision to invest your money as opposed to burying it in the ground.

[You might also like: Marrying the Business Need with the Technology Drive: Recapping It All]

Today you can look at buying separate products to accomplish these needs but you are then left with an age old problem: a disparate collection of poorly integrated best-of-breed solutions that don’t work well together.

These products should work together as part of a holistic solution where each solution can compensate and enhance the performance of the other and ultimately help improve and ensure application availability, performance and reliability. The goal should be to create a resilient architecture to prevent or limit the impact of DoS and DDoS attacks of any kind.

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

Download Now

Application DeliverySecurity

Should Business Risk Mitigation Be A Factor When We Choose Our Suppliers And Manufacturers?

July 24, 2018 — by Daniel Lakier1

supplier-manufacturer-960x640.jpg

This is something that I have struggled with for most of my working life. As a technology professional, it is my job to pick the best products and solutions or to dig deeper to marry that technological decision with one that’s best for my organization. Is it incumbent on me to consider my suppliers’ financials, or their country or origin, or perhaps their business practices?

This thought was thrust sharply into focus during the past few months. First, we were reminded that a sound business still needs to have sound financials. The second warning is around the ramifications of a trade war.

Application Delivery

Marrying the Business Need With Technology Drive, Part 4: Use Tools to Save Some Time (They Do Exist)!

March 6, 2018 — by Daniel Lakier0

using-tools-960x574.jpg

In the past 20 years I have often found myself looking for just the right technology tool to solve a specific problem. Most often I have been able to find something to fit the bill, but not the sought after, best-of-breed solution that promises to solve all the world’s problems.  Sometimes I wonder if it would be possible to find the right combination of tools to create world peace, end world hunger or end global warming. Obviously I’m being facetious, but the problem is this approach of finding specific tools to solve symptomatic problems remains the same as it did twenty years ago. By the time you assemble all the disparate tools to create Utopia, you realize you actually have Frankenstein. Too many tools, like too many cooks in the kitchen, can make success untenable with too much to set up, too much complexity, a non-global view and oftentimes fractured ownership. Not to mention that this approach oftentimes makes solving the root cause of the problem difficult.

Application DeliveryWAF

Marrying the Business Need With Technology, Part 3: Re-aggregating the Tools

January 18, 2018 — by Daniel Lakier0

reaggregating-tools-960x421.jpg

In part one of this blog series we discussed how there is oftentimes a lack of knowledge when it comes to infrastructure technology and knowhow in the relevant DevOps teams. This is not what was intended when “Agile” moved from being a pure development approach to a whole technology management methodology, but it is where we find ourselves. One of the consequences we face because of this is that the traditional user of many technologies, the developers/application owners, know what functionality they should have but not where to get it.

Application Delivery

Using SLA Management to Save Time and Improve

December 13, 2017 — by Daniel Lakier0

sla-management-software-960x679.jpg

Today more than ever, the success or failure of our digital enterprise rests on whether our customer has a good user experience. No one wants to use something that is difficult to use or unreliable, and most of us don’t want to use something unless the user experience is consistent. All too often, organizations expend all their energy into making their tool /application look good, be easy to use or making it have great functionality. What they forget is that performance, especially consistent performance, can be just as important. All these things rolled into one are what I call the convenience factors. It’s not a new concept and many brick-and-mortar companies have failed over the years because of this. If we go back a few years, we can see many examples of technology or companies succumbing from an original position of strength because they never took this perceived convenience/quality factor into account. Three examples:

Application Delivery

Marrying the Business Need With Technology Drive, Part Two: Security by Proxy or to Complicate

December 6, 2017 — by Daniel Lakier0

security-by-proxy-960x640.jpg

One of the biggest challenges we continue to see in the evolving cloud and DevOps world is around security and standards in general.

The general lack of accumulated infrastructure knowledge coupled with the enthusiasm with which DevOps teams like to experiment is causing significant challenges for corporations in terms of standardization. This is leading to two primary symptoms:

Application Delivery

Marrying the Business Need With Technology Drive, Part One: Choosing Your Cloud

November 30, 2017 — by Daniel Lakier0

choosing-cloud-960x585.jpg

Several years ago, the monolithic approach to application development fell out of vogue because time to market became the key success metric in our ever-changing world. Agile development started to become the norm and the move to DevOps was born.  At the same time as this change was taking place, there was another ground breaking development: the advent of public clouds.  Either change by itself was industry -impacting but the two happening at the same time, both enabling each other, changed everything.