Keeping the Lights On: Business Continuity for Office 365

Early in my career at Microsoft, I worked in Microsoft Consulting Services, supporting organizations looking to deploy Exchange 2007 and 2010 in their on-premises environments. During those engagements, the bulk of the conversations focused on availability and disaster recovery concepts for Exchange – things like CCR, SCR and building out the DAG to ensure performance and database availability during an outage – whether it was a disk outage, a server outage, a network outage or a datacenter outage.

Those were fun days. And by “fun”, I mean “I’m glad those days are over”.

It’s never a fun day when you have to tell a customer that they CAN have 99.999% availability (of course – who DOESN’T want five 9’s of availability??) for their email service, but it will probably cost them all the money they make in a year to get it.

Back then, BPOS (Business Productivity Online Service) wasn’t really on the radar for most organizations outside of some larger corporate and government customers.

Then on June 28, 2011, Microsoft announced the release of Office 365 – and the ballgame changed. In the years since then, Office 365 has become a hugely popular service, providing online services to tens of thousands of customers and millions of users.

As a result, more businesses are using Office 365 for their business-critical information. This, of course, is great for our customers, because they get access to a fantastic online service, but it requires a high degree of trust on the part of customers that Microsoft is doing everything possible to preserve the confidentiality, integrity and availability of their data.

A large part of that means that Microsoft must ensure that the impact of natural disasters, power outages, human attacks, and so on are mitigated as much as possible. I recently heard a talk given that dealt with how Microsoft builds our datacenters and account for all sorts of disasters – earthquakes, floods, undersea cable cuts – even mitigations for a meteorite hitting Redmond!

It was an intriguing discussion and it’s good to hear the stories of datacenter survivability in our online services, but the truth is, customers want and need more than stories. This is evidenced by the fact that the contracts that are drawn up for Office 365 inevitably contain requirements related to defining Microsoft’s business continuity methodology.

Our enterprise customers, particularly those from regulated industries, are routinely required to perform business continuity testing to demonstrate that they are taking the steps necessary to keep their services up and running when some form of outage or disaster occurs.

The dynamics change somewhat when a customer moves to Office 365, however. These same customers now must assess the risk of outsourcing their services to a supplier, since the business continuity plans of that supplier directly impact the customer’s adherence to the regulations as well. In the case of Office 365, Microsoft is the outsourced supplier of services, so Microsoft’s Office 365 business continuity plans become very relevant.

Let’s take a simple example:

A customer named Contoso-Med has a large on-premises infrastructure. If business continuity testing were being done in-house by Contoso-Med and they failed the test, they would be held responsible for making the necessary corrections to their processes and procedures.

Now, just because Contoso-Med has moved those same business processes and data to Office 365, they are not absolved of the responsibility to ensure that the services meet the business continuity standards defined by regulators. They must still have a way of validating that Microsoft’s business continuity processes meet the standards defined by the regulations.

However, since Contoso-Med doesn’t get to sit in and offer comments on Microsoft’s internal business continuity tests, they must have another way of confirming that they are compliant with the regulations.

First…a Definition

Before I go much further, I want to clarify something.

There are several concepts that often get intermingled and, at times, used interchangeably: high availability, service resilience, disaster recovery and business continuity. We won’t dig into details on each of these concepts but suffice it to say they all have at their core the desire to keep services running for a business when something goes wrong. However, “business continuity and disaster recovery” from Microsoft’s perspective means that Microsoft will address the recovery and continuity of critical business functions, business system software, hardware, IT infrastructure services and data required to maintain an acceptable level of operations during an incident.

To accomplish that, the Microsoft Online Service Terms (http://go.microsoft.com/?linkid=9840733),which is sometimes referred to as simply the OST, currently states the following regarding business continuity:

  • Microsoft maintains emergency and contingency plans for the facilities in which Microsoft information systems that process Customer Data are located
  • Microsoft’s redundant storage and its procedures for recovering data are designed to attempt to reconstruct Customer Data in its original or last-replicated state from before the time it was lost or destroyed

 

Nice Definition. But How Do You Do It?

I’ve referenced the Service Trust portal in a few other blog posts and described how it can help you track things like your organization’s compliance for NIST, HIPAA or GDPR. It’s also a good resource for understanding other efforts that factor into the equation of whether Microsoft’s services can be trusted by their customers and partners.

A large part of achieving that level of trust relates to how we set up the physical infrastructure of the services.

To be clear, Microsoft online services are always on, running in an active/active configuration with resilience at the service level across multiple data centers. Microsoft has designed the online services to anticipate, plan for, and address failures at the hardware, network, and datacenter levels. Over time, we have built intelligence into our products to allow us to address failures at the application layer rather than at the datacenter layer, which would mean relying on third-party hardware.

As a result, Microsoft is able to deliver significantly higher availability and reliability for Office 365 than most customers are able to achieve in their own environments, usually at a much lower cost. The datacenters operate with high redundancy and the online services are delivering against the financially backed service level agreement of 99.9%.

The Office 365 core reliability design principles include:

  • Redundancy is built into every layer: Physical redundancy (through the use of multiple disk, network cards, redundant servers, geographical sites, and datacenters); data redundancy (constant replication of data across datacenters); and functional redundancy (the ability for customers to work offline when network connectivity is interrupted or inconsistent).
  • Resiliency: We achieve service resiliency using active load balancing and dynamic prioritization of tasks based on current loads. Additionally, we are constantly performing recovery testing across failure domains, and exercising both automated failover and manual switchover to healthy resources.
  • Distributed functionality of component services: Component services of Office 365 are distributed across datacenters and regions to help limit the scope and impact of a failure in one area and to simplify all aspects of maintenance and deployment, diagnostics, repair and recovery.
  • Continuous monitoring: Our services are being actively monitored 24×7, with extensive recovery and diagnostic tools to drive automated and manual recovery of the service.
  • Simplification: Managing a global, online service is complex. To drive predictability, we use standardized components and processes, wherever possible. A loose coupling among the software components results in a less complex deployment and maintenance. Lastly, a change management process that goes through progressive stages from scope to validation before being deployed worldwide helps ensure predictable behaviors.
  • Human backup: Automation and technology are critical to success, but ultimately, its people who make the most critical decisions during a failure, outage or disaster scenario. The online services are staffed with 24/7 on-call support to provide rapid response and information collection towards problem resolution.

These elements exist for all the online services – Azure, Office 365, Dynamics, and so on.

But how are they leveraged during business continuity testing?

Each service team tests their contingency plans at least annually to determine the plan’s effectiveness and the service team’s readiness to execute the plan. The frequency and depth of testing is linked to a confidence level which is different for each of the online services. Confidence levels indicate the confidence and predictability of a service’s ability to recover.

For details on the confidence levels and testing frequencies for Exchange Online, SharePoint Online and OneDrive for Business, etc… please refer to the most recent ECBM Plan Validation Report available on the Office 365 Service Trust Portal.

BC/DR Plan Validation Report – FY19 Q1

A new reporting process has been developed in response to Microsoft Online Services customer expectations regarding our business continuity plan validation activities. The reporting process is designed to provide additional transparency into Microsoft’s Enterprise Business Continuity Management (EBCM) program operations.

The report will be published quarterly for the immediately preceding quarter and will be made available on the Service Trust Portal (STP). Each report will provide details from recent validations and control testing against selected online services.

For example, the FY19 Q1 report, which is posted on the Service Trust Portal (ECBM Testing Validation Report: FY19 Q1), includes information related to 9 selected online services across Office 365, Azure and Dynamics, with the testing dates and testing outcomes for each of the selected services.

The current report only covers a subset of Microsoft cloud services, and we are committed to continuously improving this reporting process.

If you have any questions or feedback related to the content of the reporting, you can send an email to the Office 365 CXP team at cxprad@microsoft.com.

Additional Business Continuity resources are available on the Trust Center , Service Trust Portal, Compliance Manager and TechNet

  1. Azure SOC II audit report:  The Azure SOC II report  discusses business continuity (BC) starting on page 59 of the report, and the auditor confirms no exceptions noted for BC control testing on page 95.
  2. Azure SOC Bridge Letter Oct-Dec 2018 : The Azure SOC Bridge letter confirms that there have been no material changes to the system of internal control that would impact the conclusions reached in the SOC 1 type 2 and SOC 2 type 2 audit assessment reports.
  3. Global Data Centers provides insights into Microsoft’s framework for datacenter Threat, Vulnerability and Risk Assessments (TVRA)
  4. Office 365 Core – SSAE 18 SOC 2 Report 9-30-2018: Similar to the Azure  365 SOC II audit report (dated 10/1/2017 through 9/30/2018) discusses Microsoft’s position on business continuity (BC) in Section V, page 71 and the auditor confirms no exceptions noted for the CA-50 control test on page 66.
  5. Office 365 SOC Bridge Letter Q4 2018 : SOC Bridge letter confirming no material changes to the system of internal control provided by Office 365 that would impact the conclusions reached in the SOC 1 type 2 and SOC 2 type 2 audit assessment reports.
  6. Compliance Manager’s Office 365 NIST 800-53 control mapping provides positive (PASS) results for all 51 Business Continuity Disaster Recovery (BCDR)-related controls within Microsoft Managed Controls section, under Contingency Planning. For example, the Exchange Online Recovery Time  Objective and Recovery Point Objective (EXO RPO/RTO) metrics are tested by the third-party auditor per NIST 800-53 control ID CP2(3). Other workloads, such as SharePoint Online, were also audited and discussed in the same control section.
  7. ISO-22301  This business continuity certification has been awarded to Microsoft Azure, Microsoft Azure Government, Microsoft Cloud App Security, Microsoft Intune, and Microsoft Power BI. This is a special one. Microsoft is the first (and currently the ONLY) hyperscale cloud service provider to receive the ISO 22301 certification, which is specifically targeted at business continuity management. That’s right. Google doesn’t have it. Amazon Web Services doesn’t have it. Just Microsoft.
  8. The Office 365 Service Health TechNet article provides useful information and insights related to Microsoft’s notification policy and post-incident review processes
  9. The Exchange Online (EXO) High Availability TechNet article outlines how continuous and multiple EXO replication in geographically dispersed data centers ensures data restoration capability in the wake of messaging infrastructure failure
  10. Microsoft’s Office 365 Data Resiliency Overview outlines ways Microsoft has built redundancy directly into our cloud services, moving away from complex physical infrastructure toward intelligent software to build data resiliency
  11. Microsoft’s current SLA commitments for online services
  12. Current worldwide up times are reported on Office 365 Trust Center Operations Transparency
  13. Azure SLAs and uptime reports are found on Azure Support

As you can see, there are a lot of places where you can find information related to business continuity, service resilience and related topics for Office 365.

This type of information is very useful for partners and customers who need to understand how Microsoft “keeps the lights on” with its Office 365 service and ensures that customers are able to meet regulatory standards, even if their data is in the cloud.

 

Setting Up a Kali Linux Machine in Azure

A Quick Overview of Kali

One of the tools that many security professionals use on a regular basis is the Kali Linux penetration testing platform. This tool is built and maintained by Offensive Security (www.offensive-security.com), an organization that also provides extensive training on the platform and a variety of other security and penetration testing topics.

1_KaliDesktop

The Kali Linux platform is based on Debian GNU/Linux distro and contains hundreds of open source penetration-testing, forensic analysis, and security auditing tools. However, it isn’t exclusively used by traditional “red teams” and “blue teams”. In fact, it can also be used by IT admins to monitor their networks effectively (whether wired or wireless), perform analysis of data, and a variety of other tasks.

It’s important to remember that Kali Linux is NOT a static tool. Rather, you’ll likely have updates to the Kali distro on a daily basis, so make sure you perform updates before use the tool every time. (I’ll show you how in a few minutes)

Kali Linux can run on laptops, desktops or servers. You can download the ISO for Kali from https://www.kali.org/downloads, and create a bootable USB drive if you want to. But what we are doing today is running it on Azure, and this is one of the easiest ways to get started.

Let’s take a look.

Provisioning Kali on Azure

The Kali Linux distro is available without cost on Azure, but it might not be obvious where to find it. If you log in to your Azure subscription and try to provision a Kali box, you simply won’t find it in the list of operating systems or images you can deploy.

What you actually need to do is request it from the Azure Marketplace. To do this, go to https://azuremarketplace.microsoft.com/en-us/marketplace/apps/kali-linux.kali-linux . There, you’ll see a page similar to the one shown below. Click on the “Get It Now” button to request the Kali Linux distro.

2_ProvisionKali

After you request the Kali Linux machine, you’ll be asked which account you use to sign in when you request apps from the Azure Marketplace. Enter the login ID that you use for your Azure subscription.

3_AzureMktplace

Once you request the machine as described above, you’ll be able to provision the Kali box just like you would any other virtual machine or appliance. There are a couple points that should be highlighted in the description provided when you provision the box.

First, the Installation Defaults section tells us that, by default, the only way to log in to your Kali instance is by using SSH over port 22 and using either a set of SSH keys or a user-provided password. This is because the default configuration for the installation does not include a graphical user interface (GUI). The majority of the tools in Kali work just fine without a GUI, so this is the preferred way to use it, but if you are just getting started, you may want the benefit of a GUI while you figure out how the tools work and how Linux itself is set up. I’ll show you how to install the GUI later in this article. For this article, I’ll be using a username/password to log in, but again, SSH keys are more secure and would be preferred in a production environment.

Additionally, we see that it is recommended that you update the packages on your Kali machine after you deploy it. I’ll walk you through how to do that as well.

4_KaliDefaults

After you’ve provisioned your Kali Linux machine (using username and password during the initial configuration in the Azure portal), you’ll want to connect to the machine.

To do so, download and install PuTTY, or a similar SSH/telnet tool. PuTTY can be downloaded here: https://putty.org/

When PuTTY is installed, it will require you to enter the IP address of your Kali machine in order to connect. You can get the public IP address of the Kali machine from the Azure portal, as shown below.

5_IPAddress

Next, open your PuTTY client and connect to the IP address and port 22 of your Kali machine.

6_PuTTY

One thing that’s unusual about the install is that the username and password that you defined for the Kali machine when you provisioned it does NOT have root access to the machine. This means you cant make any updates or modify the install with the set of credentials you are logging in with.

Let’s fix that.

As you can see below, I’m logged in to my machine KALI-001 as the user named KALIADMIN. I now need to set a password for the root (administrator) account.

To do this, I type:

sudo passwd root

Then I define the password I want to use. That’s all there is to it!

Now I can log in as root using the command

su root

7_SetPassword

Now that I’m logged in with root permissions, I need to update my Kali machine.

To do this, simply type:

apt update && apt dist-upgrade

Type y to confirm the updates. Depending upon how many updates are available, this could take a while. For example, when I ran this command after provisioning my machine, it took about 20 minutes to get all the updates.

8_UpdateKali

At this point, you have logged in over SSH, set a password for the root account and updated the machine. However, you still are doing everything from the command line. You may want to install GUI. Basically, there are three tasks you have to perform to be able to able to manage the Kali instance the same way you’d manage a Windows server:

1. Install a GUI
2. Install RDP
3. Configure networking to allow connection over RDP

Install a GUI

Kali comes by default with the GNOME desktop package, but you need to install it.
To do so, use the command below:

apt-get install -f gdm3

Install RDP

Next, you’ll need to install an RDP package and enable the services using the commands below.

apt-get install xrdp
systemctl enable xrdp
echo xfce4-session >~/.xsession
service xrdp restart

Configure Networking to Allow Connection over RDP

Lastly, you’ll need to configure your Azure Network Security Group (NSG) to allow TCP port 3389 inbound (RDP) to your Kali machine. In the Networking section of your machine’s configuration, configure an inbound port rule for TCP 3389. Again, this is a penetration testing tool, so in a production environment, you would likely lock down the source IP addresses that can connect to this machine, but for this demonstration, we are leaving it at Any/Any.

9_NSGRules

Now that you have this set up, you should be able to connect to your Kali box using RDP, just as you would connect to a typical Windows machine. The interface for GNOME will look something like this, but it can be customized.

10_GNUDesktop

What Can I Do With It?

In the past, Microsoft required you to submit an Azure Service Penetration Testing Notification form to let Microsoft know that it was not an actual attack against a tenant. However, as per the documentation noted here, https://docs.microsoft.com/en-us/azure/security/azure-security-pen-testing, this is no longer a requirement.

“As of June 15, 2017, Microsoft no longer requires pre-approval to conduct penetration tests against Azure resources. Customers who wish to formally document upcoming penetration testing engagements against Microsoft Azure are encouraged to fill out the Azure Service Penetration Testing Notification form. This process is only related to Microsoft Azure, and not applicable to any other Microsoft Cloud Service.”

In other words, there is no strict requirement to notify Microsoft when you perform a penetration test against your Azure resources. This means that you can perform many of the standard penetration tests against your Azure tenant, such as :

  • Tests on your endpoints to uncover the Open Web Application Security Project (OWASP) top 10 vulnerabilities
  • Fuzz testing of your endpoints
  • Port scanning of your endpoints

However, one type of test that you can’t perform is any kind of Denial of Service (DoS) attack. This includes initiating a DoS attack itself, or performing related tests that might determine, demonstrate or simulate any type of DoS attack.

Thanks, Captain Obvious……

It should be obvious, but just to be clear: DON’T use your Kali machine to attack anybody else’s stuff.

You would most definitely find yourself in a legal pickle if you decided to attack resources that didn’t belong to you (or one of your customers) without explicit permission in writing. Please, just don’t run the risk.

Practice using the 600+ tools available in the Kali Linux distro and learn how to better secure your environment!

Leverage the Microsoft Graph with Azure Active Directory Identity Protection to Identify Network Threats

What is Azure Active Directory Identity Protection?

Azure Active Directory Identity Protection is a feature built into the Azure AD Premium P2 license. The P2 SKU is important if you want to configure SharePoint Limited Access, CAS Proxy, or perform actions related to identity protection or control of privileged identities. The Azure AD Premium P2 (AADP P2) licensing is included with the Enterprise Mobility & Security E5 license, but can be added on to other licensing, such as the EM&S E3 license.

What’s great about it is that it also allows you to use the Microsoft Graph to query your Azure AD tenant and identify potential threats to your organization and even configure an automated response to them. This post will show you how to find these sorts of events in your organization, with a very simple script.

It only takes about 5 minutes to set up, so let’s get started!

What Do I Need to Do This?

For the steps below, I’m using a trial tenant with Office 365 E5 and EM&S E5 licensing (which as mentioned above, includes the Azure AD Premium P2 licensing). This means I don’t have a fully-functioning Azure tenant, where I can set up virtual machines, web apps, containers and so on – but I have enough to do the steps below.

First, I log in to my Office 365 tenant and go to the Admin Centers and click on my Azure Active Directory admin center. I can, of course, just go to http://portal.azure.com and log in there, but this just helps illustrate the connection between the Office 365 tenant and Azure AD.

 

Click on the Azure Active Directory icon and see all the properties of the Azure Active Directory instance that underpins my Office 365 and EM&S tenant.

 

I click on App registrations, as shown below:

 

 

Click on New application registration

 

 

 

 

 

 

Now I fill in the properties for the new application registration.

The values below will work as shown.

 

Click Create when finished.

Click on the Settings gear as shown below:

 

 

One of the settings is Required permissions .

Click on the arrow to expand this property.

Next, click on Add to set up permissions for connecting to the Graph API.

You have the option of selecting which API you want to grant access to.

Click on the Select an API arrow.

 

You’ll now see a bunch of API’s that you can connect to.

For our purposes, we’ll choose the Microsoft Graph, which contains security event information.

 

Click Select at the bottom of that pane.

Now click on Select permissions.

 

In the Enable access page, scroll down till you see the Read all identity risk event information line.

Click the checkbox next to that line and then click Done.

You should see the Windows Graph in your Required permissions page.

Click on Grant permissions to apply the permissions you just selected.

 

When you click on Grant permissions, you’ll be asked for confirmation, so click Yes if you agree.

 

Back in the Settings page of your Application, click on Keys.

 

Configure an access key as shown below and click Save.

 

You should see the access key value in the field below.

Copy this key and save it somewhere. You’ll use it in the script as the $ClientSecret variable.

 

Back on the Properties of the application itself, you will also see the Application ID value.

Copy this value somewhere as well. This will be used in the script as the $ClientID variable.

Use a PowerShell script to connect to Microsoft Graph and Look for Identity Risk Events

The script below can be used to query the Microsoft Graph for identity risk events. You’ll need to fill in the following values:

  • $ClientID
  • $ClientSecret
  • $tenantdomain

For my script, it looked like the screen capture below.

 

 

 

I deleted the application after running the script so these credentials aren’t valid anymore.

Shown below is the sample script for querying the Microsoft Graph to capture identity risk events.

$ClientID       = "Application ID value from the Registered App properties page "       # Should be a ~36 hex character string; insert your info here
$ClientSecret   = "Password value from the Keys page" # Should be a ~44 character string; insert your info here
$tenantdomain   = "Tenant name"   # For example, contoso.onmicrosoft.com

$loginURL       = "https://login.microsoft.com"
$resource       = "https://graph.microsoft.com"
$body      = @{grant_type="client_credentials";resource=$resource;client_id=$ClientID;client_secret=$ClientSecret}
$oauth     = Invoke-RestMethod -Method Post -Uri $loginURL/$tenantdomain/oauth2/token?api-version=1.0 -Body $body
Write-Output $oauth
if ($oauth.access_token -ne $null) {
   $headerParams = @{'Authorization'="$($oauth.token_type) $($oauth.access_token)"}
   $url = "https://graph.microsoft.com/beta/identityRiskEvents"
   Write-Output $url
   $myReport = (Invoke-WebRequest -UseBasicParsing -Headers $headerParams -Uri $url)
   foreach ($event in ($myReport.Content | ConvertFrom-Json).value) {
       Write-Output $event
   }
} else {
   Write-Host "ERROR: No Access Token"
}

 

Once you fill in the appropriate values for your environment, you can run the script in PowerShell and it will find any identity risk events associated with your tenant.

What Information Does It Provide?

In my tenant, it found one identity risk event, as shown below:



What this tells me is that on February 26, 2018 there was an AnonymousIPRiskEvent that took place using Allan DeYoung’s user account.

It looks like someone logged in with his credentials using a TOR browser, and it was classified as a medium risk event.

Additionally, I am able to see the location where this event took place and the IP address associated with it.

From there, I am able to start tracking down what happened and see if it poses any risk to my network or Allan’s account.

What other types of events would we be able to identify? Microsoft Graph contains identify events such as:

  • Impossible travel to atypical locations (Did you log in from New York and then 5 minutes later try to log in from an IP address in Indonesia?)
  • Sign-in events from unfamiliar locations (Is the location you are signing in from outside of your typical login patterns?)
  • Sign-ins from an infected device (Is the device where the login was attempted communicating with a botnet server?)
  • Sign-ins from IP addresses with suspicious activity (Maybe an IP address where a number of login attempts are taking place for lots of different accounts, which could indicate a brute force password attack)

We can categorize the risk events because the Microsoft Graph maintains information related to billions of login events each month. That means we can detect anomalies and determine whether they are just a user who forgot their password three times, or some sort of automated attack against that user’s account.

This is a very simple example, but you could configure something like this to run periodically and dump the events to a SIEM, allowing you to collect all your security related events in a single place and have them reviewed by your security team.

There are LOTS of other event types you can query on using the Microsoft Graph API (and the other application-specific API’s). I encourage anyone who manages the security for a network to take advantage of these API’s and create automated scripts that can capture risk events on your network.

Have fun with Microsoft Graph!

Applying the Basics of Blockchain to a Real-World Scenario

So there I was in my kitchen yesterday, reading an article in ZDNet about how several organizations are teaming up to prevent fraudulent food production practices around the world. The group has created a “Food Trust Framework” that is designed to increase the integrity and quality of the food in a global supply chain.

And there it was. Another reference to blockchain.

Until a few months ago, all of the references to blockchain that I had seen centered around the cryptocurrency Bitcoin, and to be perfectly honest, I figured if I‘m not being forced to pay somebody off to remove ransomware, Bitcoin and blockchain technology don’t really touch my life.

But there was blockchain again – this time in the context of food safety.

And since I eat food on occasion – well, that’s interesting to me. The premise of the news article is that there are an increasing number of food suppliers in China that are using ingredients in the food they sell that probably shouldn’t be there. As an example, maybe a beverage is diluted with water, or a filler is put into the food to reduce their cost of production. Maybe diluting a drink with water isn’t going to kill me, but it still means I’m paying for something that I don’t receive. But what if the filler that was used in a particular food happened to be a nut that I’m allergic to? Then it starts to get scary. (If you really want to scare yourself about “food fraud”, read this article)

Anyway, this group is trying to find a way to ensure that food quality is maintained through the supply chain. But how can you do that in a supply chain that could have dozens of suppliers involved in the process, particularly if some of the suppliers are specifically trying to avoid getting caught?

The answer they decided upon was – you guessed it – “blockchain”.

Blockchain Basics

The basics of blockchain are not terribly hard to understand, but let’s use a simple example to explain the principle.

We all understand the concept behind money. If I want to pay someone with money, I can hand them a dollar bill, or four quarters, or a hundred pennies or whatever, and the deal is done. The other person has the physical, tangible object in their hand, so we don’t necessarily need a third party to confirm that the money has been transferred.

However, let’s say I owe ten dollars to each of six different people, but I only have ten dollars in my bank account. Let’s also say that it’s possible for me to pay people by emailing them PICTURES of money. Being a little bit sneaky, I take a picture of a ten-dollar bill and email it to all six people. At this point, nobody can definitively claim the ten dollars in my bank account because there’s no proof that they are the ONLY one who has the picture of that ten-dollar bill.

But what if there was somebody that I had to email the picture of my money to FIRST and who could then hold me accountable for the money transfer? He would receive my email, make a note of the transaction in a ledger, deduct it from what he knows to be in my account and then pass along the picture to the recipient. If I tried to email another picture of the $10 bill to someone, the person with the ledger would say “Sorry, that money is already spoken for. You can’t do that.”.

Expand the scenario a bit and say that HUNDREDS of people have a copy of the exact same ledger, and everyone keeps the ledger updated in near real-time. Then, even if I tried to get one person to change their ledger to my benefit, others in the chain would say “Nope, this is the accurate set of figures”.

That’s the concept behind blockchain – a shared digital ledger that allows you to verify and validate the transactions contained in that ledger. The ledger is shared among many machines in a decentralized, distributed, encrypted network, so nobody has the ability to artificially manipulate the data because all the other machines in the network serve as an integrity check.

But remember – it doesn’t have to be about validating financial transactions. It can be used to validate just about any kind of record.

And that would include records that impact food safety.

Preventing Counterfeiting and Abuse

Let’s think about the application of blockchain to our original scenario.

Imagine for a moment that you are a dishonest supplier of orange juice. You have an order come in that requires you to provide 500 gallons of pure orange juice. But, being a bit of a crook, you reason that if you use half the number of oranges and instead supplement the mixture with 250 gallons of water, you could nearly double your profits!

So how would blockchain possibly prevent this fraud?

The first assumption must be that all the suppliers in the chain are being required to put their business records into the blockchain in order to be able to accurately track what is taking place.

Now, if blockchain is being used to track all the suppliers in the orange juice production process, it would show that you are only receiving half the needed number of oranges from your orange grower to produce 500 gallons of orange juice. There may be IoT (Internet of Things) sensors tracking water consumption in your plant and sending their records to the blockchain network, and these would show that you are using a lot of water in your production process, potentially indicating that you are watering down the orange juice. Shipping records would show that you are shipping twice as much product without twice the number of oranges being purchased. Perhaps there is a quality control test performed as your product leaves the plant that verifies the makeup of the orange juice and then another test performed when it reaches the next stage in the supply chain, all of which are recorded in blockchain. The blockchain allows the end user (in this case, that might be the grocery store who buys the orange juice, and who has access to all the records in the blockchain) to watch for anomalies in the production process that would indicate fraudulent production processes.

If you attempt to go back and falsify your records, what happens? Let’s say you try to claim you used twice the number of oranges that you actually used. Well, you have an orange supplier whose records are also being stored in the blockchain, and his records show that he only delivered half the number of oranges that your records indicate. The trucking company that delivered the oranges would have a record of the weight of the oranges that were delivered, and that would also be stored in the blockchain, again making your claim suspect. Your records would possibly indicate orders for twice as many orange juice cartons – and unless you have a lot of unused cartons in the plant, that would be hard to explain. When you ship your product, the next stop in the process may perform a quality check. If that quality check indicates that the orange juice is 50% water, they are going to ask questions because now THEIR reputation is at stake.

At each stage of the process, any attempt to manipulate the data will be blocked because the entire set of blockchain participants (who may not even be known to you, and with whom you therefore cannot collude to falsify the records) will be validating that your records match the set of records that they have. The grocery store at the end of the supply chain can backtrack through the entire process and identify where the orange juice is being watered down.

The orange juice supply is saved! (And you potentially go to jail)

Conclusion

What this has taught me is that blockchain has some pretty interesting use cases. There are a number of industries that are already investigating blockchain scenarios very heavily. For example, the healthcare industry is investigating its use in tracking patient records and payment history; the financial services industry is using it to verify and validate financial transactions; and the energy industry is using it to protect themselves against intra-day price fluctuations in energy resources such as solar and wind-generated energy.

Microsoft Azure allows customers to set up blockchain solutions themselves to support their business initiatives. Some of the blockchain and distributed ledger protocols currently available are Ethereum, HyperLedger Fabric, R3 Corda, Quorum, Chain Core and BlockApps, as well as Azure Blockchain Service. These can be used to help customers provision their own blockchain network in just a few minutes in a globally distributed, highly-available network, using Azure’s massively scalable compute, storage and network infrastructure as the foundation.

Investigate blockchain at the link below and try it out for yourself!

https://azure.microsoft.com/en-us/solutions/blockchain/

Announcing Microsoft’s Coco Framework for enterprise blockchain networks

 

When You Just Gotta Have a Lab

I spend a lot of time working with partners and customers setting up and performing demos of new products.

In many cases, we are looking at features that are purely cloud-based – such as Skype for Business Cloud PBX or PSTN Conferencing. When that’s the case, I just go to the Office365 tenant that I have set up for my own testing and show everyone where things are configured or what features are available.

Every so often, though, I get asked to set up a demo using a somewhat more complex type of environment involving a set of virtual machines or some other cloud product like EMS.

I used to manually set up the lab virtual machines on my laptop, but I found a great new resource that lets me build the environment in Azure using a documented and scripted process.

It’s called the Cloud Adoption Test Lab Guides and they are located here: https://technet.microsoft.com/library/dn635308.aspx#O365

For example, if I needed to demonstrate how a highly-available SharePoint 2016 farm would be configured, I could use the guide found here, and it would walk me through building an Azure environment that looks like this:

There are a couple advantages to this approach:

  1. It frees up my laptop resources (VM’s tend to be storage hogs and I have a limited amount of CPU and RAM available for building out scenarios),
  2. I can access it from anywhere since the machines are in the Azure Cloud, and
  3. It gives me the chance to get more hands-on experience with Azure.

It’s a great option for those scenarios where you need to build a testing environment or as a way of demonstrating a product for customers.

The great thing is, you can build it in your own Azure environment so you always have a demo environment ready to go, or you can choose to build it in your customer’s Azure environment as a leave-behind for them to play with at their leisure. That also gives you the opportunity to talk to them about moving their existing on-premises workloads to Azure, or using Azure as a backup/recovery location, setting up test/dev environments in Azure and lots of other stuff.

The team that’s responsible for creating the Cloud Adoption Test Lab Guides is constantly creating new scenarios, so check back frequently to see which new scenarios they’ve created!