infoguard-cyber-security-blog-it-security-architecture-digest-2022

The 2022 IT Security Architecture Digest

What has been keeping us at InfoGuard and our customers busy in terms of IT security architecture over the past year? Just as we did in the first Architecture Digest, we have looked back at the year gone by and tried to identify emerging trends – possibly those affecting your company too. Architecture-related issues are constantly evolving, so the InfoGuard architecture team has been given the opportunity to work on not just new, but also old issues with a renewed focus. In this blog post, you can find out which ones these are.

Cloud Implementation

In 2022, we increasingly had the opportunity to check the cloud architecture of projects on the basis of reviews: The decision in favour of the cloud has been taken - now it is time to populate the cloud with IT life.

Regulatory requirements are important. These can also be complied with in the cloud, with hybrid (on premises and cloud) set-ups often being seen. Some things that are useful for meeting the regulatory requirements in the cloud are:

    • Cloud providers' moves to offer regionally based cloud stacks

    • Options for key generation and management

    • Pre-defined parameters for compliance testing

    • Manufacturers’ reference architectures

    • Specific documentation on compliance issues

    • Within compliance bodies, experience of cloud compliance is growing

The earlier specific expertise is brought in then the less adjustment is required later on. The right time to get a second opinion is:

    • At the start of a project, to define the requirements for security 

    • During the design phase based on workshops to discuss what solutions are under consideration (we find that this way of doing things is particularly useful)

    • Document review for each phase of the project

In our view, it seems important to bring in specific expertise early on in the project. As the old project saying goes: it is easier to change the plan than the end result.

Zero Trust

Zero Trust product maturity is improving. This is good news. The questions around Zero Trust involve:

    • Isolated Zero Trust solution or Zero Trust solution with broker component in the cloud

    • The order in which components are implemented

    • “Make or Buy”

    • Micro-segmentation

Companies, and of course our customers, all have different set-ups. A ready-made solution may be ideal for one customer, whereas another company might find it too restrictive. This is where it is important to clarify and weigh up the needs. It is worthwhile to find the right set-up that suits the company.

Integration with other products can be a challenge. An example of this was the integration of remote access into an evolved environment, taking into account Zero Trust. Indeed, not all Zero Trust is the same. Not everything that calls itself Zero Trust actually has Zero Trust – as required by a specific customer environment – within it.

Internet of Things (IoT) and OT

Increasingly, we have been asked how to protect an existing IoT (Internet of Things) or SCADA (Supervisory Control and Data Acquisition) environment more effectively. This is a challenging undertaking, for the following reasons:

    • There is a whole host of (old, insecure) communication protocols between OT components and networks

    • IoT devices are placed in exposed locations

    • Secure remote maintenance is a challenge in IoT and SCADA environments

The way in which the protection is designed depends on the system's criticality and how exposed it is. The effort required to protect IoT and SCADA rises disproportionately with increasing protection requirements. However, substantial improvements can often be achieved using relatively simple measures.

For those environments with the highest safety requirements, strict separation is needed, if necessary by means of data diodes. However, this results in limitations in functionality. The challenge is to find a solution that ensures both the security requirements and functionality.

Another aspect of IoT relates to trust. When you are the customer of a manufacturer of a device, you need to be sure that your device, for example. a heating system, is communicating with the manufacturer’s servers and is only getting an update from them or uploading telemetry data to them. To do this, a public key infrastructure (PKI) and sophisticated manufacturing processes are needed. There are facets of IoT that are always surprising for us too.

Furthermore, it has been demonstrated in our projects that IoT environments have a tendency to become confusing. The causes of this include the wide range of IoT devices and their limited functionality and geographical distribution. Good network segmentation and documentation with defined rules for where IoT devices are placed in the network can help to maintain a permanent overview.

Zone Concepts

We assumed that the good old zone concepts would have a harder time with the advance of cloud and Zero Trust, but we were proven wrong:

    • Zero Trust and micro-segmentation require there to be a clear idea of what should be in the micro-segments.

    • In cloud environments, the question arises of how existing networks can be integrated into the cloud. I have already written a blog article on this subject about connecting IaaS and SaaS.

The cloud network security architectures also affect zoning and can be technically implemented in a different way in the cloud:

    • Zone boundaries are defined with the subscriptions 

    • Zone boundaries are cross-subscription

    • Technical implementation of zones in the cloud, etc.

Zone concepts have not become obsolete in the cloud environment. Rather, there are supplementary questions that arise, like the connection of the cloud and the demarcation of zones within the cloud environment.

High-level security architecture

For the architecture team, the highlight was the defining of strategic high-level security architectures and the ensuing fascinating discussions with the customers’ specialist disciplines.

An architecture requires coordination, and it cannot be imposed. Holding intensive discussion with the stakeholders means they are able to contribute about what their requirements of the security architecture are. This ensures that the target architecture is useful and that it receives the stakeholders’ backing. The last factor is a critical aspect for success.

Security architecture from InfoGuard, the cyber security experts – for a stable, secure company

My colleagues in the architecture team and myself always get our inspiration from dealing with the wide-ranging tasks and client needs. The option of working with clients at different levels and, where necessary, remotely, has become the norm. 

If this has whetted your appetite for taking on an exciting, challenging architecture project with us, then get in touch! We look forward to hearing from you. 

Contact us now!

<< >>

Network Security , IT Security , Cloud Security , Architecture

Markus Pfister
About the author / Markus Pfister

InfoGuard AG - Markus Pfister, Senior Cyber Security Consultant

More articles from Markus Pfister


Related articles
Architecture Digest 2021 – Particular concerns of our InfoGuard clients
Architecture Digest 2021 – Particular concerns of our InfoGuard clients

There are probably many of you who are taking a look back at the working year when the New Year is gently [...]
Zero Trust – take care in whom you trust
Zero Trust – take care in whom you trust

This probably sounds very familiar to you – dashing from your home office to meet the client, then on to a [...]
The way to the cloud is paved with a few pitfalls [Part 1]
The way to the cloud is paved with a few pitfalls [Part 1]

Clouds – or rather cloud-based IT services of infrastructures (IaaS), platforms (PaaS) and software (SaaS) – [...]

Exciting articles, the latest news and tips & tricks from our experts on all aspects of Cyber Security & Defence.

Blog update subscription
Social Media
infoguard-cyber-security-guide-2