3 simple (but important) steps to enterprise IT security architecture

In one of the previous articles, we discussed why it makes sense to create an enterprise IT security architecture. Do you remember? If not ‒ click here for the relevant article. If you are also convinced that security architecture in your company would be an advantage, read on. We will show you how to attain effective architecture.

Of course, there are already many frameworks and even more literature on this topic. But sometimes the pragmatic approach yields results that are just as good and that can be very useful. We would like to introduce you to an approach like this, one that we also use in customer projects. In our experience, time and again, enterprise IT architecture is missing or not fully defined. In this case, there are various "entry points" for starting to make a record the actual status.

1. Analyzing the actual status of your IT architecture

The first step involves examining interrelationships in order to progressively obtain a complete overview of the existing IT landscape. This way, the relationships and data flow between the IT systems are recorded right from the business processes. This provides important information about the IT systems involved and the data that is exchanged. In the second step, the stakeholders' requirements are recorded. These result in creating systems that can fulfill these requirements ‒ or indicate a possible "gap". If the corresponding requirement is relevant to the business, this gap should be closed by the new architecture. Finally, proven reference architecture should be transferred to a particular company. This reference can be used to map your own IT landscape ("mapping"). Our InfoGuard Enterprise IT security reference architecture looks like this:

The following questions and sources of information can be helpful when analyzing your current situation:

2. Making IT architecture concrete ‒ going from the rough to the detailed

Once the actual status has been determined, the IT security architecture must be taken back "to basics". Not everything has to be completely clarified and documented from the very beginning. From our experience, this is a claim that often causes projects like these to fail. That’s why we recommend that you develop documents that become more and more detailed over time. However, it is important for architectural documents to be officially put into effect by the company and for it to be declared compulsory. We explain below how to implement the architecture.

Below is a list of the tasks for detailing the architecture with corresponding examples and the level of knowledge required:

A tool can be helpful in developing the enterprise IT architecture

A wide range of tools are available for developing the architecture. We believe that these are particularly advisable where many relationships have to be modeled. They help to record and collect meta-information (applications, systems, connections, processes, etc.) as well as to process the information in a consistent way. However, not every company needs a tool! For smaller companies, it could even be a tool from the existing Office environment or other presentation tools.

3. Implementing enterprise IT architecture within the company

Enforcing IT security architecture is first and foremost a governance issue. It requires that the IT architects involved take a cautious approach, to avoid being labeled the ‘"architecture cops’". And there will always be "good" reasons why, in one specific case, it is impossible to comply with the architecture's specifications... This is why a tried and trusted approach is needed to set the obstacles to sidestepping them as high as possible ‒ but not to prohibit them per se. The following approaches have proven themselves in practice:

• A clearly defined fleet and service policy. If any deviation occurs, the price tag will be correspondingly high.
• Specifying processes to ensure that only components on the white list are to be used. Exceptions must go through the (lengthy) exceptions procedure.
• Authorization process for firewall rules. This is a lever for controlling interventions that is often underestimated.

Two committees should be set up to approve and review project results: a Service Review Board, with a membership made up equally of IT architects, domain architects, project representatives and user representatives is appropriate for reviewing services and their interface, and a Project Review Board is ideal for the acceptance of phase results and for checking IT architecture conformity. This body should have sufficient authority to halt projects or impose conditions if the results do not meet the desired targets.

Your IT architecture needs to live and breathe

Both enterprise IT architecture and hence enterprise IT security architecture processes. When implemented correctly, the company can use its resources efficiently and effectively, openly discuss emerging conflicts of objectives and improve the quality of IT services. So good IT architecture management is methodical in character and as a result, has authority over the projects. This means, for example, that defined delivery objects such as the functional specification of a project or an interface specification are checked and released by the IT architecture departments in the context of project development. Changes to components require attention ‒ and the discipline to update architectural documents. Here, too, we have practical experience of how this can be achieved within the change management framework: Changes should only be approved with updated documentation! The more applicants need the change, the more successful this approach will be.

A defined architecture will only survive in the long term if it is lived. The same guidelines apply to the communication of IT architecture content as to any other technical content that needs to be communicated internally. An important role is played by preparing the architecture guidelines and specifications in line with the target audience, by making them available to all employees in a web portal, for example.

Communication tailored to target groups and recipients is a key factor for well-accepted and positively rooted IT architecture management. Don't forget this point with your enterprise IT architecture, otherwise all the good work could soon be forgotten and become obsolete.

Enterprise IT security architecture from InfoGuard

As you see, enterprise IT architecture is not magic, but it does have to be done. In our experience, this is exactly where the problem lies. New business requirements have to be dealt with rapidly. And how quickly can new services be used without first integrating them into the architecture...? Is this a familiar problem for you? This is why we assist our customers in planning and implementing structured and coordinated activities that ensure IT security in the enterprise architecture, in order to ensure continuity when changes occur.

Sounds interesting? Then you can find more information about our enterprise IT security architecture services on our website.

Your "home medicine cabinet" for common diseases in IT security architecture

We have repeatedly observed that companies have the same "clinical symptoms" in terms of IT security architecture. That’s why we have put together a "medicine cabinet" with the right medication acting as "emergency medicine" to treat common diseases. Act like a GP and prescribe the medication your patients need. However, before you can do this, you need to make a thorough assessment and consider any potential complications.

In an almost fun way, you learn how to continue to optimize your company's security. With just a click of the mouse, you can access information about possible solutions and services that can help you to implement your enterprise IT security architecture. Download now our free "medicine cabinet" whitepaper (in german).