S 2.325 Planning the Windows XP, Vista and Windows 7 security policies

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator, Head of IT

One of the most important organisational tasks to be performed when implementing Windows XP, Windows Vista and Windows 7 is to define and plan an appropriate security policy. This policy specifies the security regulations that need to be implemented later for Windows XP, Windows Vista and Windows 7 systems.

The requirements defined in the Windows XP, Windows Vista and Windows 7 security policy are implemented using organisational safeguards or by setting the corresponding security parameters at the operating system level. In those cases in which technical safeguards are inadequate, it is necessary to combine the two methods so that there are additional organisational safeguards to support and supplement the technical implementation of a policy. If possible, a technical solution should always be preferred over an organisational solution.

The Windows XP, Windows Vista and Windows 7 security policy to be created must be based on the currently valid security policies of the particular company or government agency and must not contradict these policies. In general, the existing rules applying to Windows XP are adapted or extended accordingly. When changing these rules, the technologies specific to Windows XP, Windows Vista and Windows 7 (e.g. Remote Desktop) in particular must be taken into account. In general, planning for the Windows XP, Windows Vista and Windows 7 infrastructure is based on the particular organisation-wide security policy, but the planning process also has an influence on the organisation-wide security policy via a feedback process. Finally, applicable legal regulations must be taken into account when creating the Windows XP, Windows Vista and Windows 7 security policy. The security policy for Windows XP, Windows Vista and Windows 7 must be documented and the users of the client/server network must be informed of the policies to the extent required. All administrators should know and implement the policies.

The following topics provide a rough overview of the areas such a policy needs to cover. Depending on the company or government agency and the operational scenarios to be implemented, it may be necessary to consider other aspects as well.

Physical security

Aspects relating to physical security must be taken into account when planning the Windows XP, Windows Vista and Windows 7 security policy since these operating systems can also be used on mobile computers. The general recommendations for physical security provided in M 3.1 General client and M 3.2 General stand-alone IT systems must be implemented.

Responsibilities

The responsibilities for the operation of the Windows XP, Windows Vista and Windows 7 systems must be specified in the Windows XP, Windows Vista and Windows 7 security policy.

The policy must specify which administrator will assume which responsibilities. The responsibilities to be assumed can include the following, for example:

It is also necessary for the end users performing administrative tasks in a client/server network to assume certain responsibilities. In general, these responsibilities are limited to granting other users (application/data) access authorisations to their own files, provided that these authorisations need to be specified explicitly and the default authorisation settings of the parent directory are not applied.

System administration should be performed by trained administrators. Suitable rules for substitutes must be made in this case in the framework of contingency planning.

User accounts

Before setting up user accounts, it is necessary to decide which accounts will be created locally or in the Active Directory.

Active Directory or similar solutions should be used since these inherently allow stronger authentication procedures and effective control of the accounts. The use of local accounts is to be restricted to specific applications. Furthermore, the restrictions to be applied to the accounts must be specified. This applies especially to the rules for passwords and for the response of the system to failed login attempts.

Authorisation concept

The security policy must contain an authorisation concept, among other things. The authorisation concept defines the rights granted to normal users and administrative users.

One problem in this regard is the fact that roles cannot be used in Windows XP, Windows Vista and Windows 7. For this reason, an appropriate group concept must be planned and implemented locally or in the domain. This basically requires the organisational hierarchy and the existing roles to be mapped to the corresponding groups.

The authorisation concept is implemented by assigning these groups the corresponding authorisations and defining the corresponding policies (e.g. software restriction policies), if necessary. This in turn requires corresponding planning and a determination of the responsibilities and processes required.

The following areas must be covered by the authorisation concept:

The user rights must be planned carefully since they have precedence over other rights, especially over file and directory permissions. User rights apply to the entire Windows XP, Windows Vista or Windows 7 system. The user rights are assigned through group policies, which are defined in the Active Directory for the members of an Active Directory-based domain and locally on other systems (see S 2.326 Planning the Windows XP, Vista and Windows 7 group policies). When granting user rights, it must be ensured that the authorisations and rights are granted to the groups and not to individual users whenever possible.

In Windows Vista and Windows 7, the authorisation concept must also consider the use of the User Account Control (UAC) (see S 4.340 Use of Windows User Account Control UAC in Windows Vista and higher).

Communication security

Requirements for the security of data transmissions must also be included in the security policy. It is recommended to formulate basic requirements (target state) for transmission security in the security policy and then formulate any exceptions necessary due to the local conditions. When defining requirements and the corresponding exceptions, questions relating to the required level of authenticity, confidentiality, integrity, and availability must be taken into account.

The requirements can be implemented technically in various ways. Two possible implementations are described in S 5.123 Securing network communication under Windows and S 5.90 Use of IPSec under Windows.

When implementing the requirements, the Windows firewall must be considered against the firewall functionality of separate protective software. The Windows firewall meets the normal security requirements in most cases only under Windows Vista and Windows 7 and higher. If a centrally managed protective software is already available, its firewall functionality will often be better integrated in the security function of the overall protective software than the Windows firewall of different Windows versions. Especially in mixed environments, it is recommended to formulate the necessary security levels individually for every system type in accordance with such considerations and to take the technical compatibility, the initial purchase cost and the central control into account.

Under Windows 7 and higher, integrated sensors, such as GPS sensors, can collect data. The data is used by applications and services, in particular by internet-based services. By default, sensor data is accessible from all applications installed and all service and user accounts. Therefore, they should normally be disabled to ensure the informational self-determination of the user of the IT system.

If sensors are required, concrete rules should be defined for the relevant application in advance. It is necessary to specify which software and which service and user accounts are allowed to query sensor data. Furthermore, the employees should be informed on the type and use of the data collected. It must be checked whether a separate declaration of consent by the user is required. In addition, the system should be encrypted and equipped with access protection because otherwise it will be possible under certain circumstances for a third party to extract the sensor data and misuse it for social engineering.

Logs

Like Windows 2000 and Windows XP, Windows Vista and Windows 7 offer extensive capabilities for logging security-related events (successful and/or failed attempts).

However, when these capabilities are fully utilised, it is possible for the logging tasks to overload the system and occupy large amounts of storage space. When defining the protocol settings, the overall system monitoring concept must be taken into account (see S 4.148 Monitoring a Windows 2000/XP system and S 4.344 Monitoring of Windows Vista, Windows 7 and Windows Server 2008 systems).

Aspects specific to operational scenarios

Depending on the operational scenario, there may be additional scenario-specific aspects that need to be taken into account during the planning phase. In particular, the use of peer-to-peer services generates new security aspects that need to be covered by the security policies (see also S 5.152 Exchange of information and resources using peer-to-peer service). If possible, you should refrain from using peer-to-peer services since it can adversely affect the security of the client/server network.

The aspects to be taken into account for the operation of a portable Windows XP, Windows Vista and Windows 7 system are described in S 2.328 Use of Windows XP on mobile computers and S 2.44 Use of Windows Vista and Windows 7 on mobile systems.

Another example of a scenario-specific security aspect is the use of EFS, which then leads to additional security-related requirements (see S 4.147 Secure use of EFS under Windows). Furthermore, the possible use of BitLocker hard drive encryption must be taken into account for Windows Vista and Windows 7 systems (see S 4.337 Use of BitLocker drive encryption).

Review questions:

© Federal Office for Information Security. All rights reserved.