UBC Successfully Migrates Windows and SQL Servers to Azure

Industry:  Trade Union

The United Brotherhood of Carpenters is one of North America’s largest building trade unions, with over a half-million members. The union leads the way in training, educating and representing the next generation of skilled construction professionals.

Business Problem

  • Development of Cloud migration plan to Azure.
  • Meet security and regulatory compliance requirements for migrating core legacy applications, including Personify running on Windows Server and SQL Server.
  • Provide ongoing Azure optimization and management.


  • Lightstream Cloud Foundation Framework Workshop and guided Foundation Build aligned with Cloud Adoption Framework (CAF).
  • POC stand up, Security Planning and Design, Network Architecture and Design, App Validation, Automation and Implementation.
  • Lightstream Cloud Managed Services for ongoing Azure management and optimization of financial, technical, security and operational aspects of environment.

Business Outcomes:

  • Successful workloads migration to Azure.
  • Compliant governance and security posture for workload environment enabling UBC to safely deploy applications via Infrastructure-as-Code.
  • Ongoing management and optimization including 65% cost savings through RI management and successful networking providing full direct interoperability between on-premise resources, Azure resources via ExpressRoute and AWS resources via Direct Connect.

The Red Herrings of Cybersecurity – Blog 2 of 4

Hello again.

In the previous blog in this series, I set things up for you. I explained the three things that I believe are “red herrings” in our industry – and now we’re going to dive into the first. Let’s go for a short, pointed, and honest ride.

There has been a consistency about managed services providers in the years I’ve worked for them. While not particularly comforting, the consistency of failings at least meant that we were all doing it wrong together. There is cold comfort in that.

One of those things that killed me for years is the speed of implementation. Or should I say, the complete lack thereof? In my years with HP, one of the managed services accounts that I worked with directly was grumpy because it had taken over 9 months to get an IDS successfully implemented. Yes, you read that right. Nine months. It’s not like security is a real-time battle of good and evil, and losing seconds is cause for concern, right?

I swore that I’d work to improve this, but ultimately I was unsuccessful. Then I left the company. But this stayed in my mind for a while. In my next role, I was too far removed from this situation to be able to affect it. That said, it never left my mind as my team and I advised CISOs on strategy and program development. The goal was always to decrease the time that elapsed between signing a contract and getting “security value.”

Fast-forward a bit to when I joined my previous role at Armor. The company was touting “2 minutes to deploy” and given my previous experience I thought I hit the jackpot. I’d learn over the next two years why I had been chasing a false dream. I’d recognize that faster is not necessarily better, although rapid time to value is desirable.

So what changed that swayed my thinking? Experience.

You see, I had the opportunity to witness a few “2-minute” deployments. They were categorically a disaster. Why? The answer lies in another question.

“How much protection can you expect from a security tool that does near-zero customization?”

If you answered the above with “about that, near-zero” you are now in my headspace. One of the reasons; and this is personal opinion now, there were so many install failures and missed issues downstream was that we were going for speed versus security. Sure we had it installed in two minutes. But did it serve any value? That was debatable, at best.

The lesson is this – to provide a valuable outcome to your customers, you need to do the work. There is a multi-step process that needs to be followed that I’ll readily share with you, here.

1. Understand your customer, their environment, and their challenges. Without this, you’re applying peanut butter. There are no two customers that share the same strategy, architecture, network topology, and security response needs. This I can guarantee. So why would you pretend that a single stock configuration would do anything but provide for the most basic of controls? I would argue that without this step you’ll be doing more harm than good.

2. Prototype and test your configurations. Once you think you know your customer, develop the defensive model, policies, and response actions. Work hard to identify not just the 80% case but those 20% outliers that are going to cause trouble once you deploy. Here’s a hint – one of the most difficult things to get right is the disruptive cases. The situations where something happens to upset the customer’s ecosystem due to a configuration you’ve made are irreversible – especially during initial deployment. If you can’t get it right from the start, you’ll lose your customer’s trust before you ever get to protect them. Minimize your unknowns; that’s the best advice I can give.

3. Expertly guided deployment is essential. Far too many times I heard customers say, “We got this” and then proceed to bungle everything because of either ego or something else. But I promise if your provider is offering you assistance to deploy – take it. If they’re not, ask why they’re not helping you be successful.

Expect this effort to take you north of forty hours for a mid-size implementation. That’s my estimation. You, the provider, should spend a week of solid work to get to a deployment stage. That’s a far cry from 2 minutes but provides infinitely more security value.

While I still believe that deploying as quickly as possible to get security value is critical, I no longer believe that doing so at the expense of customization and testing is viable. Everything comes at a price, and in cybersecurity, the price for protection is time. And effort. It takes effort, planning, patience, and expertise on your part and your customers. I don’t care how you present it – those are things you can’t rush.

Next up, removing complexity. I welcome your comments in the meantime.

The Red Herrings of Cybersecurity Blog Series – Blog 1 of 4

The longer you’re in the cybersecurity business, the more you realize that some of the things you learned early on as ground truths were red herrings. Allow me to elaborate.

As the head of security strategy here at Lightstream, my job is to innovate and think ahead of the demand curve. I take this job very seriously, which is why I’ve been re-evaluating some of the things I held true in previous roles. There are three things I want to address over the next four posts, and I hope this reveals a little about how I’m thinking and perhaps provides some groundwork for good dialogue.

First, the three red herrings I want to discuss. These apply specifically to the delivery of security services in the form of an MSSP – and while these three things may be applicable elsewhere, that’s not what I’m addressing in this series.

  1. Faster deployments are somehow better;
  2. Complex services are more effective;
  3. Vendors taking over your tools is a good idea.

Let me break these three things down so you can get a sense of the high level here, and then over the next few posts, I’ll share my thoughts and how I have arrived there.

At my last company, there was a very odd metric we put on all of our marketing literature – the time to deploy our product. It made sense at the time. We told customers we could get the product installed in about 2 minutes and that as soon as they signed up for our service, they’d be off and going in that short timeframe. That all sounded good until I observed a few of these deployments. Have you ever tried to install a security product in 2 minutes? If you have, then you will probably agree with me that the only thing you get in those 2 minutes is a stock vanilla deployment with virtually no contextual understanding or customization. To translate that into an outcome – low value, and a potential disaster by breaking something.

Complexity has always been the archenemy of everything in technology. The more complex a deployment becomes, the more difficult it is to understand it. Hence it will be difficult to fix and secure. I don’t believe this is disputable. So why is it that so many security services vendors build slide after slide in their presentation to explain their overly complex systems and processes? The answer is simple – the buyer has come to believe that if they don’t understand it, then it must be advanced. It’s like the Arthur C. Clarke quote: “Any sufficiently advanced technology is indistinguishable from magic.” My friends, don’t buy magic; it’s rarely real in the end.

Finally, let’s talk about those RFPs you’re sending out. If you’ve purchased a set of tools and failed to implement them properly – whether you figure this out on day three or three hundred is immaterial – asking someone else to take your operation over is a terrible idea. The likely outcome is what we in the industry refer to as: “your mess, for less.” I promise you there is no value here. You get what you pay for, and “cheap” is not the same thing as “less expensive.” There’s a lot to unpack here. I’ll save my thoughts for the full post; however, I wanted to seed this in your mind for now.

So now you have it – my thoughts on the three most important red herrings cybersecurity services vendors put forth that I believe you should avoid. In the next three blog posts, I’ll unpack each and perhaps leave you with something to think over. A better way forward, perhaps.