Cyber Resilience Towards the Quantification of Cyber Security Threats

The World Economic Forum and its partners have developed and shared a way for organizations to calculate the impact of cyber security threats. The framework, called cyber value-at-risk comes at a time when cyberattacks are increasing in velocity and intensity, and when 90% of companies worldwide recognize they are insufficiently prepared to protect themselves against them.

Cyber Resilience workshop at the World Economic Forum meeting in Tianjin, China. September 2014.

Download the full report here: Partnering for Cyber Resilience Towards the Quantification of Cyber Threats

Cyber Resilience workshop at the World Economic Forum meeting in Tianjin, China. September 2014.

I feel honored to have been one of the participants in the development of this. The project is led by Elena Kvochko and team of the World Economic Forum in collaboration with Deliotte and other Forum partners.

Cyber Resilience workshop at the World Economic Forum meeting in Tianjin, China. September 2014.

The World Economic Forum announced this today at the annual meeting in Davos.

(Source: WEF Press Release: New Framework to Help Companies Calculate Risk of Cyberattacks)

9 Reasons Why News Media Web Sites Should Consider Moving to HTTPS in 2015

If you work in news media and are interested in technology, you may enjoy my article listing 9 Reasons Why News Media Web Sites Should Consider Moving to HTTPS in 2015. I co-authored it with Eitan Konigsburg and Elena Kvochko, two colleagues with expertise, deep knowledge and passion for cyber security, privacy and technology.

It is published on the Times Open Blog maintained by the Software Engineering Team at The New York Times.

My personal Web site, is served exclusively on HTTPS thanks to CloudFlare.

Why investors should care about cyber security breaches

If you are interested in business, technology, and cyber security, you may enjoy my article about why investors should care about cyber security breaches. I co-authored it with Elena Kvochko, a leader in the field of cyber resilience.

SHA-3 Hash Generator

SHA-3, originally known as Keccak is a cryptographic hash function. Learn more on WikiPedia…

Enter text below to generate the SHA-3 Hash Code for

Output length in bits:

The SHA-3 Hash Code is below

Management & Technical Career Growth Tracks (v2)

Click on the diagram above to view it as a zooming presentation.

This second version of the diagram illustrating technical career tracks reflects the following updates since version one:

  • A product management track is now included. (Future updates may include other tracks like design, editorial and marketing.)
  • There is no longer a contributor-level position on the people-management track. This is because most organizations do not have an entry-level position whose main job is to manage people yet is below the manager level.
  • The number of levels is still 5, but the two contributor levels below manager have been merged into one. The C-level (as in CEO, CTO, CFO, …) band has been added above the VP levels.
  • The director-level position in the technology track is now called principal architect or simply principal.
  • In the people management track, it is suggested that a manager directly supervise at least 3 contributors and that a director supervise at least 3 managers. Exceptions can be made to this guideline when it is well-justified, but these are suggested as the default requirement to hold these titles.

(Thanks to Brian Murphy and Brad Kagawa for their contributions to this system.)

Proposal for Linking To Users Across Social Networks @username@service

We present here a convention for linking to users across social networks.

Social networks have evolved into a category of their own. They are not like most Web sites in the traditional sense and even when considered modern Web apps, they are a special type of application. They have become our new digital personas. Email used to be our online persona. Blog URLs (especially when coupled with OpenID) have also served that purpose. Instant messenger IDs and online forum handles have been also serving as our partial online identities. Social network personas combine elements of all  of these: Personal blog/comment URLs, email, discussions and real-time chat.

We often see people including their Twitter usernames ( e.g. @rajivpant ) as contact info on presentations, business cards and email signatures. This has helped make Twitter even more popular. There is a need for a simple, short and consistent way to refer to a user on any social network.

We propose three alternative options.1 A. @username@socialnetwork , B. socialnetwork:@username and a third option as conventions to link to users across social networks. Why? Because Twitter has already made the @username widely popular. These conventions are backwards compatible and extend the existing convention to include other social networks.

Option A.  @username@service

On Twitter posts (tweets), you would continue refer to a Twitter user as @rajivpant (implying a Twitter user as the default). On posts on other sites, you would refer to the user as @rajivpant@twitter and still have it link to the user’s page on Twitter (and potentially also notify them on Twitter). That way, we’d have a consistent person naming and linking convention across social networks and perhaps even blogs. E.g. @rajiv.pant@facebook , @rajiv.pant@linkedin , @rajiv.pant@google and @rajivpant@tumblr


Option B.  service:@username (URL format)

On Twitter posts (tweets), you would continue refer to a Twitter user as @rajivpant (implying a Twitter user as the default). On posts on other sites, you would refer to the user as twitter:@rajivpant and still have it link to the user’s page on Twitter (and potentially also notify them on Twitter). That way, we’d have a consistent person naming and linking convention across social networks and perhaps even blogs. E.g. facebook:@rajiv.pant , linkedin:@rajiv.pant , google:@rajiv.pant and tumblr:@rajivpant

Option C.  sn:username@servicedns (Unified URL format)

A third option, and one that we originally proposed is to have social network URLs like sn:[email protected] where sn:would be a universal social network protocol handler that would be distinct from the email URL syntax of mailto:[email protected] . It would avoid the need of per-site handlers like twitter:@rajivpant on iOS that are becoming common.

One benefit of having the @ (or + in Google+) at the beginning is that the text editor can start to autocomplete the name for you. It would still continue to do that. However, when you type @@, it would first give you a list of other social networks and then could even show you names from your connections on other social networks if you have authorized it!

In your contacts (e.g. MacOS Address Book), you could then enter someone’s social network addresses using the @username@socialnetwork or the sn: URL format. When someone clicks on an @@ or sn: link, the URL handler would first look to see if there is registered custom app for that domain name (e.g. Twitter client on MacOS or iOS) and then launch that app. If no app is registered for that social network’s domain, it would map it to an http: URL like , or
This would avoid social network specific URL formats like twitter:@rajivpant proposed by option B.

For brevity, the URLs could simply be in the format @username@twitter , @username@facebook , @username@linkedin and If such shorter forms are adopted, then each social network’s brand name could be registered via a system of registries or it could default to .com if the full domain name isn’t specified. We could also have shortcuts like @rajiv.pant@fb or fb:@rajiv.pant since Facebook owns the domain at the fb: URL schema on iOS.

Either way, a number of people have agreed that this problem needs to be solved. Which option do you prefer, A, B, or C?

  1. Thanks to Adnan Alam and Vinod Unny for suggesting option B. []

Hosting Large-Scale Web Sites: Contract Review Guide for the CTO

If you host and operate large-scale Web sites, or negotiate contract agreements with vendors that provide such services, you need to understand what should be included in a Web hosting infrastructure. This knowledge will help you in three areas:

  1. Providing reliability, scalability & good performance
  2. Minimizing risks via security, privacy, regulatory compliance and reduction of vulnerability to potential lawsuits
  3. Reducing and controlling costs

This guide is meant to help you review upcoming contracts as well as existing services.

Likely audience for this article: Managers, directors and vice presidents of technology, operations or finance at organizations operating large-scale Web sites; Executives supervising technology: CTO, CIO, CFO, COO.

Seven Aspects of Large-Scale Web Hosting

Large-scale Web hosting infrastructure and services can be organized into the following seven areas:

  1. Servers & Environments
  2. Network & Other Appliances
  3. Managed Hosting Services
  4. Third-party Provided Services
  5. Program Management Office, PMO
  6. Account Management
  7. Infrastructure & Facilities

Checklist for Review

You can use the following checklist to review your hosting services or a vendor’s proposal.

What to look for

When you review each item below, consider:

  • Is this item included in the vendor’s proposal or in the services we are currently receiving? If it is not included, what are the good reasons it isn’t included?
  • Is this needed for my organization’s current business requirements? Can we do without it? Is it a must have or nice to have for present and reasonable future needs?
  • What are the alternatives?
  • What is the unit price of this item? How does the price scale up as needs grow? How does the price scale down when need for this item decreases?
  • What level of fault-tolerance does this item need? i.e. redundancy, standby backups, time to recover

Some of the above review questions may apply only to things and not apply to services and processes.


Servers may be physical hardware servers and/or virtual servers managed using software such as VMWare, Parallels Virtuozzo or Xen. The services listed below can each run on separate servers or multiple services can run on a server. It is generally better to have servers running only one (or minimum number) of the major services listed below. That reduces complexity and saves expensive staff time saved maintaining, troubleshooting and recovering. Virtualization makes it economical to have multiple virtual servers on the shared physical hardware economize costs.

The following is a list of commonly found services at large-scale Web sites that require servers.

  • Web
  • Application
    • Content Management software. This is the software that the Editorial and Production teams use to submit, edit, package and manage articles, photos and other Web site content
    • Dynamic Content Assembly. Typically done using Portal Server software, either third-party supplied or in-house developed
    • Data Processing. E.g. workflow engines, jobs/tasks processing servers
    • Middleware
    • Other applications. These are applications that happen to be separate from the main content management system. They could be separate for any number of reasons. E.g. blogs, forums
  • Database

Server Environments

An environment is a self-sufficient set of servers assigned to serve a purpose as described below. Large-scale Web sites typically utilize multiple environments.

  • Production
    • This serves the Web sites to the customers and public.
    • Typically has 99.9% or higher uptime guarantee in the Service Level Agreement
      Please refer to the accompanying table titled Understanding SLA Uptime Guarantee Percentages to compare different time windows when the SLA Uptime measurement gets reset. I recommend that you ensure that the reset window you get is the same duration as your billing cycle (usually monthly) or shorter. This will help avoid having long downtimes without penalty.
  • Staging
    • This is the environment where content packages are developed, integrated and previewed by Editorial, Design and Production teams before they are published to the end-users. For example, when working on a major site redesign or relaunch for several months. Since the tech teams are often making changes to the Development Integration and QA environments, they are not suitable for content integration work by the Editorial and Design teams. Staging is used in large-scale Web sites where mutiple Editors, Designers and Production staff are collaboratively creating content packages and new sections. In smaller Web sites or in cases where just one or two Editors are working on a piece of content like an individual article, previewing is done in the Production environment itself with access controls.
  • Quality Assurance (QA)
    • The QA engineers perform Functional Testing and Load Testing here. Doing functional testing while a load test is running is sometimes a good idea as it simulates usage closer to live production.
  • Development Integration
    • Software product code developed by different engineers is integrated here. There could be continuous integration or nightly builds.
    • This is where developers ensure that their code works with other developers’ code (does not break the build, and does not conflict resulting in undesired functionality)
    • Programmers should ensure that the product works here before handing it off to the QA engineers for testing

In a virtualized system the environments may not be physically separate and may regularly grow and shrink at different times. For example when hosted at a cloud computing provider, the QA environment may scale up during load testing and shut down completely during the hours the QA team is not working.

Network & Other Appliances

These are devices to which various servers are directly or indirectly connected.

Managed Hosting Services

  • Systems Administration
    • This typically includes all the management of the physical hardware up to and including the operating system and popular applications that complement the operating system.
  • Database Administration Services
  • Applications Management Services
    • This typically includes all the administration of the applications that run on top of the operating system.
  • Systems Monitoring, Alerting & Reporting
  • Web Support Help Desk, 24×7

Third-party Services

Program Management Office, PMO

  • Project Management
    • PM people, organization, processes
    • Collaborative project management tools, e.g. JIRA, RallyDev, Mingle
    • Shared documentation management tools, e.g. Wiki
  • Change Management Processes & Tools
    • Documentation system
    • Tools for source control, build & deployment
  • RASIC Matrix Describing Roles & Responsibilities
  • Escalation Flowcharts
  • Crisis Management & Emergency Procedures

Account Management

  • Customer service
  • Relationship management
  • Master Services Agreement, MSA
  • Statements of Work, SOW
  • Service Level Agreement, SLA
    • What to look for in the SLA is the subject of a separate article in this series.
  • Billing & Service Level Agreements
    • Monthly bills provided by telecommunications (telco) and hosting companies tend be extremely complex and lengthy. As a result, they are difficult and time-consuming to review.
    • Always factor in one-time setup fees and any implementation fees paid to the vendor and/or their partners in the total cost of the contract. Don’t look only at the recurring charges. A simple way to do this is this:
      contract cost = implementation fees + (estimated recurring fees x number of recurrences committed to)
      e.g. contract cost for 1 year = setup fees + (estimated monthly charges x 12)
      For most hosting / telco contracts I recommend this simple calculation over more sophisticated methods that factor in time value of money because the recurring fees are estimates anyway.
    • Make sure that 1-year contract is really a 1-year contract and not effectively a 13-month, 15-month or even longer contract by ensuring the following:
    • The contract’s start date is the first date for which the recurring billing begins. This is useful in determining the default end date of the contract. For example:
      If you agree to a 1-year contract with monthly billing when the first monthly bill will be for services provided April, 1, 2010 through April 20, 2010, then the default termination date for the contract is March 31, 2011. If the service provider estimates 3 months for implementation that ends on June 30, 2010 and they charge you the monthly services for April, May and June, don’t let the vendor tell you the contract start date is July 1. If you paid the monthly fees for services provided on April 1, then the start date is April 1.
    • If the vendor charges you fractional monthly fees for the implementation period and/or charges you one-time set up fees, then you should negotiate and agree on a contract end date that is fair to both parties. Use this guideline: The contract commitment should aim towards a certain money target (revenue for the vendor). If the implementation fees are equivalent to say, 3 months of recurring billing, you might agree that end date is after 9 months of the first recurring billing cycle.

Tips for Reviewing Technology Vendor Contracts and Service Level Agreements (SLA)

  • Don’t let the vendor use a lower monthly rate for calculating SLA credits.

    An example: The vendor’s contract section X.YZ1 states that the customer’s service credits will be calculated against a monthly rate of $6,000.00 per month. However, the vendor’s estimated total charges seem to be at least $10,000 per month. Don’t let the vendor calculate service credits based on a lower monthly bill than the actual monthly bill.

  • Don’t get locked into a deal where you could be stuck with overages every month.

    An example: The vendor’s contract section X.YZ2 locks the customer into the vendor’s service for two years for a total of between $80K/month to $100K/month if the customer remains at under 100 million page views per month. If the customer’s page views go over 100 million in any month, then there will be additional overage charges. There is no out clause nor a pre-determined next rate tier in the customer’s favor in the contract. If customer s traffic rises to regularly being over 100 million page views per month, the customer will be trapped in a contract with recurring overage charges. Make sure that if you have overages in the future, you can move into the next tier, preferably at a better rate.

  • Beware of vaguely defined scheduled maintenance and make sure scheduled maintenance needs customer’s prior approval.

    An example: The SLA section X.YZ3 states that the vendor can schedule maintenance downtime with 48 hours notice. They can give the customer notice by one of many means. There is no requirement for the customer to review or even acknowledge receipt. This is slanted too much in vendor s favor. The customer should have some ability to reschedule scheduled maintenance or ask for it to be shorter in duration if it interferes with the customer’s business.

  • Make sure that service credits can also be redeemed as cash.

    An example: The SLA section X.YZ4 states that service credits are not cash. Such credits will only be applied to future service billings. This is usually fine, except if it happens in the last month of the contract or if there is not enough future usage to use up the credits. In such instances, service credits should be payable as cash.

  • If the vendor will charge you for overages, the vendor needs to be responsible for service at the overage usage levels too.

    An example: The SLA section X.YZ5 states that response time service credits will not apply if monthly page-views exceed 120 million. This is not fair to the customer. The vendor is fine with charging the customer overage fees, but not being responsible for level of service at those levels. If the vendor charges overage fees, it should bind them to providing full service at the exceeded usage as well.

Infrastructure & Facilities

This item, infrastructure & facilities, is beyond the scope of this article. It includes the buildings, electric power, generators, climate control, physical security and related staffing.

This article is part of a series titled “Guide for the CTO: A compilation of articles on how to lead and manage technologies, projects and people”.

Understanding SLA Uptime Percentages

The table below helps illustrate why you should ensure that the “SLA Uptime Measurement Meter Reset Window” is the same duration as your billing cycle or shorter.

Availability % Downtime per year Downtime per month (30 days) Downtime per week Downtime per day
90 “one nine” 36.5 days 72 hours 16.8 hours 2.4000 hours
95 18.25 days 36 hours 8.4 hours 1.2000 hours
97 10.96 days 21.6 hours 5.04 hours 43.2000 minutes
98 7.3 days 14.4 hours 3.36 hours 28.8000 minutes
99 “two nines” 3.65 days 7.2 hours 1.68 hours 14.4000 minutes
99.5 1.83 days 3.6 hours 50.4 minutes 7.2000 minutes
99.8 17.52 hours 86.23 minutes 20.16 minutes 2.8800 minutes
99.9 “three nines” 8.76 hours 43.8 minutes 10.1 minutes 1.4400 minutes
99.95 4.38 hours 21.56 minutes 5.04 minutes 43.2000 seconds
99.99 “four nines” 52.56 minutes 4.32 minutes 1.01 minutes 8.6400 seconds
99.999 “five nines” 5.26 minutes 25.9 seconds 6.05 seconds 0.8640 seconds
99.9999 “six nines” 31.5 seconds 2.59 seconds 0.605 seconds 0.0864 seconds
99.99999 “seven nines” 3.15 seconds 0.259 seconds 0.0605 seconds 0.0086 seconds

Sources: Wikipedia, my calculations

How to Avoid Duplicate Search Results when using Apple with Gmail

I use Gmail’s IMAP feature with my Apple Mac OS’s built in program. keeps local copies (on all my personal Macs) of all my email messages that I’ve kept (since 1994). It enables me to:

  • Effectively work offline with all my emails (searching, reading and composing), when my computer is not online. That’s sometimes the case when I’m traveling, especially in places where Internet access is unavailable, unreliable, slow, insecure or too expensive.
  • Regularly back up all my saved emails using Apple’s Time Machine. It is also a precaution in case I someday no longer have my Gmail account and/or move to another email service. With email account theft rampant these days, it is important to have up to date backups of all your emails.
  • Send digitally signed and encrypted emails when needed.
  • Compose greeting cards and other visually rich emails with pictures on’s stationary.

The Problem:

When you initially set up to use Gmail via IMAP, you will observe that when you search your mail using Apple’s built in Spotlight feature, the search results will show duplicate (or more) copies of your email. This is because Gmail’s labels and special views (like “All Mail” or “Starred”) appear as separate IMAP folders in Messages in these seemingly “separate IMAP folders” appear to be duplicates to and Spotlight search.

The Solution:

To solve this problem, I suggest showing only essential Gmail special views and labels as IMAP folders to Gmail and then telling Spotlight search to only index the master copies of the messages in Gmail’s “All Mail” folder. To accomplish this, I did the following.

Note: I do the labeling of my messages via the Gmail Web interface and do not need to see the labels applied to messages when I’m using My solution below hides all my custom Gmail labels from and that’s fine with me.

In Gmail (via the Web interface)

Go to “Settings > Labs” and activate “Advanced IMAP Controls“. After enabling it, go to “Settings > Labels” and uncheck “Show in IMAPfor each custom Gmail label you have created. Also uncheck it for “Starred” since shows to do flags in messages in other folders.

Leave “Show in IMAPchecked yes for “Inbox“, “Sent Mail“, “Drafts“, “All Mail” and “Trash” since these are system folders and Apple should be configured to use them. Also leave it checked yes for a label folder called “Apple Mail To Do” which is an Apple Mail system folder.

On your Macs

Go to “System Preferences > Spotlight > Privacy“, exclude the following folders from appearing in search results. Where it says [email protected] below, use your Gmail account name.

~/Library/Mail/IMAP-[email protected]/INBOX.imapmbox

~/Library/Mail/IMAP-[email protected]/[Gmail]/Sent Mail.imapmbox

Also, if you are displaying your starred folder via IMAP, exclude:

~/Library/Mail/IMAP-[email protected]/[Gmail]/Starred.imapmbox

Now when you search messages in your Mac’s, only results from your Gmail All Mail folder will appear.

Checklist for Migration of Web Application from Traditional Hosting to Cloud

In 2010, Cloud Computing is likely to see increasing adoption. Migrating Web applications from one data center to another is a complex project. To assist you in migrating Web applications from your hosting facilities to cloud hosting solutions like Amazon EC2, Microsoft Azure or RackSpace’s Cloud offerings, I’ve published a set of checklists for migrating Web applications to the Cloud.

These are not meant to be comprehensive step-by-step, ordered project plans with task dependencies. These are checklists in the style of those used in other industries like Aviation and Surgery where complex projects need to be performed. Their goal is get the known tasks covered so that you can spend your energies on any unexpected ones. To learn more about the practice of using checklists in complex projects, I recommend the book Checklist Manifesto by Atul Gawande.

Your project manager should adapt them for your project. If you are not familiar with some of the technical terms below, don’t worry: Your engineers will understand them.

Pre-Cutover Migration Checklist

The pre-cutover checklist should not contain any tasks that “set the ship on sail”, i.e. you should be able to complete the pre-cutover tasks, pausing and adjusting where needed without worry that there is no turning back.

  • Set up communications and collaboration
    • Introduce migration team members to each other by name and role
    • Set up email lists and/or blog for communications
    • Ensure that appropriate business stakeholders, customers and technical partners and vendors are in the communications. (E.g. CDN, third-party ASP)
  • Communicate via email and/or blog
    • Migration plan and schedule
    • Any special instructions, FYI, especially any disruptions like publishing freezes
    • Who to contact if they find issues
    • Why this migration is being done
  • Design maintenance message pages, if required
  • Setup transition DNS entries
  • Set up any redirects, if needed
  • Make CDN configuration changes, if needed
  • Check that monitoring is in place and update if needed
    • Internal systems monitoring
    • External (e.g. Keynote, Gomez)
  • Create data/content migration plan/checklist
    • Databases
    • Content in file systems
    • Multimedia (photos, videos)
    • Data that may not transfer over and needs to be rebuilt at new environment (e.g. Search-engine indexes, database indexes, database statistics)
  • Export and import initial content into new environment
  • Install base software and platforms at new environment
  • Install your Web applications at new environment
  • Compare configurations at old environments with configurations at new environments
  • Do QA testing of Web applications at new environment using transition DNS names
  • Review rollback plan to check that it will actually work if needed.
    • Test parts of it, where practical
  • Lower production DNS TTL for switchover

During-Cutover Migration Checklist

  • Communicate that migration cutover is starting
  • Data/content migration
    • Import/refresh delta content
    • Rebuild any data required at new environment (e.g. Search-engine indexes, database indexes, database statistics)
  • Activate Web applications at new environment
  • Do QA testing of Web applications at new environment
  • Communicate
    • Communicate any publishing freezes and other disruptions
    • Activate maintenance message pages if applicable
  • Switch DNS to point Web application to new hosting environment
  • Communicate
    • Disable maintenance message pages if applicable
    • When publishing freezes and any disruptions are over
    • Communicate that the Web application is ready for QA testing in production.
  • Flush CDN content cache, if needed
  • Do QA testing of the Web application in production
    • From the private network
    • From the public Internet
  • Communicate
    • The QA testing at the new hosting location’s production environment has passed
    • Any changes for accessing tools at the new hosting location
  • Confirm that DNS changes have propagated to the Internet

Post-Cutover Migration Checklist

  • Cleanup
    • Remove any temporary redirects that are no longer needed
    • Remove temporary DNS entries that are no longer needed
    • Revert any CDN configuration changes that are no longer needed
    • Flush CDN content cache, if needed
  • Check that incoming traffic to old hosting environment has faded away down to zero
  • Check that traffic numbers at new hosting location don’t show any significant change from old hosting location
    • Soon after launch
    • A few days after launch
  • Check monitoring
    • Internal systems monitoring
    • External (e.g. Keynote, Gomez)
  • Increase DNS TTL settings back to normal
  • Archive all required data from old environment into economical long-term storage (e.g. tape)
  • Decommission old hosting environment
  • Communicate
    • Project completion status
    • Any remaining items and next steps
    • Any changes to support at new hosting environment

The checklists are also published on the RevolutionCloud book Web site at and on the Checklists Wiki Web site at