Practical Protection: Do You Need a Cybersecurity Reference Architecture? 

You can think of enterprise software customers as existing along a continuum. The endpoints of that continuum can be labeled in all sorts of ways. One example: one endpoint might represent the type of company that wants to build and design their network and computing resources 100% in-house. The other endpoint represents companies that want to use as much outside knowledge and assistance as possible, looking at what other similar organizations have done and (in the best case) adapting it, or (worst case) blindly copying it. It’s also true that some things are complicated enough that having a trusted source give you an example can save you a lot of trouble and hassle. For example, Texas Instruments publishes reference designs for various types of PC based on their chipsets. 

What is Reference Architecture? 

The demand for packaged guidance has led to the rise of reference architectures. You’re probably familiar with some of these, even if you’re not familiar with the term because they are often introduced with a label such as “best practices design” or “design recommendations.” One example: for years the on-prem Exchange world was able to draw guidance from the Exchange preferred architecture, which represented the product group’s guidance for how to build a reliable, manageable, and performant Exchange on-prem deployment at large scales. 

In the security world, many organizations have security systems that have been incrementally deployed. This is the “coral reef” school of security design: every individual coral in the reef is doing its best locally, and the design roughly follows a desirable pattern, but there are lots of gaps and holes caused by incremental deployment and lack of coordination. With that in mind, it might be useful to have a canned set of reference architectures when designing an organization’s security implementation. And, voilà, now Microsoft has done just that by releasing an updated version of the Microsoft Cybersecurity Reference Architecture (MCRA). 

What’s in the Microsoft Cybersecurity Reference Architecture?  

Microsoft says that the MCRA diagrams “describe how Microsoft security capabilities integrate with Microsoft platforms and third-party platforms.” These platforms include Microsoft Azure, Microsoft 365, ServiceNow, Salesforce, and Amazon Web Services. Over the last two years, MCRA has evolved, in part because security threats have changed and in part because Microsoft now sells many more (and more sophisticated) security tools.  

The MCRA itself is a combination of two primary items. One is a 95-slide PowerPoint deck; the other is a series of 18 YouTube videos where Microsoft engineers present the material in the deck. The content is oriented around four purposes: 

• You can use it as the baseline template for your own security architecture. 
• It is usable as a set of recommendations that you can use to compare against your existing set of security tools. 
• You can use it to learn about what Microsoft’s security tools can do, including how Microsoft’s various solutions integrate with third-party systems 
• You can use it as a general-purpose cybersecurity reference and learning tool 

The deck itself is extremely dense; every slide has lots of text, there are extensive speaker notes, and most slides use animation to help emphasize key points. The YouTube videos will be more approachable for many of us, because cycling through the deck and reading the speaker notes isn’t a great user experience compared to reading a linear document. 

But what does the MCRA actually include? Excellent question. You can think of the MCRA as a sample implementation of many aspects of the Security Adoption Framework (SAF) that Microsoft designed. The SAF tells you what you should do, and why; the MCRA tells you how to meet the requirements the SAF outlines. For example, the SAF says (basically) “zero trust is awesome and you should use it”, then the MCRA tells you what key zero trust principles are most important and then drops the slide below on you to drive the point home. 

This slide looks horribly complex until you understand its purpose. It’s meant to show the mapping between the components of a zero trust implementation (e.g. “threat intelligence” or “access control”) and Microsoft products that deliver the functionality required for those components. There are similar triplets of slides (concepts, components, and implementation mapping) for a number of other aspects of cybersecurity. 

How to use the Microsoft Cybersecurity Reference Architecture 

As a learning tool, I really like MCRA, but it’s a tough hill to climb. Most people will prefer to watch the YouTube videos instead of trying to crunch through the slides. However you put in the effort, though, the MCRA contents will help inform you of what Microsoft’s security solutions offer and how you can put them to use. 

Beyond that, the MCRA is useful as a benchmarking tool, but it’s going to require some focused effort on your part first. Vendors often act like their solutions are the security equivalent of Cajun seasoning: just sprinkle a little on top of whatever you’re cooking and it will magically taste better, with no skill or effort involved. This is of course completely untrue (for security products, not Tony’s). MCRA isn’t magical. To get good value out of it as a reference architecture, you need to have a thorough understanding of your existing as-built architecture first. The MCRA can help you by showing you what set of capabilities Microsoft recommends; from that you can assess where your own systems have gaps. The early slide on anti-patterns alone is good enough guidance that I should probably write a column focused on it—and overall MCRA is full of other similarly valuable gems. Since MCRA costs you nothing, it’s well worth a good look and some thoughtful pondering of how it might be applicable in your own network.