September 2013 Archives

Every morning I scan the news headlines for stories that may have an impact on Akamai customers and the wider security community. Today I direct you toward five items worth keeping an eye on.

Data Broker Giants Hacked by ID Theft Service
By Brian Krebs, Krebs on Security
An identity theft service that sells Social Security numbers, birth records, credit and background reports on millions of Americans has infiltrated computers at some of America's largest consumer and business data aggregators, according to a seven-month investigation by KrebsOnSecurity.

Recycled Yahoo Email Addresses Still Receiving Messages for Previous Owners -- Passwords Included
By Lee Munson, Sophos Naked Security blog
Yahoo announced in June 2013 that it was going to recycle inactive email addresses by giving them to other users who wanted them. Security experts and other critics raised concerns about Yahoo's plan at the time, and sure enough, some new owners of recycled accounts have received messages of a sensitive nature.

Researcher: Exploit kits revolutionize automated malware production
By Brandan Blevins, SearchSecurity
In the past, producing a unique malware sample was a time-consuming process that required knowledge of both programming and security systems. Now, a researcher has shown how automation has revolutionized malware production, turning it into a trivial pursuit for even novice attackers.

Social media, mobile phones top attack targets
By John P. Mello, Jr., CSOonline
Social media has become a top target of hackers and mobile devices are expanding that target, IBM reported on Tuesday in its X-Force 2013 Mid-Year Trend and Risk Report.

Banks Plan National Cyber-Attack Drill
By Tracy Kitten, Bankinfosecurity
More than 1,000 banks will test their incident response strategies by participating in a simulated cyber-attack exercise. SWACHA's Dennis Simmons says the drill, which is open to more participants, will help bolster defenses.

The following is a guest post from Enterprise Architect Matt Ringel, Senior Enterprise Architect Joseph Morrissey and Enterprise Architect Manuel Alvarez.

This is a follow up post to the Boston Web Performance Meetup presentation by the Professional Services team - The Render Chain and You.

There are many factors that affect your site performance and one of the less discussed ones is the Rendering Engine.  There are a lot of smart people developing browsers, why should you care about how your page renders?  The reason is simple: the rendering engine is using rules to paint your site and if you do not follow them, it will penalize you by slowing you down.

The Rendering Engine is a component of the browser in charge of displaying the requested content.  The most common rendering engines, Gecko (Mozilla), WebKit (Safari), old versions of Chrome, and newer versions of Opera) and Trident (IE), follow a similar flow:

Figure 1 Rendering engine flow

At a high level, as soon as the HTML has been retrieved it is sent in chunks to the Rendering Engine.  The Rendering Engine will parse the HTML and create the DOM, every element of the HTML will have a corresponding entry in the DOM.  Styling information from the CSS along with the visual attributes defined for the elements in the HTML are combined to create the render tree.  The render tree is then parsed and the exact coordinates/location of each element in the window is calculated.  The render tree is traversed and each element is then painted onto the screen. 

The process is not as straightforward as it seems.  The Rendering Engine follows defined rules to support the dynamic and evolving nature of websites; for example, an script adding stylesheets causes the page to re-flow as coordinates might need to be adjusted.  Another example is that if a <SCRIPT> tag is encountered, parsing of the HTML may pause while the script executed.  If the script is external, then parsing pauses until the script is pulled from the network. 

Matt Ringel and Joseph Morrissey discussed these rules at the Boston Web Performance Meetup in August and they have summarized them here for you: 

The One Rule of Rendering

Anything that introduces uncertainty into how the page should be rendered will block rendering until it's resolved.

If the Rendering Engine does not know how the page will be rendered (CSS), it is waiting for an asset (long load time), or suspect that the render tree might change (Javascript) then it will not render the page.

 

Rule #1: Scripts Block Parsing 

• Posit: JavaScript is a single-threaded environment¹, and JS files have the potential to change the DOM.
• Consequence: The render chain blocks because there's uncertainty in how the page is rendered.
• Result: If you have a large amount of JS to parse, the browser will sit there parsing it all without putting a pixel to the screen.
• Conclusion: Don't do that.  Use async/defer where you can.

Rule #2: Style Sheets Block Rendering

• Posit: Anything that can force a re-flow of content (font changes, different margins for certain elements, etc.) will introduce uncertainty.
• Consequence: Browsers will block rendering a Web page until all external style sheets have been downloaded².  (cf. The One Rule).
• Result: If you have style sheets interspersed with content or inline in your document, rendering will stop until they're integrated with the DOM.
• Conclusion:  Pare down the amount of CSS you have to what you're using, and put it all in the <head> of the document.

Rule #3: Less Caching, More Problems.

• Posit: The fastest load time is when the browser already has the data.
• Consequence: Origin hits cost time and is distance-based.
• Result: Non-cacheable content creates high variability in page load time.
• Conclusion: Cache browser-side if possible and consider using a CDN.

During the Boston Web Performance Meetup event, our speakers took a look at the top five rendering issues affecting e-Commerce sites by using these rules.  You can watch their findings  or download the presentation here.

¹ HTML5 JavaScript Workers change this a bit

² CSS "print" styles or non-matching media selectors will not block because they're not immediately applicable

Edge is a must-attend event for global Internet business leaders looking to take their online operations to the next level. In addition to great networking events and amazing speakers, Edge connects you with the tech experts and innovation engineers who are available for hands-on lab sessions, 1:1 consultations, or an informal chat. All have the insight and know how to address your technical challenges head-on - no matter what they may be. 

There are several important security conferences this week and this coming weekend, and Akamai InfoSec will participate in all of them. 

Earlier this month, I told you about the second phase of efforts to raise Akamai's profile as a security company. This post is an update on the last goal I mentioned: creating a security page on the Akamai website.

In this week's Akamai Security Podcast, I talk to Larry Cashdollar, a senior security response engineer on our CSIRT team. Larry discusses the mechanics of his job and the particular threats he and the team have been tracking and defending against.

Listen here.

Most of the readers of this blog already know Akamai and our connection to e-Commerce.  We've been helping IR 500 companies accelerate traffic for 15 years.  Today 96 of the Top 100 retailers (as measured by Internet Retailer) take advantage of the Akamai Intelligent Platform to optimize content and deliver traffic.  

What many of you may not know is that in addition to delivering performance, Akamai also protects etailers from the threat of Denial of Service attacks and data theft.  We are able to do this precisely because of the architecture of our platform.  We have servers delivering traffic in 1100 different networks, in more than 650 cities, and 74 countries around the world.  That is why, after all, we are able to cache, optimize, and deliver Web experiences for our customers.  But that is also how we are able to prevent downtime by blocking Denial of Service attacks and prevent data theft by inspecting traffic for SQL injections and cross site scripting.  We are close to end-users, and we are also close to attackers.  So we block attacks far away from your Web server and away from your data center, at the edge of the Internet. 

We like to think of our services as akin to the concept of the "Bouncer and the Concierge".  The concierge is the perform part of our offering.  The concierge greets people at the door and ensures that real customers get what they need as quickly and painlessly as possible.  But the concierge is also skilled in the art of "filtering."  The concierge can spot an intruder, keep a certain class of intruders out, and in some cases minimize the damage that an intruder can do to other customer's experience.  And the concierge works hand in hand with the bouncer - the "Protect" part of our offering - communicating with him regarding visitors and potential attacks.  And vice versa.  The "Bouncer" distinguishes real customers from rabble rousers and keeps the latter at bay - just as the Akamai platform distinguishes good traffic from malicious traffic and blocks the malicious traffic from ever accessing the Web site. 

So what does this mean in practice for existing Akamai "Protect" customers?  Akamai customers are protected against, first and foremost, attempts to steal data from Web applications and Web sites.  Our Web Application Firewall, after all, is installed in every one of our 140,000 servers around the world, and thus can inspect incoming requests for information in order to separate legitimate users looking to browse or purchase from illegitimate requests looking to "scrape" information for competitive advantage or steal credit card credentials for later sale on the black market.  Akamai customers are also protected against "Denial of service" or "DoS" attacks.  These attacks are perpetrated by hackers who are motivated by a variety of desires - financial, political, or simply "glory."  Denial of Service attacks attempt to serve more traffic to a Web site than it can handle in order to cause the Web site to crash.  

You may have heard the recent press reports about high profile attacks against banks and e-Commerce sites in the past year.  Akamai is uniquely positioned to protect against this kind of attack because it is inline (present in all 140,000 servers in the Akamai Intelligent Platform), always on, and has unmatched scale.  In fact, one attack against retailers that Akamai defended against saw 1 - 10k spikes in traffic against 5 separate customers in a coordinated attack designed to harm the US economy as a whole.  Akamai detected the attack and was able to prevent crashes.  In doing so, Akamai averted 15M USD in lost revenue for our customers.

That, by the way, is only the loss that would have occurred as a result of direct opportunity cost - downtime.  It does not calculate the loss to brand value or the potential loss due to regulatory fines as a result of data exposure.

So the nature of our Intelligent Platform allows us to protect against both Web site downtime and data theft.  The other advantage that the platform brings is visibility into trends.  Because we see 15% to 30% of the world's Internet traffic, we see attacker trends well before they take hold and are able to mitigate them before they do damage to our customers.  One recent example of this is the "Account Checker" attacks that has been covered previously on this blog and elsewhere.

Please join us on Sept 26^th at 11 AM ET for our next "Crush the Rush" holiday readiness Webinar to learn more about how to protect your site and holiday season revenue.  Mike Smith, director of our CSIRT Team, and myself will be detailing the types of attack trends that Akamai is seeing, and ways in which other customers have mitigated the latest threats.  Click here for more details.

A researcher at Cisco Systems published a blog post yesterday that Akamai customers and the larger security community should be aware of. The subject: "watering-hole" attacks.

It's something Cisco researchers -- and Akamai's CSIRT team -- have been tracking for some time. In May, Threat Research Engineer Jaeson Schultz wrote about the increasing popularity of the attack technique. 

He wrote at the time, "Watering-hole attacks, as evidenced by the recent attack involving the U.S. Department of Labor, are becoming increasingly popular as alternatives to attacks such as Spear Phishing. In a Watering Hole attack, the attacker compromises a site likely to be visited by a particular target group, rather than attacking the target group directly. Eventually, someone from the targeted group visits the 'trusted' site (A.K.A. the 'Watering Hole') and becomes compromised."

Threat researcher Emmanuel Tacheau's post from yesterday provides updated data on who these attacks are targeting and the methods used.

Beginning in May, he wrote, Cisco TRAC started to see several malicious redirects targeting the Energy & Oil sector. The structure, he said, consisted of several compromised domains, of which some play the role of redirector and others the role of malware host. Watering-hole style domains infected with the malicious iframe included:

• An oil and gas exploration firm with operations in Africa, Morocco, and Brazil;
• A company that owns multiple hydro electric plants throughout the Czech Republic and Bulgaria;
• A natural gas power station in the UK;
• A gas distributor located in France;
• An industrial supplier to the energy, nuclear and aerospace industries; and
• Various investment and capital firms that specialize in the energy sector.

"Encounters with the iframe injected web pages resulted from either direct browsing to the compromised sites or via seemingly legitimate and innocuous searches," he wrote. "This is consistent with the premise of a watering-hole style attack that deliberately compromises websites likely to draw the intended targets, vs. spear phishing or other means to entice the intended targets through illicit means."

Akamai CSIRT Director Michael Smith said that in watering-hole attacks, the bad guys attack one's website to use it as a platform to attack the browser. 

"The interesting thing with energy-sector websites is that they usually service a particular geography, say the NE United States or France," he said. "Energy sector websites also sometimes are supplier portals for a particular vertical such as gas companies."

Since Akamai deals with the server side of the watering hole equation, we have a set of recommendations for our customers:

• Use our Web Application Firewall with cross-site scripting (XSS), command injection, and SQL injection rules in deny mode.
• Protect access to your Content Management System as a high-criticality system.
• Restrict access to content and CMS to specific geographies.
• Look at third-party content (such as advertising services) and have a plan to disable that content if the provider becomes compromised.
• Secure your DNS registration and name servers to keep attackers from redirecting the entire domain to an arbitrary location.

A few days ago I told you about all the security awesomeness planned for the Akamai Edge customer conference. Today, I'm delving deeper into the agenda for a look at the more technical talks.

Now for that deeper dive...

Wednesday, Oct. 9:

Noon-1:30 p.m.: Financial Services Roundtable Lunch: Security Information Sharing - Lessons Learned from Financial Services: Join us for our annual financial service luncheon and roundtable discussion. This year's topic will include speakers from the FS-ISAC (Financial Services Information Sharing and Analysis Center), USAA, and TD Bank. Come learn about the FS-ISAC, and hear how the financial services industry shares threat intelligence to protect critical systems and assets. Take part in the conversation, share your experiences, and network with your peers. The session is open all conference attendees. Commerce, High Tech and other Akamai customers are encouraged to join and learn how the banks share cyber threat intelligence.

Discussion leaders:

Rich Bolstridge, Akamai, Chief Strategist, Financial Services

Denise Anderson, FS-ISAC, Vice President, Government and Cross-Sector Programs

Don Clemmons, USAA, Technical Fellow

Dave Grau, TD Bank, Head of Threat Response, Intelligence, and Defensive Technologies

2:20-3 p.m.: Developers' Lab II: Akamai Observed Attacks and Mitigation Techniques - A Real-time Demonstration

4:20-5 p.m.: Government Forum Keynote by Joel Brenner, NSA, Former Senior Counsel - Glass Houses: Privacy, Secrecy, and Cyber Insecurity in a Transparent World

5:15-5:45 p.m.: Main Stage Partner Keynote: Observations on Modern Cyber Crime and Espionage

Thursday, Oct. 10:

10:30-noon: Kona - Web Security Roadmap: Gimme Shelter - How Kona Site Defender, IP Defender, and Cloud Security Intelligence Will Help You Weather Cyber Storms in the Coming Year: Explore the latest attack trends, from the Russian Business Network and the Al Qassam Cyber Fighters to Vietnamese Carders and Account Checkers. Learn how to tune rules to avoid "noise" and capitalize on the latest rules created to help protect customers across the Akamai Intelligent Platform. Discover how to implement the newest Kona Site Defender features and what features are still to come in 2013. Learn about how Kona IP Defender will extend protection to your entire data center. Hear how the User Validation Module has successfully defended against Account Checkers at the some of the largest eCommerce sites in the world. Understand how Cloud Security Intelligence will lead to even greater sets of rules in the future.

1:30-2:10 p.m.: Security Keynote: A Conversation with Bruce Schneier

1:30-2:10 p.m.: Developers' Lab II: Leveraging Akamai's Kona Security APIs

2:20-3 p.m.: Security Panel: Operation Abibal, Anniversary Panel - What We Have Learned: Launched in the fall of 2012, Operation Ababil has been the most visible and sustained battle in the security landscape. This well-funded, well-organized adversary has caused loss of business for many financial institutions and loss of sleep for a great many more. This panel will consist of a conversation with information security leaders from several institutions discussing what lessons they have drawn from the past year's response and practices they have put into place that have improved the security posture of their organizations and from which others can benefit. Confirmed panelists include David Cripps, CISO, Investec, Denise Anderson, Vice President Programs and Services, Financial Services Information Sharing and Analysis Center (FS-iSAC)

2:20-3 p.m.: Developers' Lab II: Akamai Observed Attacks and Mitigation Techniques - A Real-time Demonstration

3:30-4:10 p.m.: Security Tech Session: Big Data Intelligence - Harnessing Petabytes of WAF Statistics to Analyze and Improve Web Production in the Cloud: As web application attacks turn into massive campaigns against large corporations across the globe, web application firewall data increases exponentially, leaving security experts with a big data mess to analyze. Pinpointing real attacks in a sea of security event noise becomes an almost impossible tedious task. In this presentation, we will unveil a unique platform for collecting, analyzing and distilling Petabytes of WAF security intelligence information. Using the collected data, we will discuss the OWASP ModSecurity Core Rule Set project's accuracy, and reveal common attack trends, as well as our impressions and suggestions for how to wisely make the best out of the CRS project.

3:30-4:10 p.m.: Commerce Security Threat Briefing with Akamai CSIRT Director Mike Smith

Friday, Oct. 11:

9-9:40 a.m.: Security Session: USAA - Optimized Kona Site Defender and Real World Usage: Web attacks - they aren't something to fear, they are something to expect and prepare for. Please join Josh Stevens and Neelsen Cyrus, Senior Security Analysts at USAA, to hear how their team has leveraged Akamai Kona Site Defender to stop attacks while preserving site performance and availability. The team will focus on operational efficiencies gained by replacing error-prone, manual WAF updates with automation using Akamai's Network List API for Network Layer Protection.

9:50-10:30 a.m.: Security Session: The Many Dimensions of Web Security

9:50-10:30 a.m.: Developers' Session I: Leveraging Akamai's Security APIs

The following is a guest post from Director Global Service Delivery Patrice Boffa and Associate Solutions Architect Seema Puthyapurayil.

We know that the average page size tends to increase overtime; we can confirm this statement using the available Web performance data in Google BigQuery and HTTP Archive. 

Analyzing the HTTP Archive data for + 300,000 popular sites in the last nine months, we can validate that the average page size increased by about 20%.

Total Bytes per Web site

Being the market leader we are constantly challenged to prove our acceleration services can improve the performance of any Web site. 

What public data is available to validate the fact that Akamai can make Web site faster even if they improve their page sizes?

To answer the question, we query HTTP Archive for the latest 1,000 Web sites that started using Akamai services in the last nine months. The HTTP Archive recorded the Web sites information twice a month and we analyzed the data before and after turning on Akamai services for those 1,000 Web sites. 

Fully loaded time

We decided to focus on "Fully Loaded time" that is measured as the time from the start of the initial navigation until there is 2 seconds of no network activity after Document Complete.  This will usually include any activity that is triggered by JavaScript after the main page loads.

The results for those 1000 Web sites show about a 35% fully loaded time improvement, it's a good number but we were expecting better.

Total Bytes per page

We also looked at the "Total bytes" per page to validate that if we were comparing "Fully Loaded time" numbers, we were actually downloading the same amount of data with Akamai than without Akamai.

The analysis results show on average a 4% increase in the page size the month after customers start using Akamai. 

SpeedIndex

The last metric we decided to look at is the "Speed Index", the Speed Index measures rendering speed; it's the average time (in milliseconds) at which visible parts of the page are displayed in the user browser. This gives a measurement around the user's perception of Web site speed.

The data shows on average an improvement of 12% of the Speed Index if we compare the before and after Akamai.

Akamai Professional Services team is key in helping customers get the most performance from their Web sites, by assessing their current applications and advising on the high performance best practices observed across the industry, tailoring them to our customers specific initiatives while helping them accomplish their performance goals efficiently.

Yes - you can increase the size of your page without affecting your performance by using Akamai delivery services. The analysis of a larger sample of Web sites (1,000 sites) over the last nine months using public accessible data (HTTP Archive and Google BigQuery) validated that Akamai services have successfully accelerated Web sites performance. The two main conclusions are that Akamai improves:

• Akamai improves the overall Fully loaded page times and the Site Speed Index considerably. 
• The improvements of those two indicators seem to allow our customers to provide a more rich experience to their end-users by increasing the Total Bytes per page.

A couple weeks ago, Akamai's CSIRT team warned that chaotic actors could use the anniversary of 9-11 and news of potential military action in Syria as an excuse to unleash a fresh wave of DDoS attacks. 

The SEA was quiet, and I believe that's because of a combination of not having a good excuse for actions agains the US while the US was debating Syria, and they might have been involved in OpIsrael Reborn. A substantial number of middle eastern hackers were involved in OpIsrael Reborn, which was just as effective as the last OpIsrael, which is to say not very. It seems most of the attention is focused on targets other than the US right now. QCF remained dormant. They haven't done anything of note since declaring Phase 4 in late July. 

I really was expecting more, honestly, but is seems the Syria negotiations and a few ops kept everyone distracted from the US.

I recently spoke with Meg Grady-Troia about her role in Akamai InfoSec, particularly the security training she does for new hires. 

At this year's Akamai Edge Conference, taking place Oct. 7-11 in Washington DC, security will be a central part of the agenda.

One of the three tracks this year is a Web Security Symposium, tailored to meet the needs of security professionals looking to protect their organization from unwanted network or application layer attacks, while improving the exchange of information between employees, customers and business partners on any device, anywhere. Topics include:

• Developing strategies to secure your data, sites and applications
• Security without compromising performance
• Web security customer panel discussions
• Managing enterprise global security in a hybrid cloud environment
• Mobile security insights and best practices

Security heavyweights are featured prominently on the keynote roster.

There will be the Financial Services Roundtable Lunch on Security Information Sharing: Lessons Learned from Financial Services, and Former NSA Senior Counsel Joel Brenner will share his insider perspectives on the implications of our global reliance on the inter-connected and Internet-dependent way of life and how to address "the new faces of espionage and warfare on the digital battleground."

There will also be a keynote discussion with Bruce Schneier, founder and CTO of BT Managed Security Solutions, and Akamai CSO Andy Ellis will lead a panel discussion on the lessons of Operation Abibal.

Akamai CSO Andy Ellis offers more of an overview here:

We look forward to seeing you there!

The following is a guest post from Senior Enterprise Architect David Senecal and Sr. Solutions Architect Aseem Ahmed

Recent years have been very dramatic in security landscape with emerging threats; the application layer is now a more prominent target.  The new (and deadly) Layer 7 attacks called slow HTTP Denial of Service (DoS) attacks are on the rise.  Although they are not as new as they might sound, anything that is not frequently spoken of in the security world is often new!

In my experience, the common perception of DoS is a volumetric attack that occurs quickly, not slowly.  Traditionally, DoS/DDoS attacks have been volumetric, required a large number of clients and could be geographically distributed.  But slow attacks that consume minimal resources/bandwidth from the attacker side can still bring down your Web server. 

Here are the results of using slowhttptest against a vulnerable apache server in our lab environment.  The snippet below shows the tool in action where new connections are established very quickly with the server.  The Web server becomes unavailable after 5 seconds of launching the attack.

The HTML screenshot below shows the results of the same test.  The tool opens 1000 connections with rate of 200 connections per second, and the server is able to concurrently process only 351 connections, leaving the remaining 649 connections pending. 

Why is this a problem?

• These connections look like legitimate user connections.
• Traditional rate detection techniques will skip them.
• Existing IPS/IDS solutions that rely on signatures will generally not recognize them either.
• They require very few resources and little bandwidth for execution.
• Such attack can bring down a Web server, irrespective of its hardware capabilities.

How do these attack work?

Slow HTTP DoS attacks rely on the fact that a Web server will faithfully honor client requests.  The attacker's motive is to send a legitimate-looking request to keep the server resources busy handling said requests for the longest time possible. If the attacker keeps adding to such long-ended requests, the server can quickly run out of resources.

Slow HTTP Denial of service attacks have different variants, but before we get into the details, let's review the normal HTTP structure and flow:

Request

Headers POST /account/login HTTP/1.1 CRLF Accept: */* CRLF Content-type:  application/x-www-form-urlencoded CRLF Content-Lenngth: 60 CRLF Connection: keep-alive CRLF Host: www.customer.com CRLF User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:22.0) Gecko/20100101 Firefox/22.0 CRLF

Body email=customer%40account.com&password=mypasswrd

 

Response

Headers HTTP/1.1 200 OK CRLF Server: Apache/2.2.22 (Ubuntu) CRLF Content-Type: Text/html CRLF Content-Length: 200 CRLF Date: Fri, 12 Jul 2013 05:31:32 GMT CRLF Connection: Keep-Alive CRLF

Body <html>    <head>    .....   </head> </html>

Long before coming to work here, I knew Danny Lewin was co-founder of Akamai and that he died Sept. 11, 2001. But that was about all I knew. Then I got a tweet from Ben Rothke, manager of information security at Wyndham Worldwide Corp., suggesting that Lewin's story needed to be retold. Since I was now at Akamai, he said, I was the man to do it.

Emotions will already be high next week with the 12th anniversary of the 9-11 attacks. On top of that, Congress is expected to debate and possibly authorize military action in Syria. This has Akamai InfoSec's CSIRT team on high alert.

The SEA attacks primarily via social engineering. In the past month they were able to compromise a DNS registrar and modify DNS zone files as well as an advertising network in order to insert malicious javascript. While normally DOS attacks consists of traffic floods to a target, the SEA is adept at denying access to web servers without directly attacking the target.

Akamai recommends the following steps to prevent similar attacks:

• Place a transfer lock on your domain registration 
• Be ready to delete or shut off any trusted third-party content on your sites, in the event they are compromised
• Be more vigilant monitoring the health (and existence!) of your websites
• Remind employees to be wary of social engineering and phishing attempts 
• Ensure that key personnel is available and ready if a situation does arise

In addition to the SEA, we believe that other organizations will take advantage of the political situation and proximity to 9-11 to launch attacks. 

Al-Qussam Cyber Fighters (QCF) have not attacked as expected during Operation Ababil phase IV, but they have been maintaining the Brobot botnet and recruiting new nodes. It is possible that the QCF will attack again in the next week, hoping to take advantage of the confusion of other attackers. The QCF is primarily interested in targeting financial institutions, banks and brokerages with volumetric DDOS attacks. Firms in this sector should be prepared for the possibility of attacks by the Brobot botnet. 

Members of the Anonymous hacktivist collective are working to gather support among Muslim hackers for OpIsrael Reborn and threatening attacks on both Israeli and US websites.

Other attempts at widespread disruption by Anonymous in both OpIsrael and OpUSA had only minimal success with website defacements using cross-site scripting (XSS) and data exfiltration via SQL injection, but companies should be prepared for these kinds of attacks as well.

The confluence of the anniversary of 9-11 and the possibility of a declaration of US intervention in Syria makes next week an especially tempting one for hacktivists. Any organization with a web presence should make preparations to defend themselves from:

• Volumetric DDOS attacks
• Social engineering and phishing attacks
• Attacks via third party code
• Attacks on DNS infrastructure.

Just when I thought the trend toward smaller, more efficient mobile computing was taking us in a greener direction, a recent study by the Center for Energy-Efficient Telecommunications (CEET) finds, in fact, we're creating a monster. To date, attention to the rapidly expanding energy consumption and concomitant carbon emissions of the Internet has been focused on data centers. A New York Times series targeted the data centers of major Cloud players such as Google, Facebook, Microsoft and Apple to reveal the power hungry and polluting nature of the Internet - 2% of the world's energy and growing. Greenpeace in its "How Dirty is Your Data" and "How Clean is Your Cloud" reports also exposed the energy- and carbon-intensiveness of data centers. To their credit, the major Cloud players, including Akamai, have responded and are leading the way to unprecedented efficiency, and even powering with renewables.

But as we've been busy scrutinizing data centers, a new power-intensive infrastructure component is emerging: wireless. Traditionally, we accessed the Internet from PC's tethered to Ethernet cables, hard-wired into the Cloud. Most of our content and applications lived on our computers or on company servers. Now, thanks to advancements in ubiquitous wireless technology and smart, mobile clients, we've been unleashed, free to roam, to access our videos, music, documents and applications anytime, anywhere. Smart phones and tablets have given us compute power at a fraction of the energy and clunkiness of PC's. This evolution has brought us unprecedented convenience and flexibility.   

Now we come to find that all this freedom and convenience has come at an energy and environmental cost according to the CEET study, The Power of Wireless Cloud. Most surprising and concerning is that by 2015 wireless infrastructure, including technologies such as WiFi and 4G LTE, will account for 90% of the total energy consumption of the wireless cloud, while data centers supporting mobile users and their Internet activities will represent only 9%. Energy consumption of the wireless cloud will grow 460% from 9.2 TWh in 2012 to 43 TWh in 2015, resulting in a 24-megatonne increase in CO2 emissions, the equivalent of adding 4.9 million cars to the roads.

 

 

Source: The Power of Wireless Cloud, Centre for Energy Efficient Telecommunications, Bells Labs and University of Melbourne

And that might be a lowball estimate. A 2011 study (G. Auer, Oct. 2011) cited by CEET estimates the contribution of just the 4G LTE infrastructure at 80 TWh. Akamai's most recent State of the Internet report supports this prediction of rapid growth in energy consumption indicating that mobile (2-4G only) web traffic has been doubling year over year since 2007.

 

Source:  Akamai State of the Internet Q1 2013 report.  Traffic data does not include Wi-Fi, DVB-H and Mobile WiMax).

While the wireless cloud is only a small fraction of the Internet's total estimated 260 TWh of energy consumption today, we can only expect the transition to an untethered world to continue. The question is will the energy consumption of the wireless infrastructure dominate the total as predicted? Even at something substantially less than domination, that's still a lot of energy. And, like power-hungry data centers, unless that energy comes from renewable sources, it will be contributing to ever increasing greenhouse gas emissions which we cannot afford at any level of convenience and flexibility.

But there are also some things we can do in the meantime. Helping to make the transmission of wireless traffic more efficient will help. For example, a feature of Akamai's Aqua Ion offering is support for "suppressed header for uplink traffic reduction" (SHUTR), developed by Qualcomm Technologies, Inc. This HTTP protocol extension reduces the size of HTTP headers sent by mobile phones which in addition to improving browsing speeds reduces mobile data traffic. It's definitely a start.

 

Nicole Peill-Moelter is Akamai's Director of Environmental Sustainability

This October at the Edge Global Conference I'll be joined by technology visionaries from a wide range of industries and organizations discussing topics related to creating cutting edge experiences ... faster. 

I'm specifically excited to share details about the new Developers' Track we'll be introducing. We have some fantastic presenters lined up, including Geoffrey Moore - Author and Business Strategies; Gene Kim - VisOps Author and Entrepreneur; Jason Grigsby - Mobile Web Evangelist; and Josh Clark - Mobile Design Strategist, talking about stimulating topics ranging from DevOps to responsive design, and discussing steps toward adopting these cutting-edge development methodologies.

 

And, of course, beyond that we will share new information about Akamai product roadmaps, discuss best practices, and network with an incredible group of peers whilesharing a beer together after the sessions.

 

Stay tuned and I look forward to seeing you at Edge 2013.

 

Guy Podjarni

Vice President, Chief Technology Officer, Web Experience , Akamai

One of the challenges of working in the security community is that you are expected to be fully aware of risk at all times. But as humans we all slip up sometimes. I was reminded of that yesterday when I helped out with a training session for new Akamai employees. I've been in this profession for a long time, and have found myself on the receiving end of blistering criticism plenty of times. It's a simple byproduct of the job. And yet I had to know who was spreading bad rumors about me. And I had to know right that second. I clicked the link and got a slow-loading site that ended in a request for my Twitter username and password. Another huge red flag. But someone was out there spreading rumors about me, you see, and I had to know what it was. So I plugged in my credentials.

The following is a guest post from Senior Solutions Engineer Eric Mingorance

* This is the third blog post to our "Crush the Rush" holiday readiness webinar series

Christmas started in July this year. Not just because "Drugstores ‛R Us" and the "ShopMarts" of the world are ever expanding the holiday window in hopes of more consumer revenue, but because Online Marketing, IT, eCommerce and Network departments in the Internet-retail-world started preparing for the traffic peaks and online overload.

Estimating load, capacity, and throughput, has become the holiday gamble that determines the trifecta payout from the lost investment wager. The thinking is "If you build it (and promote it) they will come!" However we all know that greater traffic brings greater challenges. 

Those higher and longer traffic peaks tax your Web site infrastructure and stability. There's also a need for greater order velocity and the potential for back-end system overload. Unfortunately this degradation can affect end-user performance.

To top it off, all the extra marketing & advertising dollars spent simply means that more eyes are upon the tech team internally and externally. There's not only an expectation to perform, but higher scrutiny over the ROI of the large investments made...and of course there's a high opportunity cost of poor shopping experience.

All this holiday traffic is also affecting your third party vendors and SaaS providers, which can result in issues affecting your site performance and experience. Brand degradation, bad press, loss of loyalty all go beyond just the loss of revenue.

In our Services webinar, we covered some of the best practices for preparing for the online holiday season commerce conundrum.

We shared our experience from working with 96 of the top 100 online retailers - what we've learned over the years and from our customers, from load testing to shoring up security.

• What systems should you baseline and monitor? 
• Where can you get data and clues about the weakest link in your infrastructure? 
• How should you focus resources where they'll be in most demand? 
• What should you prepare for, who will execute the plan, and where will it be documented?

We also shared insights that should be valuable with or without the use of a CDN (Content Delivery Network) including managing search engine or channel bots as well as throttling traffic under load.

Last year we saw over 700 attacks on our customers, and the industry attacked the most was Commerce - even more than what we saw in the financial sector and 7 of the top 10 world banks use Akamai.

While another Crush the Rush webinar specifically covers Defending against a DDoS Attacks we still touched upon security planning and strategy from a high level for the holiday season. 

• Is your IDS, WAF or Firewall a bottle neck for good traffic as well as bad? 
• Who has the authority to turn on on/off security protection depending on if it's helping or hurting? 
• Is that person working on Black Friday and Cyber Monday? Are they even reachable?

We discussed benchmarking performance metrics, setting up alerts, and monitoring, along with having an incidence response plan. 

We also talked about how to prepare for downtime, from hot-hot datacenters to DR and a failover plans. How to manage traffic and plan for back up branded experience in the cloud. We talked about failover actions to 4xx and 5xx response codes as well as shifting anonymous traffic to a branded waiting experience under heavy load while end-users with items in their cart can use the limited resources to check out.

Click here to watch the 45-minute video-on-demand and please feel free to email us with questions or comments. We'll respond even in to the holidays - but time is ticking to get proactive as holiday code freezes are just around the corner.

Three months ago when I started at Akamai, I told you the goal was to tell some Akamai InfoSec stories and make it clear how A.) we make sure our own house is secure, and B.) we provide an ironclad defense for customers. Here's an update to explain how we're doing that.