Monitoring Architectural Risk

Learn how to monitor architectural risk in this article by Neil Rerup, the person responsible for the security architecture for the Vancouver 2010 Winter Olympics and Milad Aslaner, a mission-focused security professional and an award-winning speaker and technical expert at global conferences, such as Microsoft Ignite, Microsoft Tech Summit, and Microsoft Build.

There are different types of threats posing a risk to the organization. However, as an architect you need to focus on security. There are architectural risks that have to be thought about and provided as an input into the strategy.

What are architecture risks?

Architecture risks are those risks that arise as a result of the architecture components that are in your organization. You can have different types of solutions that provide the same security posture but have different architecture risks and those are things that have to be considered.

Take, for example, the ever-present legacy infrastructure. The infrastructure that everyone wishes would just go away but you can’t get rid of because of the dependencies. Every organization has a legacy Windows NT Server still sitting around simply because there’s an application that can only run on Windows NT and there is a business requirement to keep that application. Having the Windows NT server in your environment will create an architectural risk because of the lack of support from Microsoft.

Legacy systems are the biggest source of architecture risk that you have to consider. You can understand this with the help of an anti-virus (AV) example as a way of talking about architecture risk. When you look at your current AV solution, you have to look at both the capabilities of the AV package as well as the infrastructure that it is residing on. Maybe, in your analysis, the AV package is able to support the needs of the business for another three years. However, the operating system that it is residing on will reach the end of life in one year. Now you have to put into your security architecture strategy a change to the AV because the infrastructure supporting the AV has to be changed.

When you are working with your security architecture strategies, look at the different components and the dependencies of those components. Look at the age and capabilities of those components and then map the architecture risks associated with those components. Do this using a table of sort, such as the one shown in the following example:

In this example, there are three sample projects but, more importantly, there are five options for laying out how to deal with your architecture risks by planning longer term. Those five options are as follows:

• Investigate: The investigate option is all about looking into the current solution, the requirements that a solution is supposed to meet, and then determining if there are options out there that might be better than the current solution. In this option, you want to be looking into all the possible solutions, including sticking with the current solution.
• Select: The select option is about deciding about which solution to use and how to use it. You’ll be comparing the pros and cons of each possible solution and, if you do this properly, you’ll make use of your Key Decision Document(KDD) for describing your final decision in regards to your long-term strategy on reducing architecture risk.
• Deploy: The deploy option is the timeframe that you need for rolling out a new option and it’s never as easy as you expect. Remember that the preceding table also describes the timeframes for the activities, so don’t discount how long it will take to deploy a new solution. There will be all sorts of gotchas that come up and you need to plan for it.

One of the mistakes that commonly occurs with architects is that they assume that the amount of time to deploy a solution is similar to how long it would take them to deploy a solution. But there’s a reason why architects are more senior to other roles—they’ve been through the trenches and learned the lessons to dealing with solutions. The people that will actually do the deployment will be more junior to you so really build in a buffer for time to deploy new solutions.

• Operate/sustain: Once the solution has been deployed, it will sit in production for a long time, likely several years. This will be the longest timeframe associated with the strategy timetables and it’s easy to forget about solutions during this period. This is why your asset inventory is so important and what you use in your planning (so that you don’t forget about solutions once they’ve been put into production).

Keep an eye on the solution and touch-base with the operations group to determine how it’s doing. Is it continuing to meet its original requirements? Are changes to other environmental component impacting the solution itself to the point where the solution may need to be upgraded? Remember, technologies change, and the direction of organizations change as well. This may impact the functionality of a perfectly good solution in a way that may require changing directions.

• Retire: Here’s where you want to actually retire the older solutions. Many times, you’ll want to maintain the old solution in parallel with the new solution, just in case something happens. But then you want to retire the old solution and that isn’t as easy as just pulling the plug. There will be tools that have to removed, IP addresses released, VLANs changed, and so on. All these can impact an organization if not done correctly and that also raises the architectural risk.

Align your retirement option with when your current solutions are going end of life. Ideally, you replace the current solution a year before it reaches its end of life so that you don’t have to deal with a raised architectural risk.

One other thing to remember about retirement of solutions—you don’t necessarily have to be bound to them when they reach the end of life. Sometimes, if you talk to the vendor, you may be able to pay a premium to continue getting support from them even after products reach the end of life. Vendors may be ending support simply because they have a new product that they want to be pushing, but they seldom will turn down money.

Another option for a solution that has reached its end of life is to find support from unauthorized sources. For example, a piece of infrastructure has reached its end of life and is no long supported by the vendor. You’ve talked to them and they don’t want to continue providing support even after end of support. Maybe there’s someone in the marketplace that has deep expertise of the product that would be willing to support the product. Support doesn’t necessarily have to come from the vendor itself. And this will help your operations teams as they are trying to support the product inhouse.

If you found this article interesting, you can explore Neil Rerup and Milad Aslaner’s Hands-On Cybersecurity for Architects to architect solutions with robust security components for your infrastructure. This book will help you to successfully design, integrate, and implement complex security structures in any solution whilst ensuring that the solution functions as expected.