Flagging a legitimate user as malicious (false positive) results in the denial of service for legitimate users; conversely, identifying a malicious user as legitimate (false negative) may open the door for additional, undetected cyber-attacks. How then, do DDoS mitigation solutions distinguish between legitimate and malicious users?

Rate limitation is not the way to go

First, I’ll explain why outdated anti-DDoS solutions that base their protection on rate limitation methods cannot address this challenge.

The rate limit mechanism is based on a pre-defined, static threshold of traffic and has two main drawbacks:

1. It does not mitigate attacks until the attack traffic reaches the predefined threshold. This results in slow detection of attacks or failure to detect attacks below the threshold.
2. Once the rate based mechanism starts to mitigate suspected traffic, it impacts the quality of experience for all users, including legitimate ones. Not every increase in traffic rate is a result of an attack; there are other cases, such as flash crowd events, that look like attacks to outdated anti-DDoS solutions. As a result, the solution can mistakenly block legitimate traffic.

It is clear that outdated anti-DDoS solutions cannot distinguish properly between attackers and legitimate users. Advanced DDoS mitigation solutions deploy more sophisticated methods, such as behavioral analysis or challenge-response mechanisms to deal with this challenge.

Behavioral Analysis

Behavioral analysis follows application transactions and builds an understanding of the application in order to distinguish between legitimate and malicious users. A baseline application behavior is defined after considering both the amount and frequency of events.

During an attack, data is gathered and compared to the baseline behavior model. If a suspicious behavior is detected, a deeper inspection process is triggered, which analyzes application-level parameters and resolves whether the suspicious behavior is a result of a legitimate burst of application traffic or a result of a malicious application abuse.

For example, a PDF file in a certain website is normally downloaded 10 times per hour. If the same file is downloaded 1000 times per hour, an attacker may be involved, so further security measures must be taken.

Challenge Response

A challenge response (C/R) mechanism sends challenges to suspicious sources and based on the response, determines if the source is a Bot or a real user. An example of a challenge response mechanism is CAPTCHA, which requires the user to type letters and/or digits from a distorted image that appears on the screen. The CAPTCHA test prevents unwanted internet bots from accessing websites, since a normal human can easily read the CAPTCHA, while the bot cannot process the image letters.

To use the C/R mechanism, an attack mitigation system launches a series of queries to the source of a request in question, and according to the responses received, it decides whether to send an additional, more sophisticated challenge, or flag the source as a malicious user. C/R mechanisms use automated processes, and require no human intervention from the mitigation system or from the source. The intelligent usage of a C/R mechanism and network behavioral analysis can almost completely eliminate false positives, guaranteeing an excellent quality of experience for legitimate users.

In summary, anyone can rate limit the traffic to a specific application and prevent floods on the applications, but this will result in denying the service from your legitimate users, which was the original objective of the attackers. Only advanced anti-DDoS solutions can successfully distinguish between attackers from legitimate users during an attack and guarantee proper service to online customers.

Why you need to know your site’s performance poverty line

What’s the ideal load time for a typical web page? I encounter this question a lot, and there’s no single correct answer. Depending on whom you ask, you’ll hear a range of answers, including:

• 100 milliseconds
• 400 milliseconds
• 1 second
• 2 seconds
• 3 seconds
• And so on.

Having an ambitious performance goal, such as delivering pages in 2 seconds or less, is an essential part of your web strategy. But in conjunction with that goal, you also need to know at what point your site bottoms out in terms of delivering conversions, page views, revenue, stickiness, or whatever metrics are key for your business.

To illustrate this, we recently looked at data for five of our ecommerce customers’ sites, comparing sets of their 2010 and 2012 numbers for bounce rate, page speed, and conversion rate. After plotting the data on a set of graphs, a clear snapshot emerged:

Observations

In this case study, we can see two things clearly:

1. The performance poverty line for these sites was around 8 seconds across all three metrics. What’s noteworthy here isn’t just this number, but how incredibly consistent it is across all metrics.
2. When pages are slow, business metrics suffer more now than they did two years ago. For example, look at the final graph. A page that took 6 seconds to load in 2010 suffered a -40% conversion hit. Today, a 6-second page takes a -50% hit. Or look at the second graph, where you see that a relatively fast 4-second page suffers a -30% hit in page views per visit in 2010, but in 2012 a 4-second page takes more than a -40% hit. This indicates a substantial change in consumer expectations. Simply put, people are less willing than ever to suffer slow pages.

How to measure the poverty line for your own site

Your results may vary: 8 seconds may not be the poverty line for your site. Fortunately, the process for identifying the low end of your site’s performance threshold is fairly straightforward. All you need is access to a statistically significant amount of your web data, plus whatever analytics tool you use for tracking key metrics.

Step 1: Identify the metrics you want to measure.

If you run an ecommerce site, then you’ll obviously want to measure revenue. If you’re a SaaS, then you may focus on conversions. If you’re a media site, then page views and bounce rate matter.

Step 2: Gather data.

To ensure that you get statistically relevant results, the more data you can gather, the better. When we conducted our tests, we aggregated millions of transactions that took place over a single month.

Step 3: Plot data.

We found that using the x axis for load time and the y axis for the metric yielded easily readable graphs.

Step 4 (optional): Compare to previous time frames.

If you want to find out if your customers’ load time expectations have changed over time, as we found in our test, repeat steps 1 through 3 for an earlier time period. Depending on how far back your data goes, it would be extremely interesting to track changes year over year.

Step 5: Share your findings.

Evangelize your results within your organization. Knowing how low your bar can go is, in its own way, as critical as knowing how high you want it to be. And incidentally, as you may have already noted when looking at the graphs above, this process will also give you valuable insight into how your metrics are affected at other points on your graphs.

I’m very curious to find out if our 8-second poverty line is consistent across other sites, or if it varies. If you go through this exercise, I’d love to hear your results.

It doesn’t take much to imagine the following scenarios arising from a system or power outage as a result of a cyber attack:

• Infirmed individuals struggling to maintain continuity of care during either a power or system-level outage
• Emergency responders unable to gain valuable information about the nature of a fast-moving disaster because of a system level hack or outage
• People falsely directed to take specific action as a result of cyber attack on the emergency broadcast system
• Extended outages of power, oil and gas production and communications and/or water services

However, with attacks happening on a daily basis we have become numb to the depth, breadth, speed and efficacy of cyber attacks and systemic breakdowns occurring all around us. Let’s look back at a few that we witnessed over the past year:

• The longest continuous DDoS attacks in history: Operation Ababil against US Commercial Banks
• The first “in-the-wild” encrypted DDoS attacks: Operation Ababil
• Politically motivated cyber attacks: Operation Israel, Operation USA, Operation Turkey
• The first systemic outage of a tier-one telecommunications provider by a cyber attack: AT&T DNS attack(s) around Aug. 15th, 2012
• Largest oil production cyber attack in history: Oil fields in Saudi Arabia stop producing for two days and thousands of PCs are infected with malicious viruses

Confronted with these events, information security professionals can respond in one of two ways:

The first option is to wave the proverbial “white flag” and rack up the well-heeled excuses for not getting the hard work that information security requires done.

The following is a list of justified reasons often cited by security professionals in response to failing to adequately protect an enterprise:

• Lack of resources including time, money and available people
• Identified risks accepted by the business
• Lack of knowledgeable people
• Lack of access to key technologies/vendors

The second option is to recognize that the sky is falling, sound the trumpets and head to the “high-ground”. Yes, sometimes that happens – even if it should rarely be talked about. How else can we explain why the US commercial banks, the largest, most well-resourced and well-staffed companies in the world, are struggling with the current threat landscape? After all, if these strong and heavily fortified institutions fell victim to DDoS attacks, how in the world can more ill-prepared industries such as government agencies, healthcare providers, educational institutions as well energy and manufacturing, be prepared without dramatic and quick change to their security programs?

If, like me, you are among the group of paranoid security professionals that make up the second category, how do you go about battening down the hatches and building a much more effective security program?

While it is difficult to say with certainty how these changes in the cyber security landscape will play out, we can make certain assumptions based on the frequency, effectiveness and directed nature of the attacks:

• Cyber Attacks will Become ‘Normal’. That is, we will come to expect an attack whenever the slightest grievance is encountered in our business and daily duties. These attacks will result from macro-level political motivations, like the Middle East conflict, to micro-level grievances such as a quarrel with your next-door neighbor and everything in-between. Bottom line: Cyber attacks are not a fad. As long as they are effective, they will NOT just go away.




• Common and Not-So-Common Criminals Will Get in on the Cyber-Attack Act. Cyber attacks started out as largely ideologically or politically motivated in nature. However, since the start of 2013 we’ve seen a significant increase in common criminals who are leveraging effective attack techniques to either make money or increase competitiveness. Bottom line: Cyber attacks focused on “Hacktivism” will be joined at a massive rate by “Financially Oriented” attacks. Perpetrators will become more brazen as they realize how inept the legal system is in dealing with these attacks.




• Attacks will Get Very Technical and Encrypted. Taking lessons learned from the US banks attacks, perpetrators understand that systemic technical weaknesses such as SSL-DDoS attacks do exist. Bottom line: If the security model your enterprise is deploying hasn’t materially changed since 2005, your organization will be utterly ineffective in fighting today’s cyber attacks.




• Laws will fail to Meaningfully Address the “Flat Cyber Battlefield”. Unfortunately, laws built around a paradigm of domiciles and nation-states don’t work well for a world in which these constructs have lost their efficacy. As a result, all of the laws in the world won’t address the problem unless the issue is addressed globally and systemically. Bottom line: Help from law enforcement will not be available; organizations have largely been left to fight this battle alone.

Countermeasures are needed! Defense mitigation strategies are also evolving and now include active counterattack strategies. Bottom line: organizations will become more aggressive in fighting DDoS attacks amidst the increasing need to leverage counter attacks to mitigate threats.

What security changes are you making to effectively deal with the evolving threat landscape?

Pitfall #1: An ADC that Cannot Connect to Next-Generation Switches

When it comes to network switches, there’s an increasing adoption of next-generation connectivity in the form of 10GE, and even 40GE, ports. It is important that your ADC is able to connect to these switches without requiring migration to a new ADC device. With built-in high-speed ports, your ADC will be able to connect to both today’s and tomorrow’s core switching – allowing your applications to benefit from 10GE connectivity. In addition, make sure that your ADC has high port density. This enables connectivity to a greater number of applications and physical networks without adding more intermediate switches.

Pitfall #2: Not Leveraging the Benefits of ADC Virtualization

If you’re in charge of an application, line of business or the entire IT infrastructure – you’re probably responsible for managing the application lifecycle. Until now, rolling out a new application required deploying a new dedicated ADC, which meant high CAPEX and OPEX. Using one of your existing ADCs to serve several applications is not recommended because the applications will compete for the same resources, which impacts the end-user quality of experience at times of cyber attacks, flash crowds and shopping peaks. The solution? Make sure to select an ADC that provides ADC virtualization. This will enable you to employ a separate virtual ADC (vADC) instance per application – providing the addition of a new ADC service without the need for more ADC hardware units.

The benefits of this approach are countless. Rolling out an application is fast and easy without the need to add a new ADC unit, as well as rack it, connect it to the network and reconfigure switches. Application SLA is guaranteed thanks to the complete isolation between vADC instances at the fault, management and network levels. Ongoing maintenance is simplified as each vADC is configured separately without interfering with neighboring instances. In addition, the combination of high vADC density together with the fact that each vADC instance can run a different vADC supports more and more applications and/or services over time in a risk-free fashion.

Pitfall #3: Buying an ADC with a Fixed Capacity

Given the benefits of ADC virtualization, I would recommend selecting an ADC solution that provides the flexibility to add more vADCs on the same box – starting at entry-level requirements. As more applications require load balancing, the overall network throughput, SSL traffic and compression capacity might all grow. What then? Would you replace your ADC every time that happens? Pay more money for new hardware and spend time on configuration, staff training and new spare units? As these imply high expenditures, the answer is no. 

Therefore, it’s important to select an ADC that delivers high performance in terms of all layer 4-7 metrics. Combined with a “pay-as-you-grow” approach based on a simple license update, this flexible ADC solution will be able to address unfolding business and network needs in a cost effective manner. Particularly, it is vital to be able to scale on demand out of the box, using resources from the cloud or from a different site. Such an approach helps reduce expenditures and offers the best investment protection by eliminating forklift upgrades and application downtime.

Pitfall #4: Not Asking Which Response Time Acceleration the ADC Can Offer

Everyone realizes that application delivery is not only about availability and reliability but also about better performance and faster response times. In this respect, all of today’s ADCs claim to deliver response time acceleration. But the truth is that most of today’s ADCs only deliver a set of commoditized application acceleration capabilities including SSL offloading, web compression, caching, HTTP multiplexing and more. Though these can offload server processing and shorten response times, they are not enough. Other ADCs claim to offer Web Performance Optimization (WPO) features that provide more modern web optimization techniques. I recommend checking the specific WPO features the ADC you’re considering delivers. Specifically, it’s important to verify that the WPO capabilities optimize response time for any browser as well as all end-user devices (including mobile devices), anywhere. Even better – ask for a performance test for your specific application in order to see the performance optimization outcome for yourself.

Pitfall #5: Choosing An ADC That is Not Application-Aware or Non-Customizable

If you run or deploy off-the-shelf business applications (such as applications from Microsoft, IBM, SAP, Oracle, etc.) you obviously require your application delivery configuration policies to be optimized for them. With this priority in mind, ensure the ADC you select has pre-defined configuration templates for these applications. This not only ensures optimization but also streamlines the process of configuring your policies, saving you precious time. On a wider scope, make sure that your ADC can be managed from an application perspective, including configuration templates, automatic application configuration synchronization, reporting, logging, compliance and more. The business value includes fast application rollout and operational simplicity. 

Pitfall #6: Ignoring Your Application SLA

Are you 100% aware of the actual quality of experience that your end-users are experiencing? Probably not. Would you like to be? Definitely. Whenever your end-users experience issues – whether they are network or application related – you want to be the first to know about it, before you receive those angry calls. Otherwise, your users will be less satisfied and your business reputation will suffer, leading to a potential reduction in revenue. Leveraging your ADC’s built-in central reporting and application performance monitoring (APM) capabilities is the simplest way to get end-to-end visibility of application/ADC performance issues because it doesn’t require server integration or synthetic transaction scripting. Make sure that the APM module allows you to drill-down to geo-location, transaction and server farm level for complete visibility into the application delivery infrastructure.

Armed with these six potential pitfalls as a guide, your ADC purchasing process should be a much smoother experience. Is your organization currently looking for an ADC? If so, we would love to hear more about the features you find most important in an ADC solution.

Although this brings the promise of relieving traffic jams for mobile operators, it also brings new security risks. As traffic generated by smartphones grow, LTE networks’ fast mobile broadband will assist handling the increased traffic.

However, mobile operators will have to learn how to handle the new threats. New Advanced Persistent Threats (APT) are emerging and mobile carriers and mobile user will find themselves struggling with similar APTs that we see at Enterprises today. For Long Term Evolution networks not to fall short on security, mobile operators must realize the increased threats from malware, fraud, distributed denial of service (DDoS) attacks and many other attacks, and adopt more comprehensive and innovative security strategies.

Although LTE, which is commonly referred as mobile network 4th generation (4G), provides a solid infrastructure to deliver advanced, content-rich applications in real-time, I discuss a few security challenges that should be addressed in order to protect the network from overload and declining quality of service.

The article can be found here. I invite you to read it, and feel free to share any comments or questions you may have for me.

Appearance of legitimacy

Low & Slow attacks use slow traffic that appears legitimate in terms of the protocol rules and rates. By not violating any network standard or security policy they pass undetected, flying below the radar of traditional mitigation strategies.

The traffic, however, is designed to exhaust the victim’s resources until its services halt and become unavailable. For example, a popular Low & Slow attack tool is R.U.D.Y (R U Dead Yet?), which can bring down a web server by creating long form field submissions. This is done by iteratively injecting one byte into a web application post field followed by a sleep period. The result is that application threads become stuck because they are occupied with these one-byte POST fragments.

Slowloris is another popular Low & Slow attack tool that holds HTTP connections open by sending partial HTTP requests. Slowloris continues to send subsequent headers at regular intervals to occupy the application stack and keep the connections from closing. The web server quickly reaches its maximum application stack capacity and becomes unavailable for new connections by legitimate users.

Limited resources

Unlike other denial of service attacks, Low & Slow techniques require very little resources from attackers.  While performing a network flood requires several hundreds of Bot machines that simultaneously send traffic to overload network resources, Low & Slow attacks can be activated from a single attacking computer with no additional bots.

Detecting Low & Slow application attacks requires real-time awareness of the resources consumed by the protected servers, such as CPU, memory, connection tables, application states (virtual or real ones), application threads and more.

A resource aware detection solution will constantly monitor the status of resource allocation, as well as trends of the protected servers, and will be able to identify misuse of those resources. For example, long and relativity “idle” open network connections might imply that the server is under a connection table misuse attack. Additionally, an application stuck in a process that is supposed to be completed quickly may be under a R.U.D.Y attack.

Detecting such attacks requires a tight integration between the protected server and the mitigation solution. Another approach is for the mitigation solution to analyze the behavior of open server connections and to simulate the application stack resources without a direct connection to the server itself.  With the proper behavior analysis technologies, the misuse of the network and application resources can be identified with high accuracy. Once the activity is detected, it can be traced back to its origin and mitigated as necessary.

It’s clear that the Low & Slow method upends some of our preconceived notions when it comes to DDoS attacks. From its relative simplicity to its usage of minimal resources, defending against this increasingly popular tactic requires the right security infrastructure along with a dedicated team of security personnel that possesses the expertise to break down the latest attack tools in real time.

Has your organization been the victim of a Low & Slow attack? If so, share your experiences of how you detected and mitigated this deceptively malicious DDoS attack tool.

1. It’s in the protocol

The 30-year-old TCP (Transmission Control Protocol) is one of the most commonly used protocols between any two network devices today. While the TCP protocol has many advantages, such as reliability, its basic implementation delivers very low efficiency (i.e. net payload throughput). This is mainly because it pauses periodically, waiting for acknowledgements from the receiving side that all information has been received correctly. Even if a small portion has not been received, the information will be resent while recalibrating (slowing down) the amount of traffic that can be sent before waiting for the next acknowledgment. This basic process of pausing and waiting for acknowledgement from the receiver side is one of the causes of the TCP protocol’s low efficiency.

Application Delivery Controllers (ADCs) often serve as proxies to server clusters, and terminate/initiate the TCP connection with both the users and servers. There are various TCP optimization algorithms (e.g. Hybla or Westwood algorithms) that ADCs can execute to optimize the efficiency of the TCP protocol and thus yield higher throughput and lower response times.

2. Connection brokering

The TCP protocol is based on a connection that needs to be established for each and every network transaction. This process adds delays and lowers network throughput.

By using the ADC as a TCP proxy, it can maintain a few TCP connections opened with the server on one side and multiplex those connections with users’ TCP connections, reducing the delay caused by establishing the connection with the server. The ADC can also offload the server from maintaining multiple connections for numerous users.

3. Bandwidth Management

Assuming resources are limited, congestion is unavoidable. In itself, congestion is not necessarily a problem. The challenge is how to minimize its effects. One of those effects can be packet loss or varying delays, and even “time outs” of different application processes. This often results in a higher rate of retransmissions, which lowers the network’s “good-put” and as a result, its efficiency.

One of the solutions for this challenge is managing bandwidth utilization in the network. However, to do this effectively, the enforcer must gain enough knowledge of what each flow is, and how much bandwidth should be allocated to each in order to gain maximum network utilization efficiency. Since ADCs are designed to handle traffic based on information from layers 2-7, it makes sense to also implement a bandwidth management function, which will be able to classify traffic with high enough granularity and smart enough to “understand” how much bandwidth to allocate per traffic flow / application / user.

4. Measuring and selecting the fastest path

Routing protocols provide the ability to choose the fastest path from point A to B. However, if a web application can serve an end user from multiple datacenters, the question is, which one will provide the fastest response time?

To illustrate this point, here’s an example from a real customer – a Video on Demand (VoD) provider. The challenge was to provide the VoD service to hundreds of thousands of users connected through 6 different ISPs. By replicating his VoD application and content 6 times and deploying it in each of those 6 ISPs, the VoD provider naturally gained high availability. But he still needed to route his users to the correct datacenter, so that if user A connected to the Internet via ISP 1, he would be routed to the VoD application sever deployed in ISP 1’s datacenter, and so on.

ADCs that have a Global Server Load Balancing (GSLB) function can be used to do just that. When a user requests content from a website, the GSLB function will measure which of the datacenters can provide the requested content with shortest path delay to the user. It then redirects the user to the closest datacenter in terms of delay and number of hops. This way, the user benefits from a faster service with better quality of experience. At the same time, the amount of traffic across the ISPs is minimized – yielding higher network efficiency, lower delays, and ultimately, a decrease in cost for the VoD provider.

5. Integrated Application Performance Monitoring

Up to this point we’ve discussed techniques and tools embedded in ADCs that allow you to get more “good-put” out of your networks. However, network performance is impacted by unexpected challenges like slow links, unmanaged congestion, slow responding DNS, cyber attacks and much more. There are two ways to discover high delays in the network. The most common way is to hear from dissatisfied users who complain about slow or broken network connections. Another way is to monitor the end user experience.  Although this can be costly and complicated, user experience monitoring is important because the problem is not always in the network – the problem can also lie within the user’s device. 

Implementing an Application Performance Monitoring function in your ADC provides you with a bird’s eye view of the different elements comprising the user experience. It measures datacenter delay, network delay between the datacenter and the user, and collects information from the user about the actual time it takes for the application page to start functioning.

When combining this information with a good analytic tool, it’s possible to easily pinpoint performance bottlenecks in different parts of the network between the user and the server and in real-time, in order to proactively detect and troubleshoot network performance issues that often cause customer dissatisfaction.

In sum, while ADCs are often thought of as a tool that increases application availability and scalability, they also have key functionalities that can provide major improvements to network performance. But it’s not enough that the ADC has those capabilities – the ADC admin must be aware of those capabilities and enable them with the correct configuration in order to gain maximal performance improvement. And the only way to gain maximal improvement is by monitoring performance, which provides the necessary visibility and insight into all aspects of the application delivery process.

This post explores a set of best practices for those times when there’s a lot of money at stake because of the high volume of customers using your online business.

How to Keep Your eCommerce Running

Here are the top 5 tips to keep your eCommerce website running:

• Monitor, monitor, monitor. Ensuring high QoE and network availability requires attention to, and readjustment of, the network infrastructure. As a result, it is vital to monitor traffic levels on an ongoing basis and analyze them in comparison to seasonal peaks from previous years. That said, it’s imperative to define the SLA required for each application per location and monitor the actual transaction SLA, including the visibility of potential errors.




• Accelerate. It is highly recommended that businesses leverage application acceleration features that are available as part of the application delivery controller (ADC) solution, such as caching, compression and SSL acceleration. When it comes to SSL, ensure the solution supports 2k SSL keys, which are becoming the de-facto standard.

  But it’s important to note that today’s web applications are more complex. Tough development cycle deadlines mean that there’s not always enough time to optimize application performance. Leveraging an advanced Web Performance Optimization (WPO) solution, however, will accelerate the response time of your eCommerce applications over any web browser and any end-user device. In particular, WPO will save you the cost of having to manually optimize the application. This allows your development team to focus on the really important features and rollout an optimized application on time, which results in more conversions and higher revenues.




• Spread the load. Because a web traffic load might unexpectedly increase, it’s critical to spread the traffic in an intelligent manner. Therefore, it’s recommended to deploy an ADC solution, which not only delivers basic load balancing capabilities, but also employs advanced policies for traffic redirection, server offloading and bandwidth management, matching “regular” business days and “seasonal peaks.” In cases where the local network capacity is maxed-out due to traffic peaks, it is essential to be able to burst resources to the cloud and redirect the traffic there to avoid disrupting the quality of experience.




• Leverage configuration templates. When there is a seasonal shopping period, an online business can easily shift to an application delivery profile that optimally fits the changing network stress and user activity. For example, a seasonal shopping period typically implies more secured transactions (as opposed to regular non-SSL web site surfing) and as a result, it would make sense to give higher priority to SSL traffic in order to meet user demand. Our advice – prepare these configuration templates in advance so you can leverage them when needed.




• Think on demand. The old days of buying a solution that will address all of your upcoming needs are over. This implies that the risk of capacity planning is potentially much higher. With the move to virtual resources and cloud-based services, scaling on-demand is affordable and doable. Therefore, on-demand network services, such as load balancing and acceleration, allow businesses to scale network infrastructure capacity with minimal impact on active services – guaranteeing optimal online business execution. Using such as approach will eliminate hardware replacements and enable the best investment protection.

As we’ve seen, there are several challenges associated with guaranteeing high QoE. These include ensuring uninterrupted availability, providing sufficient capacity to process transaction peaks while delivering faster response time and guaranteeing that services can continuously operate even when under attack.

Unfortunately, these challenges become harder to address during seasonal shopping peaks. Expected and unexpected traffic surges that cannot be addressed by existing application and network infrastructure are the biggest threat to optimal performance. Employing the best practices discussed in this post will help your organization provide the capacity required during seasonal peaks, decrease the risk of losing the shopper and strengthen your business’s overall competitive position.

Time to first byte

What it means: Time to first byte is measured from the time a request is made to the host server to the time the first byte of the response is received by the browser.

Caveats: Time to first byte doesn’t mean anything when it comes to understanding the user experience, because the user still isn’t seeing anything in the browser.

When it’s relevant: For detecting back-end problems. If your website’s time to first byte is more than 100 milliseconds, it means you have back-end issues that need to be examined. (Web performance consultant Andrew King has written an excellent post about this, as has Google performance expert Patrick Meenan.)

Response time

What it means: Response time causes a lot of confusion. Depending on whom you ask, it can refer to any number of things: server-side response time, end-user response time, HTML response time, time to last byte with no bandwidth/latency, and on and on.

Caveats: If someone starts talking to you about response time, first ask them to clarify which type they’re referring to. Be wary of anyone who tries to sell you on the idea that there’s only one definition.

When it’s relevant: Different types of response time measurements tell you different things, from the health of your back end to the moment when content starts to populate the browser. You need to know what you’re measuring and why. For example, if user experience matters to you, ask how whatever type of response time you’re looking at relates to what the end user actually sees.

Start render

What it means: As its name suggests, “start render” indicates when content begins to display in the user’s browser. This term seems to have evolved as an alternative to “end-user response time”, but it’s not yet widely used outside performance circles.

Caveats: Doesn’t tell you if the first content to populate the browser is useful and important, or simply ads and widgets.

When it’s relevant: When measuring large batches of pages, or the performance of the same page over time, it’s good to keep an eye on this number. Ideally, visitors should start seeing usable content within 2 seconds. If your start render times are higher than this, you need to take a closer look.

Load time

What it means: This term is misused a lot — it frequently gets conflated with start render time. Properly defined, load time is the total amount of time it takes for all page resources to render in the browser — from those you can see, such as text and images, to those you can’t, such as third-party analytics scripts. (Geek version: “Load time” is also known as “document complete time” or “onLoad time”. It’s measured when the browser fires something called an “onLoad event” after all the page resources have fully loaded. No matter what you call it, it’s used as a primary measuring stick for site performance.)

Caveats: Needs to be taken with a grain of salt, because it isn’t an indicator of when a site begins to be interactive. A site with a load time of 10 seconds can be almost fully interactive in the first 5 seconds. That’s because load time can be inflated by third-party scripts, such as analytics, which users can’t even see.

When it’s relevant: Load time is handy when measuring and analyzing large batches of pages, because it can give you a sense of larger performance trends.

Above-the-fold time

What it means: In the past two years, there has been a growing awareness that the four terms discussed above are not adequate for conveying the real-user experience. Two recent Google initiatives — Speed Index and Above-the-fold time (AFT) — have attempted to define a new user-oriented metric that better represents the time when a significant amount of usable content renders in the browser.

Caveats: Unfortunately, there are technical constraints in gathering AFT metrics in the real world. As Google performance expert Steve Souders states of the initiatives described above:

“In other words, it’s not feasible to perform these rendering metrics on real user traffic in their current form. That’s important because, in addition to incorporating rendering, this new metric must maintain the attributes mentioned previously that make window.onload so appealing: standard across browsers, measurable by 3rd parties, and measurable for real users.”

When it’s relevant: Assuming that the technical hurdles will eventually be overcome, above-the-fold time could be the ideal metric for measuring when a page’s primary content has rendered in the browser — in other words, the optimal end-user experience.

Takeaways

1. There’s no single “right” way to measure performance. Each measurement tells you something meaningful about how your site performs.

2. You need to understand the different performance measurement terms so that you can interpret your own data. If you don’t, sad to say some people will take advantage of your ignorance to mislead you for their own benefit. (For example, some performance vendors have convinced site owners to tie bonuses for key employees to backbone test results, which do not measure real-world performance.)

3. As a matter of due course, you always need to gather large batches of data about your site’s performance and rely on median numbers. But you also need to periodically get under the hood – using tools such as WebPagetest* — and take a real-world look at how your pages behave for real users.

4. Currently, there is no perfect metric for measuring the optimal real-world user experience. This is something the performance community is working to address.

*WebPagetest is a third-party tool that simulates how fast a site loads for real-world users using a variety of browsers.

Why can’t firewalls and IPS handle DDoS attacks?

The simple answer is that they were not designed to do so. Firewalls and IPS focus on examining and preventing the intrusion of one entity at a time, but were not designed to detect the combined behavior of legitimate packets sent millions of times. Of course, this is a bit simplified. What follows, however, is a more detailed explanation of firewall and IPS shortcomings when it comes to effectively blocking DDoS attacks.

Firewalls and IPS are Stateful Devices

As stateful devices, firewalls and IPS track all connections for inspection and store them in a connection table. Every packet is matched against the connection table to verify that it was transmitted over an established, legitimate connection.

The typical connection table can store tens of thousands of active connections, which is sufficient for normal network activity. However, a DDoS attack may include thousands of packets per second. As the first device in the organizational network to handle the traffic, the firewall or IPS will open a new connection in its connection table for each malicious packet, resulting in the quick exhaustion of the connection table. Once the connection table reaches its maximum capacity, it will not allow additional connections to be opened, ultimately blocking legitimate users from establishing connections.

DDoS mitigation devices, on the other hand, include a stateless protection mechanism that can handle millions of connection attempts without requiring connection table entries or exhausting other system resources.

Firewalls and IPS Cannot Distinguish Between Malicious and Legitimate Users

Certain DDoS attack vectors such as HTTP floods, are composed of millions of legitimate sessions. Each session on its own is legitimate and it cannot be marked as a threat by firewalls and IPS. The problem of course is that firewalls and IPS were not designed to look at the behavior of millions of concurrent sessions as a whole, but only to examine individual sessions. This eliminates the ability to identify an attack composed of millions of valid requests.

Firewalls and IPS Possess an Inappropriate Network Location

Firewalls and IPS solutions are deployed too close to the protected servers and are not deployed as the first line of defense. However, this is precisely where DDoS attacks should be mitigated. The result is that DDoS attacks go through the protected data center without being detected by the traditional network security solutions. A dedicated DDoS mitigation solution, on the other hand, would be deployed even before the access router at the ISP hand-off, enabling the early detection of an attack.

There is no doubt that the increasing use and sophistication of DDoS attacks has fundamentally changed the security landscape. As organizations adjust their security architecture to effectively mitigate the rise in availability-based attacks, there is no question that the tools they deploy must continue to evolve as well. While firewalls and IPS continue to play an important role in protecting the network, today’s threats require a holistic solution that can secure the network and application’s layers, as well as effectively distinguish between legitimate and illegitimate traffic to keep organizations up and running.