Wichtige Info

Die Inhalte, die du hier siehst stelle ich dir ohne Werbeanzeigen und ohne Tracking deiner Daten zur Verfügung. Trotzdem muss ich die Server bezahlen sowie Zeit in Recherche, Umsetzung sowie Mail Support stecken.
Um dies leisten zu können, verlinke ich in einigen Artikeln auf die Plattform Amazon. Alle diese Links nennen sich Afiliate Links. Wenn du dir mit diesem Link etwas kaufst, dann erhalte ich eine kleine Provision. Dies ändert jedoch NICHT den Preis, den du bezahlst!
Falls du mich also unterstützen möchtest, kannst du auf den Link zum Produkt klicken und hilfst mir dabei, dieses Hobby weiter zu betreiben.
Da ich Keine Werbung schalte und keine Spenden sammle, ist dies die einzige Möglichkeit, meine Systeme und mich zu finanzieren. Ich hoffe du kannst das verstehen :)


ISMS in everyday life - operating concept on the example Windows 11


ISMS - An operating concept for Windows 11 clients

Introduction

My job often leads me to slip into roles that were unknown to me before, and to think about things that you rarely have in mind. In times of operating system change, from Windows 10 to Windows 11, larger companies, possibly with their own ISMS, have the subject of the operating concept – i.e. how to operate a system in a way that meets all regulators, whether externally or internally. At the moment, I would like to help set up such an operating concept. This article is intended to show some of my thoughts and, in the best case, provide a kind of blueprint for an operating concept.

As always: No guarantee of completeness or accuracy...

Main part

As a bloody beginner, it is my concern that other newcomers can also benefit from this post. Therefore, I would like to start at the beginning and define some basic principles.

What is a documentation?

First, it should be clear what a documentation is. In my everyday life I have already noticed that there can be great differences in the definition. That is why I believe that what a documentation should be.

A documentation is a systematic collection of information that describes processes, systems or products in detail in order to facilitate the understanding and use of users or developers. Good documentation is characterized by clarity, completeness and easy accessibility, so that readers can quickly find and understand the information they are looking for. In addition (and this is with the most important) it is always up to date by reviewing it regularly and adapting it to changes or new requirements.

Documentation should therefore give users (even new users) the opportunity to use a new system quickly and informing them. The quality question of a documentation is: “Can an unparticipated third party use the product with this documentation, run the process or use the system?” If the user has to ask, the documentation is not complete.

IMPORTANT: A documentation should be written in accordance with the following principle: As much as necessary, as little as possible. Too much documentation is as harmful as no documentation. Too many details can paralyze processes and make documentation in the worst case unusable if it is too confusing.

In addition to the documentation requirements, is there also requirements for the reader?

One of the most common problems in writing documentation is the target group definition. Documentation does not necessarily have to be general for everyone. In the case of a system documentation, it can be assumed, for example, that the reader masters certain basics. Such conditions can be defined in the documentation in order to clearly distinguish the target group. Furthermore, a documentation can also presuppose that the reader may have to use other documents for understanding. Especially in the case of comprehensive systems, it is not sensible to pack all information in a set of documents, as the documentation can become so quickly confusing. Finally, it is also not sensible to reinvent the wheel. Documentation of any integrated systems can be linked. If the system is relevant in an interference case, the referenced material can thus be accessed. If this is not necessary, these components cannot cause any confusion.

There is too much effort for documentation

The short answer is: Yes! A good documentation is not characterized by a flood of information, but by the intelligent weighing of critical information that guides the user. It is important to emphasise that the reader can also make demands. It is important, however, that the conditions should never be implicit knowledge. This means that the reader does not have to have special experiences (company or team-based skills) to use or understand the documentation.

Example of freezing, which should NOT be set - Implicites Knowledge

Situation:
A network administrator creates a know-how article for new colleagues. The title of the article: "Efficient troubleshooting in the Central Network Management System"

Context:
The system administrator has been working in the company for decades. He knows all systems by heart and knows every trick to fix every problem within minutes.
In order to implement various customer requirements, different adaptations to the infrastructure have been made in the past, which are not documented. The article should help to fix certain problems if the administrator has no time.

Example of implicit knowledge:
In a section of the article on the diagnosis of network lances is explained:

"For unusually high latencies, check the configurations of the CPE router in segment B12. Often incorrect attitudes that we have maintained for historical reasons lead to these problems. Remember to use the special adjustment we have implemented for dynamic route optimization."

Implicit knowledge that is presumed:

Understanding historical configurations: The reader should know the "historical reasons" and consider the solution. New employees cannot know these historical decisions and situations, this can lead to misdecisions being made. Here either the documentation must be revised or the settings must be adapted to a standard that can be traced by other sources.

Knowledge of "special adaptation": The article assumes that the reader is familiar with an internally developed, undocumented adaptation used for dynamic route optimization. Without knowing this adjustment, it is almost impossible for new team members to implement the instructions effectively.

Local knowledge of network segments: The mention of "Segment B12" without further explanation presupposes that the reader is familiar with the physical and logical structure of the network, which could pose a challenge for new employees without extensive involvement. Here the link to a network plan can already be sufficient to pick up new team members.

Summary: In this situation, the effective use of documentation requires not only technical knowledge and experience, but also a deep understanding of company-specific practices, historical decisions and internal adjustments. Without this implicit knowledge, new team members or external consultants could seriously understand and apply the instructions.
This example shows, as already a paragraph, that documentation cannot be used for operators.

The way to the operating concept - What to consider?

This article cannot provide general information on how any operating concept has to be viewed. There are different challenges and demands in each company. Therefore, it is the task of every organization to assemble the necessary building blocks individually. For this reason, I am trying to keep myself as general as possible and to divide the concept into "modules". There are modules that should be included, unless there are explicit reasons against it, and modules that should only be used if the relevant application is present. In the following we now develop an operating concept using the example of the introduction of Windows 11 and look where this leads us.

Important: This example also serves only as an orientation! Each organization provides its own specifications and measures. Technical precautions or processes may be missing. These can only be supplemented internally!

Operating concept - Modules

Module - Introduction (Mandatory)

In the Introduction module, the principles should be defined. The introduction describes what we are doing here, who is responsible and who the documentation applies to.

In this case, the following points should be dealt with in the introduction:

  • Definition of documentation
    • e.g. The present operating concept defines the foundations for the safe operation of Windows 11 clients in the organization. The definition of a clear framework for operating Windows 11 clients is necessary to ensure smooth operation and implement policies, best practices and security configurations.
    • if necessary Need for the project -> Why must be migrated to Win11?
  • Scope
    • e.g. all Windows clients of the organization
  • User requirements
    • e.g. In order to be able to use and implement the present operating concept, the following preconditions are defined, so that the concepts described can not only be understood but can also be implemented in practice.
      • Technical understanding of Windows operating system
        • e.g. user and system management based on GPO/Active Directory
        • e.g. WSUS, MECM
      • Technical understanding of basic network services
        • for example NTP, DHCP, DNS
  • Validity / PDCA classification
    • In which interval is the present documentation checked?
  • Versioning (best in a table within the document)
    • Author
    • Date of amendment
    • Letzer worker
    • Product Owner/Information Asset Owner -> This ensures a clear responsibility, which in case of emergency ensures that contact persons are quickly available.

Module - Responsibility (Mandatory)

This module should define who is later responsible for the execution. For example, teams can be defined here. Furthermore, emergency contacts and corresponding rollers should also be documented. This section must be kept up-to-date and should be considered, for example, in the employee-lifecycle process. If an employee leaves the company and defines it as an emergency contact, it must also be traded outside a test cycle.

Here, too, each organization can have other requirements for documentation, for example from the ISMS. As a result, the operating concept can deviate greatly at the end.

In this section, for example, the following data could be found:

  • Main responsibilities
    • Main operating concept
    • Responsible for the maintenance/production of the documentation
    • responsibilities at management level (e.g. IT Head or CIO or CTO)
  • Jurisdiction
    • Responsibilities for e.g. components of the system (e.g. network, patch management, user administration)
  • Contact person for technical support
    • Contact list for support levels or hotlines
    • if necessary Listing of external service providers
  • Contact person for security-related requests
    • Contact person for implementing security policies
    • Contact person for monitoring systems
    • Contact person for security incidents
  • Data protection officer
    • Contact person for data protection incidents and processing of personal data
  • Change Responsible
    • Contact person for the approval and planning of changes within the operating system environment
  • Emergency and crisis management
    • Responsibilities for crises or emergencies
    • Responsibilities for the creation of crisis and emergency plans
  • Training and training
    • Responsibility for the training of users (possibly also creation of training material)
  • Compliance
    • Responsible for monitoring and compliance with internal and external guidelines
    • Responsible for conducting audits

Module - Validity (Mandatory)

This module defines when the documentation enters into force and in which business areas it is valid.

Module - Architecture (Mandatory) -> The "Other Documentation"

To apply a documentation, it is necessary to know how the product is integrated within the organization. This means that one should know what services are necessary and how the system interacts with other systems. The system architecture shows exactly that. This defines what needs to be given to apply the documentation (requirements).

Important: This section is highly individual. It doesn't make any sense to write everything down here. This applies not only to internal guidelines from the ISMS or other internal documents. If necessary, legal framework conditions must also be considered here, for example when personal data is processed via the client (e.g. GDPR) – encryption and access control.

Lastly, the technical setup also plays in here.

This section could contain, for example, the following information:

  • Hardware requirements
    • optionally used models from the supplier
    • minimum requirements for future models (e.g. TPM2)
  • Organisational organisation
    • Presentation of the current landscape (e.g. by network diagram)
      • Presentation of necessary systems (e.g. DNS Server, DHCP Server, Exchange Server (autodetect systems), PXE Server, etc.)
  • Network configuration
    • if necessary Location dependent
      • Description of integration into the network (VLAN, (W)Lan, WAN, VPN)
    • Network integration
      • e.g. Competent DHCP Server, Exhibiting Certification Bodies
      • Authentication options in (W)LAN
        • e.g. IEEE 802.1x, NAC
  • Security infrastructure
    • Security
      • e.g. pre-connected firewalls, endpoint protection systems, IDS/IPS systems
  • Identity and access management
    • e.g. connection to AD
    • Definition of GPOs
    • MFA -> Here more link to attachment or extra documentation, depending on system
  • Basic settings
    • e.g. data carrier encryption, client certificates for authentication against the enterprise network
    • e.g. base network configurations
    • e.g. Default Packages -> Rather than Annex
  • Data management
    • e.g. inclusion of file server or cloud systems
    • Backup and recovery strategies
    • Processes for data storage -> Link to targeting -> e.g., not to save work data on local drive but to Shares.
  • Software and Application Management
    • e.g. software distribution via Ansible or MECM -> Link to documentation
    • Patch and software management -> Either link to separate documentation or definition of e.g. Patchdays (cyclen) as well as responsibilities.
    • Will updates be made automatically?
    • Planning for larger upgrades -> processes
      • Communication to users -> Processes
  • Lifecycle
    • Definition of Syst emlifecycles -> Link to Doku or here
      • e.g. after 3 years of new computer -> If there is a separate hardware management, this point is not necessary here!
  • Communication services
    • Use of communication protocols
      • e.g. HTTP(S), SMTP, IMAP etc. -> Limitations or Basic Configurations
  • Monitoring
    • How systems are monitored
    • What is being monitored?
    • Use of Management Tools
      • Which are allowed and how can they be used?
  • Other
    • e.g. disaster recovery
    • for example BCM
    • e.g. plans for emergency procurement, for surface failures (processes and stocks)
    • e.g. standard systems
      • e.g. printer -> or systems like FollowMe Print
    • e.g. definition of standards
      • e.g. GPO for definition of standard programs

Module - Curing (optional)

This section could be used to define, for example, separate curing measures

This could include, for example, the following:

  • General curing measures (Lose)
    • Link to documentation of these curings or per short breakdown
  • Curing by reference documents

Module - Software Collection (Optional)

In this section, basic systems can be defined, i.e. systems with a defined basic set of software and configuration.
Here, for example, software white/blacklists can be defined -> Alternatively, this can be the best part of other documents, e.g. within the ISMS

  • Default software
    • e.g. basic software
      • e.g.
        • Software Center
        • Endpoint Protection (e.g. Trendmicro)
        • VPN (e.g. ZScaler, Ivanti, NCP, OpenVPN etc.)
        • O365 Suite -> Word, Excel, PowerPoint, Teams, Outlook
        • Standard browser
        • Standard Driver
        • PDF Reader
  • Specific software ->e.g. for commercial terminals ->e.g. for certain AD group
    • e.g.
      • SAP
      • Database Management Systems
      • Ticket system
      • Debug Tools
      • SDKs

Module - User Management (Optional / Mandatory)

If not otherwise regulated, everything should be defined with regard to user management.

This can look different depending on the organization, but could include the following

  • Process
    • User creation
    • User management
    • User permission
  • Rolls/users
    • Standard rollers
    • Backup users (e.g. local administrator -> Where does password management take place -> Doku does not include a password!)
    • Policies / Rights
    • Profile settings
  • Authentication
    • MFA?
    • Procedure for secure authentication
    • Treatment of "old loads" such as NTLM and SMBv1 for e.g. Windows
    • Registration procedure
    • Remote access
  • Management tools

Module - Guidelines (Optional)

If there are internal straight lines which relate to the use of endpoints, they should be mentioned here

  • e.g. Guidelines for Mobile Work
  • e.g. inventory / asset management -> processes
  • e.g. sustainability / environmental regulations

Module - External Partners (Optional)

Should the system be dependent on external partners, the partners and roles should be defined. Here, doubling can occur between the module "responsibilities".
However, it should be clear which tasks external partners have, whether they have access to corporate data and how these rights are managed. But also points such as communication, security requirements, SLAs, escalation paths and data exchange possibilities (if available)

Summary

This would have created a very basic documentation. As mentioned, you could write a lot more, but also make the feeling different...
For example, you could specify system configurations -> which standard MS programs are removed when setting the system (e.g. GameBar). But also processes for enduser management, defined SLAs, compliance requirements, cost management and usage frameworks could be defined.

However, these points must be worked out internally and cannot be the same for each organization. Here it comes to the fact that each company has other policies and obligations.

I hope this article has helped you. If you have suggestions or suggestions for improvement, please send me an e-mail blog@pure-smart.de. I am very grateful for external impressions and would be pleased to have a constructive discussion.

Back…