Implementation of the network zone concept in practice
Many companies and organizations are in the process of dividing their network into different zones.
In the simplest case, the servers are separated from the clients or extremely extensive zone concepts are created. Essentially, it is always a matter of grouping systems with the same purpose and the same protection requirements into network zones. To ensure that a zone concept can be implemented successfully, a number of points must be taken into account when it is created.
Already when drawing up the zoning concept, there should not be the claim to want to cover 100% of the cases that occur in practice. An exception process is always necessary and there must be an idea of what must be and what can be handled by means of exceptions. As few zones as possible should be implemented, which can be subdivided into further subzones. The requirements for new, additional zones should be clear and correspondingly high.
Since network zoning is a demanding project with highly diverse requirements, it is important that the client is authorized to issue instructions to all parties involved and that there are guidelines from the business as to what is to be protected in the first place. It is extremely helpful if a classification of data exists in a company so that it is known what needs to be protected.
There are completely different, incompatible requirements at the level of security, IT architecture, engineering and operation. For example, it must be as secure as possible for security, as clearly and consistently structured as possible for IT architecture and engineering, and as simple as possible for operation and also easy to handle.
At the beginning of such a project, it is important to define the terms so that all participants understand the same term. For example, the term network zone does not mean the same thing for all participants from the outset.
Implementation of the zoning concept
The implementation of a network zone concept consists of the conception phase, the construction of the security elements to map the zones and the migration of the applications, respectively their infrastructure into the different network zones.
In order to provide the security elements between the network zones, it would be important to know which communication connections are required by the applications. To obtain this information, it is important that the application owners are known and that they know the communication requirements of their applications. However, it is not realistic to assume that this will always be the case. There are different ways to deal with this issue. One commonly used approach is to map the known communication links onto the security elements and include a "forward any" rule at the end of the rule set. This is done with the aim of replacing the "forward any" rule with specific rules after migrating an application and only migrating the next application when this rule is no longer required.
A migration team must be able to cover all aspects of such a migration. Depending on the migration procedure, security and network engineers, application operators and testers, and also suppliers of the application are necessary to carry out a migration successfully. The migration manager creates the script and moderates the migration. The script also always contains a fallback scenario in order to be able to go back to the status before the migration in case of insurmountable problems.
As part of the migration, an application must then be tested for its function. Since such migrations are usually carried out outside office hours, only the function can be tested as part of the migration, but not the behavior under production conditions.
In order not to be responsible for incidents of a migrated application forever after a migration as a migration team, it is necessary to agree with the company when an application should be handled again according to the standard incident process.