Akamai Diversity
Home > November 2013

November 2013 Archives

Four Things to Ask Before Seeking FedRAMP Certification

Part 3 in a series.

A few months ago I told you about how Akamai achieved FedRAMP certification and how, in our opinion, it was a very big deal. To understand what FedRAMP is and what certification means for Akamai's security program, see the post, "Akamai FedRAMP Compliance is Huge for Security."

After you read that, understand this: The path to certification is hard. All compliance efforts are difficult, of course. But FedRAMP presented its own special challenges. We learned a lot along the way.

For a look at how we reached this point, I spoke with Akamai InfoSec's Kathryn Kun, the program manager who played a critical role in getting us certified. Kathryn was one of the main lines of communication between Akamai and the FedRAMP Joint Authorization Board (JAB).

For others looking to achieve FedRAMP certification, there are four questions that must be addressed up front.


  1. What are the limits you need to define? As with any compliance effort, the auditors will want as much data as they can get their hands on. That's understandable. But many requests will cut too close to the safe holding your company's secret sauce. Before embarking on this journey, define the items that sit on the other side of the line that can't be crossed. If you're up front about it, the rest of the process can go more smoothly.
  2. Are you prepared to find a middle ground? Defining the limits is all well and good. But few things ever get done between two sides without some compromise. Be prepared to articulate the middle ground you're willing to meet at. An example for us involved FedRAMP's interest in network scanning. Akamai doesn't generally allow third-party scanning software on its boxes because it can hurt performance. Therefore we compromised on what scans, when, and how often, while offering a detailed explanation of our ongoing vulnerability management procedures.
  3. Are you prepared for the length of time the certification process will take?  We started the process of getting FedRAMP certification in early 2012 and the process took a year. To expect quick results is to be easily disappointed. Besides, the quickest way isn't always the best way. 
  4. Are you prepared for the long haul? Once you are certified, there's a lot of painstaking work that is ongoing for the sake of upkeep. You have to decide what types of scans you're willing to run and how often. You have to determine how often you're willing to rotate an SSH key in front of an assessor. In other words, once certified, the process is only beginning. The good news is that you already knew that from your experiences with such other regulations and industry standards as PCI DSS, HIPAA and ISO.
At this point you might be asking if it was all worth it for us. The answer: Absolutely.

As Kathryn explained, pursuing FedRAMP certification was the broadest and deepest security commitment Akamai has ever made. FedRAMP's metrics have the breadth of what is required by the International Organization for Standardization (ISO) and the depth of what is required by the Payment Card Industry's Data Security Standard (PCI DSS).

"When you have proof of what you are doing, and you find more cobwebs and dust bunnies, that's a plus," she said. "As a result of this process, we have swept imperfections out from corners we had not checked in ages. It raised the bar." For example, the review process uncovered parts of Luna-Oracle that needed updating. "We weren't terribly worried about these things, but taking care of them made us even more secure," Kathryn said.

FedRAMP certification means we track our processes more vigorously than ever, write it down and hand it to the federal government each month. That we have that level of commitment weighs heavily on customers minds, she said.

"We were always trustworthy. Now we are trustworthy and we document it," she added.

T-fedramp-logo__226x160--C-tcm245-1421469--CT-tcm245-1237012-32.png

Well, it's here. We're in the thick of the holiday ecommerce season. Mobile traffic to our retailers' sites is growing steadily and we're already seeing more overall traffic than last year.

Though we're still a few days away from the busiest shopping events of the year, visits to retailers' sites would suggest that we're on track with eMarketer's predictions that ecommerce sales will rise 15 percent this year and that mobile sales will account for 16 percent of those sales. Of course, visiting a site and making a purchase are two very different activities, but the interest is there - now it's up to the retailers to turn those browsers into buyers.

Let's take a look at some of our supporting data from this year and last.

BF Post 1.png

The above figure represents traffic growth from our real-time Retail Net Usage Index (NUI) for a few days earlier this month. The last day shown here is Nov. 20 (last Wednesday). This upward momentum is typical of pre-Thanksgiving traffic, but what is interesting is that last Wednesday saw a 25% increase in peak traffic over the highest spike on the same day last year (which was just three days before Black Friday), with nearly 5.3 million page views per minute. If this kind of growth continues, we could see more than 10 million page views per minute on Cyber Monday this year! (Check out our earlier post for a snapshot of what Cyber Monday looked like in 2012).

BF Post 2.png


If you're interested in how much of last year's traffic came from mobile devices, take a look at the 2012 breakdown (above) of Black Friday traffic from devices such as iPads, iPhones, Androids, Kindles and Nooks, and Galaxy Tabs. This data is inclusive of all mobile retailer site visits on this popular shopping day, so remember that in addition to browsing products on-the-go and on the couch, many were also visiting ecommerce sites in the stores to read reviews, check product availability and shipping options, and research prices. Since 2010, we've seen year-over-year mobile usage grow by 8 to 10%, and we expect to see a similar climb again this holiday season.

BF Post 3.png


As we consider how mobile traffic will grow this holiday shopping season, it's interesting to look at how it was trending in the early half of this quarter. The above charts illustrate the mobile activity from more than 30 of our top retailers' sites from Oct. 1 to Nov. 13 this year. Though the previous bar graph shows that 24% of Black Friday traffic came from smartphone and tablet use, this pie chart of recent data shows an average mobile use of nearly 32%.

Another interesting note from this more recent mobile data is the fact that more than 13% of the visits came from iPads, 11% came from iPhones, and 8% came from Android devices. Note that "non-cellular" means the devices were likely WiFi-enabled as opposed to using a "cellular" connection like 3G, 4G or LTE. The latest mobile device tracking suggests that device preferences remain about the same, with slight growth in each category, leading to greater overall mobile adoption and use. It will surely be interesting to see how this trend continues in the coming days!

Be sure to subscribe to this blog feed to see how the ecommerce season pans out, and follow #AkamaiHoliday and @Akamai on Twitter to learn about more data and trends as the holidays unfold.


Lorenz Jakober is Senior Product Marketing Manager at Akamai.





Oh The Hackers Online Are Frightful

evilsanta.jpg

Thanksgiving holiday planning is well underway in the US as is the holiday season that follows. It is gearing up to be a bumper sales cycle this year. This year will not be any different than previous ones in that in addition to great deals there will be bad actors attempting to play the role of good ole St. Nick with nothing but a bag of malicious code for the girls and boys.

One of the biggest online sales days of the year in North America is called Black Friday and it brings out amazing savings opportunities it also brings out the opportunists. This is where it becomes incumbent upon the shopper to exercise some caution.

1. Track your spending. The holiday season can be a blur of hopping from site to site and store to store. Be sure to check your credit card statements to be certain that that line up with your actual purchases.

2. Use reputable retailers. If you're unsure of a retailer don't take the risk. Look them up at the Better Business Bureau (http://www.bbb.org) or better yet, go elsewhere if you're have any hesitation. No need to put your finances at risk to save an extra $2 on that widget or grapple grommet.

3. Be judicious in your information disclosure. If you're buying something online take caution that you're not offering up more information than is absolutely necessary. Case in point, I was shopping at a national clothing store a couple years ago and the clerk was insisting that customers had to disclose their Social Security Number in order to complete the purchase as this was part of their current promotion. I declined and advised other shoppers in line that they shouldn't disclose their Social Security Number.

4. Password reuse is a huge problem. There really is no technical solution to this item as this rests with the user. When shopping online almost every site out there asks you to create an account with the option to store your credit card information. If you do this be sure to not use the same password as you do for any other account such as the one you use for banking. One of the issues that we have seen here at Akamai is a growing number of credentials being reused on multiple sites. Once a site gets compromised by an attacker they then end up replaying this login information on other online retailers. Ask yourself for a moment, why would you use the same username and password on a social media site as you do for banking? Let that sink in for a moment.

5. Check yourself before you click that link. Did you receive an email which appears to be from a retailer offering you a deal that is too good to pass up on? Well, quite possibly there is a good reason for that. When you receive a deal that offers you, as an example, a $200 gift card for filling out a survey I would hope that alarms bells sound the alert. Be sure to use your better judgement before you chase after an offer that is possibly little more than a lure.

Akamai offers services like the Kona Security Suite to help secure online retailers from attackers to better protect themselves, and ultimately you.

Tis' the season. Just be careful out there.

(Image used under CC from Cubosh)


So...just how important are Operator CDNs?


Of course WE'RE going to say that Operator CDNs are important, we're Akamai. But what do the operators think? And further to that, what do the consumers think? In IDC's recently released white paper -- Broadband and Pay TV Operators Adopt CDN Strategies to Manage Changes in Consumer Video Behavior -- we find out.
 
This white paper draws on extensive interviews with leading communications service providers in the US as well as a survey of US consumers. The paper dives into the topics of multi-screen video services, network capacity management, improved video experiences and its impact on both revenue and customer satisfaction.
 
The research uncovered some enlightening statistics including:
 
  • How many subscribers consider TV Everywhere an important offering
  • How many viewers place the blame on operators when OTT video streaming fails
  • The revenue impact of every 50,000 subscribers gained or lost per year
  • The number of subscribers who would switch providers if their pay TV provider did not offer multi-screen services but another did
 
You will learn this and a lot more by reading the white paper which can be found on our website at: http://www.akamai.com/html/ms/cdn-strategies-whitepaper.html.
 
You can also learn about the findings in a live webinar being held on December 11th at 11am EST with the author of the paper, Greg Ireland and Akamai's Frank Childs. Register to attend at: http://reg.dispeak.com/c/akamai/car/dec13/r.html#register.
 
In the meantime, check out this fun infographic that summarizes some of the findings.

The DNS Security Collection

Welcome to the next step in our effort to make security content more easily available by topic. Today's collection of posts focuses on DNS-related threats and defensive measures.

DNS reflection defense

Recently, DDoS attacks have spiked up well past 100 Gbps several times. A common move used by adversaries is the DNS reflection attack, a category of Distributed, Reflected Denial of Service (DRDos) attack. To understand how to defend against it, it helps to understand how it works.

How Akamai eDNS Protects Against DNS Attacks

This post continues the discussion of DNS protection by describing how Akamai's "eDNS" protects customers from both volumetric and reflective attacks on DNS infrastructure.

What can be done about spoofing and DNS amplification?

How following a Best Common Practices document (BCP-38) will help your company fight back against spoofing and DNS amplification.

How big is 300 Gbps, really?

The 300 Gbps attack against SpamHaus earlier this year certainly seemed epic.  But how big was it, really? An analysis through the Akamai lens.

Was This Really One of the Internet's Biggest Attacks?

In early October there was an interesting story in eWeek about "one of the largest attacks in the history of the Internet." It described a 9-hour barrage against an unnamed entity that swelled to 100 Gigabits of traffic at its peak. Did it truly qualify as one of the biggest? It depends on how you choose to measure it.

hackers_security_password-100004008-gallery.jpg

The Boston Globe Names Akamai a 'Top Place to Work'

Akamai is one of the best places to work in Massachusetts according to The Boston Globe's "Top Places to Work in 2013" survey. Akamai placed sixth in the "largest employers" category, moving up eight spots from last year, and was listed among the highest-ranking technology companies overall in the state.

TPTW 2013 logos blog.jpeg
Employees from our Cambridge, Mass., headquarters were among nearly 76,000 respondents to a survey commissioned by The Boston Globe. To help determine the rankings, the survey considered six key factors related to employee happiness: company direction, execution, employee connection, work load and responsibility, management, and pay and benefits.

Organizations need to offer quality career growth opportunities and the ability to "work with good, smart people," Jim Gemmell, Akamai's chief human resources officer, told The Boston Globe during an executive roundtable. The conversation included four technology leaders discussing their respective recruitment techniques and workplace culture.

Robert Hughes, president of worldwide operations for Akamai, called it a "tremendous honor" for Akamai to maintain its place as one of Massachusetts' top employers and considered it a "true testament to those who work here." He said the continued acknowledgement validates Akamai's efforts to provide exceptional experiences for employees as well as customers.

If you're interested in learning more about building a career at Akamai in Massachusetts or any of our offices around the world, we encourage you to visit our careers page. You can also follow @akamaijobs on Twitter.

Chris Nicholson is a senior public relations manager at Akamai.

So You Want to Secure Something

I've often heard the following question (or variants thereof):

How do I secure [this thing]?

Such a question rarely lends itself to a quick answer -- in almost all cases it prompts further questions: secure what, against what, in what cases, from whom? What options are you considering, and how will they help? Akamai InfoSec uses the Principals-Goals-Powers-Controls rubric to ask and answer these questions, and in so doing, help guide development effort towards our goals.

 

How to Secure Anything

(Note: The Principals-Goals-Powers-Controls rubric was originally developed by Brian Sniffen and Michael Stone based on a key bit of advice from Joshua Guttman of WPI: "If you're not talking about an adversary, you aren't doing security.")

How do I secure [this thing]?

  1. What is 'this'? Define the **principals** of your system: what entities, systems, locations, and/or interactions do you wish to include? What do you wish to specifically exclude? We call the participants in such a system "principals". If you have more than one or two, drawing a system diagram can aid understanding.
  2. What do you mean by 'secure'? Define your security **goals**: what does "secure" mean? What must remain true about the system in order for it to be secure? What counts as an unacceptable loss?
  3. Secure it against whom? Define your adversaries: who might try to frustrate those goals? Adversaries don't need to be malicious; we usually include "Murphy" (as in Murphy's Law: that which can go wrong, will; natural accidents, in other words) and well-intentioned but mistaken actors ("I clicked 'delete' when I meant 'save'") in the set of adversaries.
  4. What are their capabilities? Consider what **powers** are available to those adversaries. Again, accidents should be taken into account in addition to deliberate, malicious activity. For each adversary, how can they use powers available to them to frustrate your security goals?
  5. What can you do to prevent that? Define and build a set of **controls** that limit or prevent the ability of adversary powers to affect your security goals.

 

Note that we don't consider adversary goals or motivations.Capability is more important than intent -- relying on good intentions is rarely an adequate security control.

Part of our role is helping teams analyze their own security: we help them answer these questions themselves, rather than answering for them. Our engineering teams produce a Security Considerations section as part of their architecture document, containing a list of security goals, an enumeration of adversaries and their powers, and a description of security controls that help achieve those goals in the face of those powers.

A non-technical example

How can this be applied in practice? Consider this somewhat-contrivednon-technical (and belatedly-seasonal) example.

Over holiday dinner, your uncle says: "I hear you're into security.Next year, I want to secure my bowl of Halloween candy -- how would I do that?" 

Here's a conversation you might have:

You: "All right -- is it just your Halloween candy you're worried about, or do you want to prevent people playing tricks on you?"

Uncle: "No, I'm not worried about that. I drenched a bunch of TP'ers with the hose last year and since then they've left me alone."

You: "OK, then. What do you mean by 'secure'?"

Uncle: "You know, secure it. Prevent people from taking the whole thing. I have to work on Halloween night, and my security camera always catches a kid taking the whole bowl; that gets expensive." 

You: "So your goal is to prevent anyone from taking more than their fair share?"

Uncle: "Yeah -- I want to make sure each person gets one, and only one, piece of candy."

You: "Hmm, that's a slightly different statement. It's both a negative goal -- people shouldn't be able to take too much -- and a positive goal -- everyone should be able to get candy. (Otherwise, you could 'prevent people from taking the whole thing' by not handing out any candy at all!) I think I understand. Is it just kids you're worried about, or everyone?"

Uncle: "Good point. I'm just worried about kids. Oh, and there was that time someone stepped on the side of the bowl and flung candy into the bushes..."

You: "OK, then, we'll consider accidents too. What have you tried so far?"

Uncle: "A couple years back I tried putting a sign on the bowl: 'One Piece per Person.' That didn't work -- they just poured it all out."

You: "Makes sense. The sort of person who'd take an entire bowl of candy isn't much deterred by signs."

Uncle: "The next year, I tried using a very heavy cast-iron pot to hold the candy. That prevented the bowl-flipping accident. I thought it'd prevent people from pouring it out, but one smart kid just scooped it out by the handful instead."

You: "Seems like an OK solution. Shame it didn't work."

Uncle: "I also tried a box with a small hole, but larger kids couldn't get their hands in. Making the hole larger just allowed kids with smaller hands to grab more."

You: "Clever, but understandably flawed."

Uncle: "I tried building a gadget to dispense candy on a timer, but it kept flaking out -- besides, I need to be able to handle a bunch of kids showing up at once."

You: "While I'd love to come up with a clever technical solution like that, it seems easiest to have a human in the loop. Perhaps you could try getting a backup to hand it out for you? I'm usually free that night."

Uncle: "Hmm, if you're willing, that'd work. See you next Halloween."

Grandfather (interjecting): "That doesn't work! There's no way you can prevent all your candy from disappearing -- I mean, what if a robber shows up and takes your candy at gunpoint?!"

You: "That's out-of-scope. We decided before that we're only considering greedy kids as adversaries -- besides, gun-toting criminals wandering around at night are probably after more than candy."

A note on objections and limited resources

As Grandpa points out, virtually any conceivable system has one or more adversaries whose powers defeat your controls -- in a computer security context, the archetypical "gun-toting robber" is the NSA or other hypothetical adversaries with nation-state budgets and compute farms the size of small towns. In almost any "how do I secure this?" discussion, you'll find someone pointing out that the proposed system isn't secure against the NSA, Chinese intelligence, malicious BIOS rootkits, evil employers with ceiling cameras and keyloggers, and so on ad infinitum. You can't call the system secure, claim those objectors, unless you take those adversaries into account. It's true that "This system is secure, full stop" is almost always a bad claim to make -- much like "this road is safe" or "this food is healthy." That's not the goal of this process -- an honest security analysis will almost certainly admit there are times when the security controls will fail, and that's OK.

As much as anything else, system security is subject to business pressures and thus must contend for limited resources: the time you spend ensuring the security of a system is (usually) time not spent adding new features or otherwise improving the day-to-day customer experience. Thus, in most cases (unless you work for the NSA, maybe) it makes little sense to have perfect security as a goal. This is where the principals-goals-powers-controls rubric can help: defining the scope of your system and its goals, helps determine where to apply your limited budget (whether that be money, bandwidth, compute-hours, or person-hours; most likely some combination of those) towards getting the best return-on-investment.

A technical example

Bringing this back to information security, here's a common example --password authentication -- analyzed using this rubric

System: A password system for user authentication, consisting of a client (the browser), a server with a standard database, and a link between these systems.

Goals:

  • Passwords are kept secret from everyone but the end-user.
  • Only the end-user associated with a password can pass authentication.
  • Adversaries and their powers:
  • End-users, who can transmit and check passwords over the network and
  • can insert new passwords into the database by signing up.
  • Malicious actors who've compromised the system and can access the
  • database directly.
  • A man-in-the-middle who can see traffic passing over the network.

Controls:

  • Passwords are hashed using bcrypt, whosebuilt-in salting features deter rainbow-table attacks arising from a database compromise.
  • Network rate-limiting and autobanning, in addition to that naturally provided by bcrypt, renders a network brute-force attack infeasible.
  • The network link is encrypted using TLS to deter man-in-the-middle snooping. Access to the TLS private key is limited to trusted administrators.

Known limitations:

  • Anyone who has access to the SSL private key can decrypt communications on the wire and reveal passwords. Anyone who can break the key, or who can otherwise conduct a TLS man-in-the-middle attack (for example, by using a malicious-but-trusted CA) can access these passwords as well.
  • Similarly, a user with root privileges on the server can access the passwords in unencrypted form; for example, by using a debugger on the server process.
  • Malware on the end-user's computer (a keylogger or maliciousbrowser, for example) could access keyboard input and grab the password.
  • Perfect Forward Secrecy is also out of scope -- an adversary may record traffic flows in the hopes of *later* decrypting them. Also out of scope are side-channels such as timing or cache-based attacks.

Conclusion

"How do I secure this?" is not a simple question. Through this rubric,you can ask yourself questions to honestly consider the security of your system and point the way towards improving it.

Part 2: A practical guide to web resource caching

The first part of this series reminded our reader on the best practices for caching and emphasized the need to isolate personal data from any page view content.

In this second blog post, we will provide actual caching value recommendations for client browsers and edge servers. We categorize each resource by time sensitivity, list the main observed use cases for each of them, and propose TTL values for the client as well as for the edge server. When appropriate, we differentiate recommendations based on the edge invalidation policy.  

Resource is not time sensitive, points to static content. 
PL2.png

This is the best caching scenario. Always strive to make resources time-independent.

  • Images
  • Any versioned content: www.example.com/v13/js/main.js

Recommended TTLs: Edge and Client TTLs: 3 months

Resource has low time sensitivity ( Staleness > 1 hour)

PL3.png

  • Search result listings
  • User reviews
  • Backward compatible resources, e.g. JS or CSS
  • Search engine targeted pages
  • Generic ads

Recommended TTLs:
  • Edge TTL: 1 hour to 1 day if no invalidation, else 2x the refresh period, e.g. 2 days for content updated daily
  • Client TTL: 2x median user session duration , or 15 min if unknown

Resource has medium time sensitivity (15 m. < Staleness < 1 h.).

PL4.png

  • Social updates, user comments 
  • Category listings
  • Flight and other schedules
  • Weather forecasts
  • Context sensitive ads
  • Product prices or availability. (Upon purchase/reservation, non-cacheable requests to pricing/availability must be made to guarantee the transaction)

Recommended TTLs: 
  • Edge TTL: 15 min. to 1 hour if no invalidation, else 2x the refresh period, e.g. 2 hours for content updated hourly.
  • Client TTL: 10 min. or less.


Resource has high time sensitivity (Staleness < 15 mins.). 

PL5.png
  • Breaking news 
  • Finance tickers
  • Sports scores

Recommended TTLs:
  • Edge TTL: 30 sec. to 15 min. Invalidation is discouraged
  • Client TTL: 0. Validation with edge server must be performed for each request


Resource has personal information.
 PL6.png
  • Origin system generated: recommendations, messages
  • User generated, e.g. personal settings, shopping cart

Recommended TTLs:
  • Edge: Do not cache
  • Client TTL: If origin generated: 2x median user session duration, else do not cache


Resource cannot be served stale, yet is cacheable
Non-personal, popular and time-critical large objects that change at unpredictable times

Recommended Edge and Client TTLs: 0. Resource can be cached, however validation with Edge (from client) and Origin server (from Edge) must be performed for each request

If you would like to understand how to best implement these recommendations or present a use case that is not covered here, please contact Akamai professional services.

Pierre Lermant is an Enterprise Architect at Akamai

Sola Shines at Streaming Media Readers' Choice Awards

We're honored that Akamai received three 2013 Streaming Media Readers' Choice Awards, which were presented during a ceremony at the Streaming Media West conference in Huntington Beach, Calif., on Wednesday, Nov. 20th. Akamai ranked first in the Content Delivery Network (CDN), Cloud Encoding/Transcoding, and Reporting & Analytics Platform categories.

Akamai Streaming Media Awards.jpg

Akamai's Sola Sphere won for CDN. Built upon the Akamai Intelligent Platform of more than 141,000 globally distributed servers, Sola Sphere is the world's first and largest content delivery network, providing online storage and HTTP media delivery to address the expansive variety of network types and connection speeds.

Sola Vision Transcoding topped the Cloud Encoding/Transcoding category. The cloud-based transcoding services are optimized to combine the quality, simplicity and speed necessary generate multiple copies of a video file that are so crucial to adaptive bitrate streaming and a positive viewing experience across multiple devices and varying levels of connectivity.

Finally, Sola Analytics was the readers' choice for Reporting and Analytics Platform. Consisting of Audience Analytics, Quality of Service Monitor and Viewer Diagnostics, Sola Analytics delivers insights designed to address numerous business issues, including maximizing monetization, try-to-buy conversions, optimizing product portfolios, prioritizing marketing efforts, managing distribution strategies, addressing rights holder requirements, and monitoring and allocating costs.

According to Streaming Media, it received more than 300 nominations across 26 categories. We want to extend our thanks to everybody who voted for Akamai this year, and congratulations to all of this year's winners and finalists.

Chris Nicholson is a senior public relations manager at Akamai.

Making Compliance Docs Public

Part 2 in a series.

In my post about compliance and customer service, I briefly touched on one of the goals of Akamai InfoSec -- making as much of our compliance documentation public as possible. I want to spend a little more time talking about that, as it's something I'm increasingly involved with.

Also, customer feedback is going to be crucial in determining which documents to tackle first.

As I mentioned in the last post, the goal is to give customers the tools for more self service. Right now our sales staff asks questions on the customer's behalf and they deliver the answers we provide. By making documentation publicly available, we hope to reduce the need for doing it that way. If the customer has a question and all they have to do is access documentation addressing their questions via our site, they get to act more quickly to address their issues. To me, it's an extension of the Akamai motto "Faster Forward."

The soon-to-be launched security microsite on Akamai.com will include a whole section for this purpose. We have a lot of work to do. So far, only a few of the documents are ready for prime time.

We're about to move a lot more quickly to get the job done. The task begins with us reviewing each document and removing details that must remain private for the protection of customers. Then, every document must be reviewed by our legal department to ensure we've dotted every i and crossed every t.

Here's where you come in.

I'd like your feedback on the compliance issues that cause you the most difficulty; those that compel you to get answers through the sales staff. 

That will help us prioritize which documents to tackle first. 

Our compliance team already has a pretty good idea of which documents belong atop the stack, based on the kinds of questions they get most of the time. But to do something like this right, there can never me too much feedback.

Please send your feedback to wbrenner@akamai.com, and I'll take your comments back to the team.

Thank you.

Privacy Was in Danger Before 9-11

This week I participated in an online panel put on by the Information Security Buzz website. I got the following question:

What 2 things are most likely to change the security industry in the next 2 years? And why?

The question immediately made me think of the state of privacy. My full answer is here. As to the privacy issue, I answered:

After 9-11, privacy got shafted in the rush to build tougher security, but we've seen how that has led to governments abusing authority. The NSA case is a prime example, though outrage over TSA tactics in the airports had already started the ball rolling. In the next two years watch for today's outraged reactions to translate into new policies governing privacy.

Privacy is a subject I've tackled a lot over the years. When I was at CSOonline.com, I wrote a story called "6 ways we gave up our privacy." In it, I focused on how people have almost willingly given up privacy in the rush to be seen and heard on the likes of Facebook and Twitter. I've also argued several times that Americans willingly gave up a lot of privacy out of fear in the aftermath of 9-11

I do believe the outrage over the NSA's PRISM program is swinging the pendulum back in the other direction, and that may ultimately lead to new privacy safeguards. 

All that said, it's worth noting that privacy was under threat before 9-11. The issue was framed succinctly in a 1999 episode of The West Wing called "The Short List." In it, the West Wing staff are focusing on nominating a judge for the Supreme Court. They discover a writing from the judge in which he essentially endorses the idea of invading individual privacy in certain cases. The fictional presidential aide Sam Seaborn says:

Twenties and thirties, it was the role of government. Fifties and sixties, it was civil rights. The next two decades, it's gonna be privacy. I'm talking about the Internet. I'm talking about cellphones. I'm talking about health records, and who's gay and who's not. And moreover, in a country born on a will to be free, what could be more fundamental than this?

Prophetic words. From a TV show.

Food for thought.


 




Security Presentations from Akamai Edge 2013

More than a month has passed since Akamai Edge 2013. Security was a major theme this year, and in this post I want to direct you toward the presentations now available on the Akamai Edge page. For the video presentations, click here. Below are some of the slide decks from those presentations.

I know there were additional security presentations, and I'll update this post as more of them surface.

Images are probably the simplest component on a web page today. They don't block the parsing of the HTML and don't get in the way of rendering other components. Generally, they just sit there and look pretty.

However, for what they lack in complexity, they compensate in volume. According to the HTTP Archive, images make up 61% of the bytes on the average desktop homepage, and 65% of the bytes on mobile. And to make things worse, the number of image bytes has grown by over 30% on the average web page in the last year alone!\

 

image transfer size.png

 

These stats demonstrate how important it is to minimize image bytes to the maximum extent. Various image compression techniques and smart image loading approaches like LQIP and responsive images can dramatically reduce the number of bytes required to communicate the same visual appearance.

Akamai's Aqua Ion has been applying the best Image optimizations possible for a long while now, and with the latest release our Image Optimizations got a significant new boost, by introducing support for WebP & JPEG XR.

WebP is a new image format, introduced by Google three years ago. Being 15 years or more newer than the common web image formats, WebP encompasses many technological advances developed during that time, along with some unique innovations. For instance, it uses a better mathematical encoding for compression; uses prediction logic adopted from the video encoding world; and uses a dynamic color palette to encode different parts of the image. As a result, WebP images tend to require 25-50% fewer bytes than the equivalent quality JPEG or PNG image.

JPEG XR is also a new image format, developed as an ISO Standard and backed by Microsoft. JPEG XR also builds on many technological advances, and - while very different than WebP - achieves significant file size reductions, often cutting image bytes by a third. In addition, JPEG XR supports progressive rendering, which WebP does not.

Both of these image formats are awesome, and are far better than their predecessors. However, deploying new image formats on the web isn't easy. Being new also means JPEG XR & WebP are not yet widely supported. WebP is only supported by Chrome, Opera and newer Android devices. JPEG XR is supported to a limited extent in IE 9, and only fully supported in IE 10+. This means that if you simply overhaul your images to any one of these formats, your site will be broken for a huge portion of your users.

Luckily, Aqua Ion is already setup to provide Situational Performance Optimization, and optimizes differently for different browsers, leveraging the relevant browser's capabilities. With our November launch, we've added support for WebP & JPEG XR, automatically converting images on your site to those formats and serving them only to the browsers that support them. Other browsers would still benefit from our existing Image Compression techniques, and we will start delivering the new formats to them as they build support for them.

In addition, if you want to roll your own version of Situational Performance and serve WebP or JPEG XR images only to supporting clients, you can use the flexible Property Manager UI to intelligently serve the right image to the right client (though in this case, you'll still be on the hook for creating the image versions themselves). This slide shows a simple example of how you can do deliver WebP using Accept Negotiation, which can be easily tuned to fit into your website's logic.

To summarize, WebP & JPEG XR are huge steps forward in the world of Image Compression. You can start reaping the benefits of them today by using Aqua Ion, or using Property Manager to intelligently deliver your homemade pictures, and get a substantial boost to your page load times.

Guy Podjarny is CTO for the Web Experience Business Unit at Akamai

MPEG-DASH is now industry essential

While NAB 2012 was approaching, Will Law was pushing forward MPEG-DASH on this blog as "a single [video] format that can be supported across a common ecosystem of content and services, all the way from the encoder down the chain to the end consumer" with the potential to "translate into an industry with a deeper feature set and a steeper innovation curve". What is the situation after IBC 2013? Did MPEG-DASH successfully handle this industry spread to allow a world of streamlined media workflows?

Let's agree that the general perspective provided by MPEG-DASH is quite appealing for most online video professionals, with the target of drastically reducing the number of Adaptive Bitrate streaming formats to support. The recent move of Widevine dropping proprietary packaging in favor of DASH clearly goes in this direction, as well as the positive efforts of Microsoft to translate Smooth Streaming to DASH through a new generation of PlayReady DRM and new DASH-enabled player frameworks. After having recently focused on HLS support in its client implementations, Adobe now gets back to DASH with announcement of early 2014 support, which will be a major event if DASH finally comes to the huge installed basis of Flash Players and supersedes Adobe HDS format.

A main characteristic of DASH is to focus on manifest and video segment organization, delegating restrictions on codecs, containers and even transport modes to profiles. The positive side of this approach is that it conveys openness and brings flexibility to the standard. But it also brings a complexity factor: numerous interactions with other standards and standardization bodies to offer a systemic approach. This partly explains why the DASH standardization process is taking some time despite all efforts deployed by the MPEG consortium since late 2011 with the first draft standard publication. The intermediary observation that can be derived from this situation is that the standardization work is still not finished as major complementary standards like Common Encryption and multi-DRM still require industry collaboration efforts. Nevertheless, the MPEG-DASH standard has become a strategic asset for the entire video industry, considering upcoming Ultra-HD video distribution challenges.

How Akamai InfoSec Answers Customer Compliance Questions

Part 1 in a series. For more information, see "Everything You Want To Know About Akamai Security & Compliance."

The process to address customer security and compliance questions used to be somewhat chaotic. Questions would float around in random emails and elsewhere, and which ones got answered was a luck of the draw. We found this unacceptable, and did something about it.

In an interview last week, Akamai InfoSec Program Manager Meg Grady Troia -- who has had a big role in the customer service and compliance arena -- gave me an overview of the improvements made. 

It's been a three-pronged strategy:

  • Create an internal document of 100 basic security questions to give our sales staff clearer guidance on what to expect from customers and how best to answer them.
  • Create a structured process where sales people can pass customer questions along to us and we can supply them with answers in rapid-fire fashion.
  • Gather up documentation that deals with the most-commonly-asked-about issues and make them public.
The internal document deals with the first issue by laying out 100 common questions in detail and offering a variety of answers to take back to customers. The goal is to make it easier for sales staff to find answers on their own. When that can't happen, the second piece of the strategy comes into play.

An overhauled email list and ticketing system went online in late spring 2013. Senior Program Manager Lead Daniel Abraham and Security Researcher Kevin Riggle designed the improvements for easier communication between sales and our team. Sales staff asks us a question on the customer's behalf. We supply them with answers -- including documentation -- they can take back to the customer.

The third prong is about providing sales staff and customers with the tools for self service. As documents are made public, they will be housed on a compliance page that will be part of our soon-to-be-released Akamai Security microsite on Akamai.com.

Meg says the most sought-after documentation is the material dealing with PCI compliance and, as part of that, how we secure our servers and racks around the globe. Also popular are documents that map out Akamai human resource policies and insider threat information. 

"PCI is a very thorough standard about how you secure cardholder information," Meg says. "It allows us to talk about a variety of topics."

When the new security microsite goes online, customers will be able to go to the compliance page and type any topic they want to know about into a search box, which will then return every scrap of public documentation we have on the given topic, be it HIPAA, PCI, FedRamp or Sarbanes-Oxley.

security-b.46e2201935c36179fab5beeeda4db6702477.jpeg

Tweets of the Week: 11/11 - 11/15

Starting next week, I'm beginning a series on Akamai InfoSec compliance efforts. It's an extensive effort to be sure, and customers probably ask us more about it than anything else.

The first post will be about our process for getting customers the answers they need. From there, I will delve into the following (in no particular order):

  • Akamai InfoSec and the challenges of ISO 27002 
  • How ISO compliance shaped Akamai security training for vets and newbies alike 
  • How Akamai achieved FedRAMP certification, and why it's a huge deal 
  • Pen testing: Why it's essential to Akamai's security compliance efforts 
  • Case studies in pen testing: What Akamai learns about itself 
  • Edge tokenization deployments: How we do it 
  • How we approach 3rd-party assessments (HIPAA/ISO /PCI
  • The importance of code review as part of our security efforts and how it fits into the compliance puzzle
  • How we welded security and compliance into a process that makes sense
  • CP/DR at Planetary Scale
That won't be the end of the series. In fact, it will just be the beginning.

Meanwhile, the new security section of Akamai.com will launch around February, and giving customers quicker access to documentation that addresses their compliance questions is a major part of that.

Stay tuned for more. Much more. And if you have questions about a compliance issue you don't see covered in the list above, email me at wbrenner@akamai.com.

Medical-Billing-Compliance-Checklist.jpg


A practical guide to web resource caching, part 1

Web resource caching provides the dual benefit of reducing load on the origin infrastructure while accelerating the content delivered to the clients. Yet, because of business and technical requirements, it is often difficult to select the best caching rules for the client browser and the Akamai edge servers. In this 2-part blog I will review industry's best practices and offer recommendations for common use cases.

 

Part 1 will walk you through all the parameters impacting caching policies. Part 2, to be published soon, will provide actual TTL recommended values for various contexts and use cases.

 

Terminology

●    TTL: Time to live of a cached resource.

●    Cache keys: Define a set of parameters that scope the caching of a resource. The client cache key is typically the full URL, including the query parameters. Akamai edge servers cache keys can be tailored to the application and resource at hand, and allow for dynamic caching, based on cookies, headers, query strings and other parameters.

●    Resource time sensitivity, or staleness: The amount of time a resource can be served stale without breaking any significant functionality or user experience. It is not to be confused with the object rate of refresh, which indicates how often the object is changed at the origin. Time sensitivity, and not refresh rate, is a main TTL driver.

●    Personal information: Hold data that is unique to a given user.


PLPost.png

What is cacheable?

●    Edge caching: Everything can be considered for caching at the edge, except for content that is personal or must reach the origin for critical logging or business reasons. Even a few minutes TTL can enhance the user-experience and avert origin breakdown in case of request bursts.

●    Client caching: While providing the shortest path to a given resource (no N/W traffic), it must be used with caution, as it cannot be invalidated. Personal information can be considered for caching. 

It is highly recommended to not embed personal information in the page view (i.e. html) so it can be cached at the edge and shared amongst users. Instead, have the client fetch personal data through ajax calls or by reading dedicated cookies.

When to use Edge caching invalidation?

Invalidating a piece of content is enticing as it can be automated and extended TTLs can be prescribed. However it must be used with the following in mind:

●    The purge/invalidation process can create significant traffic spikes on the origin. If many resources are invalidated concurrently, or if it is performed during traffic peak hours, this may negatively impact the origin's ability to serve the requests in a timely manner.

●    It is most beneficial if automated and synchronized with the underlying systems updating the content. e.g. CMS or code release process.

●    It should only be considered for content that can be served stale for up to 10 min, as the invalidation/purge process is not immediate.

Client vs Edge caching

For each resource, business rules define a permissible overall staleness, which cannot fall below the sum of its client and edge TTLs. We will address how to partition the 'staleness budget' between the client and edge servers in our next post.  We will also provide actual TTL values for both the client and the edge server. Stay tuned and please check back on this blog.


Pierre Lermant is an Enterprise Architect at Akamai

Video: Security and Compliance 101

Chief Security Officer Andy Ellis gives a brief overview of security and compliance and what they mean to Akamai. Andy's overview includes common terms along with definitions and an overview of common standards and their components.


The holiday season is upon us once again! Stores are filling with holiday gifts and gadgets and our emails will soon be inundated with holiday shopping deals and ads. With 96 of the top 100 online retailers (according to Internet Retailer) as customers, our Akamai Commerce team has been working around the clock, alongside our retail customers and partners, to deliver, optimize and secure consumers' online shopping experiences this season. Before the season is in full swing, however, we'd like to take a look back at some of last year's holiday shopping traffic trends to paint a picture of what the 2013 online holiday shopping season may look like.

Let's start at the beginning. In 2012, traffic to retailers' websites averaged between two to three million views per minute, give or take a few spikes here and there. As the Thanksgiving holiday nears, the traffic begins to climb to four or five million views per minute. You can see this movement for yourself if you visit our Net Usage Index and select the "Retail" industry. This publicly available index shows web traffic spikes by geography and industry in real-time, and going back about a year and a half.

On Thanksgiving last year we saw online shopping peak at around 9 p.m. ET with nearly 7.6 million page views per minute, suggesting many consumers didn't wait for Black Friday to begin their holiday shopping. As can be expected, Black Friday drove 25% more average traffic than Thanksgiving, with a similar peak of more than 7.5 million page views per minute at 11 a.m. ET. Black Friday tends to drive much higher peaks earlier in the day because of research activity for offline shopping in the morning hours.

As far as where consumers did their shopping, according to a survey from NRF, approximately 48% of respondents did their Black Friday holiday shopping online, and according to data from IBM, 24% of visits on Black Friday came from mobile devices. Additionally, IBM found that nearly 60% of consumers used smartphones and 41% used tablets to look for deals on Black Friday. In 2013, we expect to see more of this on Black Friday, as consumers use coupon and savings sites to do research and search for gifts from the comfort of their own home, as they recover from Thanksgiving dinner. Are your sites ready to deliver great experiences across screens and browsers?

We also saw in 2012 that consumers shopped in store, online and on mobile devices simultaneously to get the best Black Friday deals. There will be more of this in 2013 as shoppers continue to use the resources they have at their disposal to become smarter and savvier shoppers. Mobile activity peaked between 9 and 10 p.m. ET on Black Friday, with many consumers likely checking for deals on their phones before bed.

 

Last year, the Black Friday momentum continued through the following Saturday, maintaining a peak of 7. 6 million views per minute at 2:05 a.m. ET, meaning that East Coast shoppers browsed well into the morning and West Coast folks stayed up late. They took a break on the Sunday before Cyber Monday, though, with peak views dropping to 6 million per minute at noon ET.


holiday blog 2013.png


Cyber Monday in 2012 was incredibly popular, with page views spiking at 8.5 million at 9 p.m. ET, further proving the night owls' approval of the convenience of "window" shopping and purchasing from the internet. We can expect similar behavior in 2013. Whereas other traditionally big holiday shopping days - like Free Shipping Day in mid-December and the December 28 post-holiday sale - will likely be slightly less popular. Last year the peak page views on these days were 4.1 million and 3.6 million, respectively.

 

Last year, online Thanksgiving Day sales increased by 17% over 2011, online Black Friday sales increased by 21% and online Cyber Monday sales increased by 30 percent, according to an annual holiday consumer retail spending report from Baynote. We'll likely see an increase in overall online holiday shopping sales in 2013, similar to what we saw in 2012.

 

We hope you'll find it insightful to compare your site's traffic to the aggregate of thousands of retail sites in the US and Europe. Here are the stats you can expect to find on our blog this season:

  • Overall, online traffic patterns, including peak traffic times and days, through our Retail Net Usage Index
  • The types of mobile devices and browsers consumers are using this year
  • Any other unique and interesting traffic patterns we find

Any other data you'd like us to cover? What are your predictions for the 2013 holiday shopping season? Let us know by commenting below.  

Share your own stories and data comparisons on this blog. Subscribe to this blog feed, or follow #AkamaiHoliday and @Akamai on Twitter to stay in touch and learn about interesting trends we see as the holiday season unfolds.


Margaret Kuchler is Director Industry Marketing at Akamai.

Microsoft's November Patch Load

Yesterday was the second Tuesday of the month, which those of us in security know as Patch Tuesday -- the day Microsoft unloads its security updates. It's an important calendar item for Akamai customers, given how dominant Windows machines are in many companies.

What follows is the full November 2013 update. Please review, see which are most important in your network, and deploy.

Bulletin IDBulletin Title and Executive SummaryMaximum Severity Rating and Vulnerability ImpactRestart RequirementAffected Software
MS13-088Cumulative Security Update for Internet Explorer (2888505) 

This security update resolves ten privately reported vulnerabilities in Internet Explorer. The most severe vulnerabilities could allow remote code execution if a user views a specially crafted webpage using Internet Explorer. An attacker who successfully exploited the most severe of these vulnerabilities could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
Critical 
Remote Code Execution
Requires restartMicrosoft Windows, 
Internet Explorer
MS13-089Vulnerability in Windows Graphics Device Interface Could Allow Remote Code Execution (2876331) 

This security update resolves a privately reported vulnerability in Microsoft Windows. The vulnerability could allow remote code execution if a user views or opens a specially crafted Windows Write file in WordPad. An attacker who successfully exploited this vulnerability could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
Critical 
Remote Code Execution
Requires restartMicrosoft Windows
MS13-090Cumulative Security Update of ActiveX Kill Bits (2900986)

This security update resolves a privately reported vulnerability that is currently being exploited. The vulnerability exists in the InformationCardSigninHelper Class ActiveX control. The vulnerability could allow remote code execution if a user views a specially crafted webpage with Internet Explorer, instantiating the ActiveX control. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
Critical 
Remote Code Execution
May require restartMicrosoft Windows
MS13-091Vulnerabilities in Microsoft Office Could Allow Remote Code Execution (2885093)

This security update resolves three privately reported vulnerabilities in Microsoft Office. The vulnerabilities could allow remote code execution if a specially crafted WordPerfect document file is opened in an affected version of Microsoft Office software. An attacker who successfully exploited the most severe vulnerabilities could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
Important 
Remote Code Execution
May require restartMicrosoft Office
MS13-092Vulnerability in Hyper-V Could Allow Elevation of Privilege (2893986) 

This security update resolves a privately reported vulnerability in Microsoft Windows. The vulnerability could allow elevation of privilege if an attacker passes a specially crafted function parameter in a hypercall from an existing running virtual machine to the hypervisor. The vulnerability could also allow denial of service for the Hyper-V host if the attacker passes a specially crafted function parameter in a hypercall from an existing running virtual machine to the hypervisor.
Important 
Elevation of Privilege
Requires restartMicrosoft Windows
MS13-093Vulnerability in Windows Ancillary Function Driver Could Allow Information Disclosure (2875783) 

This security update resolves a privately reported vulnerability in Microsoft Windows. The vulnerability could allow information disclosure if an attacker logs on to an affected system as a local user, and runs a specially crafted application on the system that is designed to enable the attacker to obtain information from a higher-privileged account. An attacker must have valid logon credentials and be able to log on locally to exploit this vulnerability.
Important 
Information Disclosure
Requires restartMicrosoft Windows
MS13-094Vulnerability in Microsoft Outlook Could Allow Information Disclosure (2894514) 

This security update resolves a publicly disclosed vulnerability in Microsoft Outlook. The vulnerability could allow information disclosure if a user opens or previews a specially crafted email message using an affected edition of Microsoft Outlook. An attacker who successfully exploited this vulnerability could ascertain system information, such as the IP address and open TCP ports, from the target system and other systems that share the network with the target system.
Important 
Information Disclosure
May require restartMicrosoft Office
MS13-095Vulnerability in Digital Signatures Could Allow Denial of Service (2868626) 

This security update resolves a privately reported vulnerability in Microsoft Windows. The vulnerability could allow denial of service when an affected web service processes a specially crafted X.509 certificate.
Important 
Denial of Service
Requires restartMicrosoft Windows

Akamai Security Videos, Part 2

Last week, I began making compilations of Akamai InfoSec's multimedia content. This post is the final roundup of videos we've released thus far.

For the compilation of Akamai security podcasts, go here. For the first installment of videos, go here.

Now for more videos:


Major Areas of Technology within Security
In this Akamai InfoSec video tutorial, Security Intelligence Director Joshua Corman gives an overview of major areas of technology within security.

The Security Team's Role Within An Organization
In this Akamai InfoSec video tutorial, Akamai CSIRT Director Michael Smith gives an overview of the security team's role within an organization.

Cloud Security Made Simple
In this episode, Akamai CSIRT Director Michael Smith gives an overview of the cloud, cloud infrastructure and cloud delivery models.

video-clapperboard-512x512.png


Akamai.com Security Section Takes Shape

A few weeks ago I wrote about our efforts to develop a section for the Akamai website that's all security, all the time. Here's an update.

First, a summary:
 
This section will allow InfoSec practitioners to access all our security content in one place. There will be easier access to the security blog posts, podcasts and videos we already produce daily as well as such new content as slideshows, infographics, research papers and articles on topics that matter to customers and the security community as a whole.

Another goal is to make it a place where customers can get their questions answered more quickly. We constantly field questions. Sometimes it's a compliance question. Sometimes it's about how someone may or may not be affected by an attack making headlines. Along the way, we've written up a lot of answers, and want to make them available on the new page. If you can go to our page and find the answer to a question you have, it can save a lot of time.

Since the last post, we have come up with a design for the section and started building in the content. It will be more comprehensive than the initial plan, with boxes that will take readers from the main page to detailed sub-sections where they can access our public compliance documentation, CSIRT security advisories and calendar of events.

I can't show you the whole design yet, but I can share the whiteboard sneak preview I drew for the staff last week. (For a larger view, click on the image.)


539181_10202582193542486_1120288938_n.jpg


Stay tuned for additional updates.

Türk Telekom and Akamai Team Up

Today is another exciting day for Akamai and our Aura Network Solutions team with the announcement of our strategic partnership with Türk Telekom.  We have teamed up to build a high capacity Operator Content Delivery Network (OCDN) for high-quality delivery of online content and video.  The OCDN will also optimize the network efficiency of Turkey's Internet infrastructure.


TT_Logo.png

 

The partnership will ensure a significant increase in speed and performance for broadband and mobile users in Turkey, particularly when accessing social media and popular online video sites.  It will also allow Turkish media companies to provide high quality content to their audiences outside of Turkey. 

 

If you don't already know, Türk Telekom is Turkey's leading communication and convergence technologies company with a modern network infrastructure covering the whole country; they offer a wide range of services to residential and commercial customers in fixed lines and broadband Internet.  With this partnership, Türk Telekom joins a select group of leading telecommunications companies - AT&T, KT and Swisscom (not too shabby) - who have entered a strategic partnership with Akamai to serve global and local customers on a joint technology and network platform.

 

I think it's always best said by our partners what a partnership with Akamai means to them.  At a press conference last Thursday in London, Türk Telekom CEO Tahsin Yılmaz commented...

 

"Türk Telekom built the communication infrastructure in Turkey and continues to invest in new technologies.  Our collaboration with Akamai is one of the key steps we have taken in this area.  As the leader of the Turkish telecommunication industry, we'll be offering benefits in cost and accessibility to all players in the Internet sector, from content providers and media organizations to the end users who access their services.  Akamai is one of the largest providers of content delivery and cloud services in the world and by providing faster access to popular rich media content within Turkey, both companies will ensure a highly efficient and top performing user experience to all of the stakeholders in the industry."

 

"We'll be contributing to the Turkish economy by exporting data to foreign countries.  This partnership will also significantly reduce our network costs associated with traffic originating from content across the globe.  Better yet, we will be making a significant contribution to Turkey's economy, as data traffic and services within Turkey will be accessed by users in other countries.  In a sense, we'll be exporting data to many international customers."

 

Together we are going to make a huge impact, it doesn't get more exciting than this!


To read the press release, please visit our press page.  To learn more about our Operator CDN solutions, please visit the Aura section of our site.


Tara Bartley is a Senior Product Marketing Manager at Akamai

Looking forward to Forward Secrecy

Akamai is constantly looking for ways to improve the security of our platform and protect our clients' traffic. We're currently looking into an encryption mechanism called Perfect Forward Secrecy, or simply Forward Secrecy. We prefer to use the term "Forward Secrecy" because nothing in security is perfect and we'd rather not imply that it could be. Akamai plans to include Forward Secrecy as a capability our customers can start using in the first half of 2014.

If you're connecting to a web site securely, you're probably using an encrypted connection over HTTPS, which uses SSL to encrypt traffic between the browser and the servers you're connecting to. The browser and the server negotiate the level of encryption to be used between them as part of the initial connection. This process includes the creation of a session key that is used to encrypt all further communications and deleted afterward. However this key needs to be communicated between server and browser, which is done using public key encryption and encrypting the session key with the private portion of the SSL key of the server. 

The weakness in this method of passing the session key between the server and the browser is that the entire communication stream can be decrypted if the stream is captured and the key used to encrypt the session key is known. While it's extremely useful to be able to use this capability with some network devices that require access to the traffic, such as Intrusion Detection Systems (IDS) and Web Application Firewalls (WAF), it has weaknesses. For example, it is possible for an attacker to capture the traffic and crack the private key offline, thereby gaining access to the session key and the entire encrypted communication. The ability to crack the private key once seemed to be an extremely time consuming process, but the use of graphics cards as fast cracking processors, the invention of quantum computing and revelation of weaknesses in the randomization process of some encryption techniques make the cracking of private keys much less time consuming than it used to be. And if enough computing power is applied, even the strongest keys can eventually be undone. Finally, the owner of the encrypting server can be forced to give up the private key, as is the case when a subpoena or other legal document is served to a service provider.

Which is where Forward Secrecy comes into play. While the communication of the session key is normally done using the private key of the server, when Forward Secrecy is involved, the session key is communicated using a temporary, or ephemeral, encryption key that is discarded once the session is over. This means that rather than having to crack one key which grants access to all communication encrypted with that key, an attacker would have to crack each key for each session individually, greatly increasing the time required to gain access to the communications of secure traffic.

So why isn't Forward Secrecy used everywhere?  There are two main problems with this solution. The first is that it is only supported by two algorithms: Diffie-Hellman (DHE) and (ECDHE). These algorithms aren't supported by all browsers, though the latest versions of all browsers do support them. The second issue is that these algorithms are currently slower and require 10-15% more computing power in order to use. This may not sound like a lot of additional CPU usage, but for any high capacity server, 10-15% is a huge hit to be able to support.

Akamai supports our clients' in their efforts to secure communication with their customers.  As such, we are constantly looking for ways to improve their security, with Forward Secrecy one way to provide greater security. Despite the name, nothing in security is ever 'perfect', but Forward Secrecy greatly increases the level security over normal SSL session key communications. Akamai will continue to research additional ways to secure all the traffic for which we are responsible.

For more information on Perfect Forward Secrecy, read the PFS Wikipedia page or Ivan Ristic's SSL Labs posting.

Additional resources:

https://en.wikipedia.org/wiki/Perfect_forward_secrecy

https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy

https://www.eff.org/deeplinks/2013/08/pushing-perfect-forward-secrecy-important-web-privacy-protection

http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html

https://www.facebook.com/notes/facebook-engineering/secure-browsing-by-defa%20ult/10151590414803920

http://googleonlinesecurity.blogspot.co.uk/2011/11/protecting-data-for-long-term-with.html

 

Martin McKeay is a Senior Security Evangelist at Akamai

Akamai Security Videos, Part 1

Several readers have asked me where they can find all our podcasts and videos. Our soon-to-be-released security microsite will make everything easy to find. But for now, we're creating a series of round-ups. Yesterday we published the first six podcast episodesFurther down the road, we'll have a round-up of our security webinars. What follows is the first compilation of videos.

What's a Zero-Day Vulnerability?
Akamai Chief Security Officer Andy Ellis gives a whiteboard lesson on zero-day vulnerabilities.

An Overview of Tokenization & the Credit Card Industry
Akamai CSO Andy Ellis gives an overview of tokenization and why it exists, as well as a brief history of the credit card industry.

Josh Corman on Different Adversary Classes
Akamai Director of Security Intelligence Josh Corman gives an overview of different adversary classes and their motivations.

An Overview of the OSI Model with Akamai CSO Andy Ellis
In this video, Akamai CSO Andy Ellis gives an overview of the OSI model, abstraction layers, HTTP, TCP/IP and how together these things make the Internet work.

Security Means Different Things to Different People
In this video, Akamai CSO Andy Ellis explains why security means different things to different people.

A Primer on Security Laws
In this video, Akamai CSIRT Director Michael Smith walks viewers through the regulatory minefield. It's a great primer, though we suggest, as always, that you consult your own attorneys to understand how the laws and standards discussed in this video apply to you.

video-clapperboard-512x512.png


Mastering Multi-Channel Madness

Note: This is the final blog post to our "Crush the Rush" holiday readiness webinar series.

Last week I teamed up with Steve Tack, VP of Product Management for Compuware APM, to talk about Mastering Multi-Channel Madness as part of our Crush the Rush holiday readiness webinar series.

Steve walked through five common mobile pitfalls ranging from making mobile users wait to having mobile myopia to not leveraging third parties value.

LJpost 1.png

We all know that overcoming these pitfalls will be key to our success this holiday season. Whether it is delighting end-users with speed, or leveraging third parties to drive additional value  - or even innovating with agility - all of these areas hold the key to our holiday success. 

 

Before we get ahead of ourselves, let's take a look at the reality for your customers today. Most retailers jumped into mobile. And let's be clear - mobile isn't just smartphones - it also includes tablets. In fact, if we look at the last holiday shopping season we saw an extraordinary amount of traffic from tablets - in particular during Thanksgiving - so much traffic that this phenomenon started being dubbed couch commerce.

    In Episode 6 of the Akamai Security Podcast, I continue my discussion with CSIRT Director Michael Smith. In this installment, Mike describes the process by which CSIRT delivers daily threat intelligence to our customers, along with the defensive measures needed to block attacks.

    Bio: Michael Smith is a senior security manager with more than 20 years of experience in the IT security and intelligence fields performing security design and engineering, information assurance, web development, and security testing.

    Photo courtesy of Bank Info Security


    rsa2013_michael_smith_1280x720_v2.jpg

    Webinar: Preparing Your Web Security Strategy

    For the third and final episode of our webinar series on Web security for small and medium businesses, Security Ledger Editor-in-Chief Paul Roberts joins me for a discussion on holiday-themed threats and strategies SMBs can adopt to fight back.

    Webinar: Threats and Defenses for Smaller Businesses

    Steve Ragan, a former hacker and current staff writer for CSOonline.com, joins me in part two of our series on Web security for small and medium businesses.

    The focus of this episode is on hacking techniques, attacks and defenses.

    Whither HSMs

    Hardware Security Modules (HSMs) are physical devices attached or embedded in another computer to handle various cryptographic functions.  HSMs are supposed to provide both physical and logical protection of the cryptographic material stored on the HSM while handling cryptographic functions for the computer to which they are attached.
    As websites move to the cloud, are HSMs the right way to achieve our goals?  
    Before we talk about goals, it is useful to consider a basic model for talking about them.  Our Safety team often uses the following model to consider whether a system is safe:
    What are the goals we are trying to achieve? (Or, in Leveson's STPA hazard-oriented view, what are the accidents/losses which you wish to prevent?)
    What are the adversaries we wish to defeat?
    What are the powers available to those adversaries? What *moves* are available to them?
    And finally, what controls inhibit adversaries' use of their powers, thus  protecting our goals?
    Our hazards (or unacceptable losses) are:
    An adversary can operate a webserver that pretends to be ours;
    An adversary can decrypt SSL traffic; and
    An adversary can conduct a man-in-the-middle attack on our SSL website.
    In the protection of SSL certificates in the cloud, it would seem that our goals are two-fold:
    Keep the private key *secret* from third parties; and
    Prevent unauthorized and undetected use of the key in cryptographic functions. While SSL certificate revocation is a weak control (many browsers do not check for revocation), it is that which generally constrains this goal to both unauthorized *and* undetected; a detected adversary can be dealt with through revocation.
    I could argue that the first is a special case of the second, except that I want to distinguish between "cryptographic functions over the valid lifetime of the certificate" and "cryptographic functions after the certificate is supposed to be gone."
    As an aside, I could also argue that these goals are insufficient; after all, except for doing man in the middle attacks, *any* SSL certificate signed by any of the many certificate authorities in the browser store would enable an adversary to cause the first of the losses.  HSMs don't really help with that problem.
    Given that caveat, what are the interesting adversaries?  I propose four "interesting" adversaries, mostly defined by their powers:
    The adversary who has remotely compromised a server;
    The adversary who has taken physical control of a server which is still online;
    The adversary who has taken physical control of a server at end of life; and
    The adversary who has been given administrative access to a system.
    The moves available to these adversaries are clear:
    Copy key material (anyone with administrative access);
    Change which key material or SSL configuration we'll use (thus downgrading the integrity of legitimate connections)
    Escalate privileges to administrative access (anyone with physical or remote access); and
    Make API calls to execute cryptographic functions (anyone with administrative access).
    What controls will affect these adversaries?
    Use of an HSM will inhibit the copying of keying material;
    Use of revocation will reduce the exposure of copied keying material;
    System-integrated physical security (systems that evaluate their own cameras and cabinets, for instance) inhibit escalation from physical access to administrative access;
    Auditing systems inhibits adversary privilege escalation;
    Encrypting keying material, and only providing decrypted versions to audited, online systems inhibits adversaries with physical control of systems.
    What I find interesting is that for systems outside the physical purview of a company, HSMs may have a subtle flaw: since HSMs must provide an API to be of use, *that API remains exposed to an adversary who has taken possession of an HSM*.  This may be a minor issue if an HSM is in a server in a "secure" facility, it becomes significant in distributed data centers.  On the contrary, the control system which includes tightly coupled local physical security, auditing, and software encryption may strike a different balance: slightly less stringent security against an adversary who can gain administrative access (after all, they can likely copy the keys), in exchange for greater security against adversaries who have physical access.
    This isn't to say that this is the only way to assemble a control system to protect SSL keys; merely that a reflexive jump to an HSM-based solution may not actually meet the security goals that many companies might have.
    (Full disclosure: I'm the primary inventor of Akamai's SSL content delivery network, which has incorporated software-based key management for over a decade.)

    Twitter Chat: Protecting Critical Infrastructure

    Yesterday, Akamai InfoSec participated in a second Twitter forum as part of National Cyber Security Awareness Month. Participants supplied a ton of great resources, which I think is worth sharing here. 

    What follows are some of the tweets from the conversation. If you want to better understand the threats to critical infrastructure and what's being done about it, you'll find what follows useful.

    I was on a flight yesterday that had engine failure. Realtime telemetry was being sent to HQ. How easy would it be hack that? #ChatSTC


    This video shows how we protect our network + help customers prepare for disaster: soc.att.com/HrWlGd ^CB #NCSAM #ChatSTC




    14h

    When critical #infrastructure is impacted, verify the issue through authoritative sources like #USCERT @ us-cert.gov/ncas #ChatSTC