WINDOWS HARDENING GUIDE and RECOMMENDATIONS

1

WINDOWS HARDENING GUIDE and

RECOMMENDATIONS:

WINDOWS SERVER 2012 R2

2

Disclaimer of Warranties and Liability

The information contained in this manual is believed to be accurate and reliable. However, GE Digital assumes no responsibilities for any errors, omissions or inaccuracies whatsoever. Without limiting the foregoing, GE Digital disclaims any and all warranties, expressed or implied, including the warranty of merchantability and fitness for a particular purpose, with respect to the information contained in this manual and the equipment or software described herein. The entire risk as to the quality and performance of such information, equipment and software, is upon the buyer or user. GE Digital shall not be liable for any damages, including special or consequential damages, arising out of the use of such information, equipment and software, even if GE Digital has been advised in advance of the possibility of such damages. The use of the information contained in the manual and the software described herein is subject to GE Digital standard license agreement, which must be accepted by the buyer or user before the use of such information, equipment or software.

Trademark Notices

© 2016, General Electric Company. All rights reserved.

Proficy is a trademark of GE Intelligent Platforms, Inc., a wholly-owned subsidiary of General Electric Company.

* Indicates a trademark of General Electric Company and/or its subsidiaries.

All other product names and marks identified throughout this book are trademarks or registered trademarks of their respective companies. They are used throughout this book in editorial fashion only. No such use, or the use of any trade name, is intended to convey endorsement or affiliation.

No part of this publication may be reproduced in any form, or stored in a database or retrieval system, or transmitted or distributed in any form by any means, electronic, mechanical photocopying, recording or otherwise, without the prior written permission of GE Intelligent Platforms. Information contained herein is subject to change without notice.

We want to hear from you. If you have any comments, questions, or suggestions about our documentation, send them to the following email address:

[email protected]

3

TABLE OF CONTENTS

REQUIREMENT OVERVIEW ...................................................................................................................................................................................... 5

SECURITY REQUIREMENT SUMMARY .................................................................................................................................................................... 5

HARDENING RECOMMENDATIONS PURPOSE ...................................................................................................................................................... 6

1 SECURITY DESIGN ............................................................................................................................................................................................ 8 1.1 GENERAL ....................................................................................................................................................................................................... 8 1.2 NETWORK .................................................................................................................................................................................................... 10 1.3 SYSTEMS ..................................................................................................................................................................................................... 13 1.4 REGISTRY .................................................................................................................................................................................................... 16 1.5 IMPLEMENTATION .......................................................................................................................................................................................... 17

2 AUTHENTICATION, IDENTIFICATION, AND ACCOUNT MANAGEMENT .................................................................................................. 18 2.1 AUTHENTICATION AND IDENTIFICATION ........................................................................................................................................................... 18 2.2 ACCOUNT MANAGEMENT ............................................................................................................................................................................... 22

3 ACCESS CONTROLS ....................................................................................................................................................................................... 27 3.1 FILE AND PRINTER SHARING .......................................................................................................................................................................... 27

4 REMOTE ACCESS ............................................................................................................................................................................................ 33 4.1 ROUTING AND REMOTE ACCESS SERVICES (RRAS) ....................................................................................................................................... 33

5 SERVICES ......................................................................................................................................................................................................... 36 5.1 SERVICES .................................................................................................................................................................................................... 36

6 INTEGRITY AND AVAILABILITY .................................................................................................................................................................... 37 6.1 PHYSICAL ..................................................................................................................................................................................................... 37 6.2 CHANGE MANAGEMENT ................................................................................................................................................................................. 38 6.3 PATCHES AND VULNERABILITY MANAGEMENT ................................................................................................................................................. 39 6.4 BACKUP AND FAULT TOLERANCE ................................................................................................................................................................... 40

7 AUDITING, LOGGING, AND MONITORING..................................................................................................................................................... 41 7.1 AUDITING, LOGGING, AND MONITORING .......................................................................................................................................................... 41

4

8 DOCUMENTATION .......................................................................................................................................................................................... 44 8.1 POLICIES AND PROCEDURES ......................................................................................................................................................................... 44

9 APPENDIX A IPSEC CONFIGURATION ........................................................................................................................................................... 46 9.1 IPSEC INTRODUCTION ........................................................................................................................................................................................ 46 9.2 IPSEC CONFIGURATION PROCEDURE .................................................................................................................................................................. 48

DOCUMENT CONTROL:

Name Description of Changes Date Version

Keith Chow, Manager Reviewer Initial Version 3/9/2015 1.0 Brandon Gillespie, SME Updated Revision 6/28/2015 1.1

Keith Chow, Manager Reviewer Revised 7/5/2015 1.1.1

Will Grayson Update policy references 4/16/2016 1.2

Catherine Lee Achilles Practice Certification CIMPLICITY version

9/8/2016 APC 1.0

5

REQUIREMENT OVERVIEW

Windows represents a critical component of Proficy HMI/SCADA CIMPLICITY. Serving as the basis for information delivery requires

a high level of trust in the platform. The Windows platform, as with other operating systems, can be configured in a variety of ways.

The choices made affect the level of security risk and exposure from the lowest layers up to the highest application layers.

This document focuses on the security layer of the Windows platform. When configured correctly, the platform offers a good

environment for preserving the availability, integrity and confidentiality of information hosted on or through the server(s).

SECURITY REQUIREMENT SUMMARY

The following security requirements shall serve as additional protective mechanisms specific to Windows. These requirements

serve to minimize the risk associated with Windows to the best of our ability.

6

HARDENING RECOMMENDATIONS PURPOSE

The purpose of Hardening Recommendations is to provide the framework and foundations for the design, implementation, hardening or

securing of Proficy HMI/SCADA CIMPLICITY.

This guidance was developed based upon the recommendations of the technical infrastructure organizations of business units, industry

requirements, laws, legislation, NIST and ISO 27002 standards.

7

For other valuable Windows security information, refer to:

Microsoft Technet Windows Server 2012 R2 and 2012 Security Page:

https://technet.microsoft.com/en-us/library/hh801901.aspx

Windows Server 2012 R2 Security Benchmark: http://benchmarks.cisecurity.org/downloads/show-single/?file=windows2012R2.100

NTT Windows Server 2012 Security Hardening Checklist:

https://technet.microsoft.com/en-us/security/jj720323.aspx

CIS Security Benchmarks:

http://benchmarks.cisecurity.org


http://benchmarks.cisecurity.org/downloads/show-single/?file=windows2012R2.100

https://technet.microsoft.com/en-us/security/jj720323.aspx

http://benchmarks.cisecurity.org/

8

1 SECURITY DESIGN

1.1 GENERAL

Security Requirement Purpose Implementation Guidelines

1.1.1 A domain naming convention must

be followed.

A naming convention makes it easier

for Security Administrators to detect

invalid names and to decrease the

risk of unauthorized access to the

system in a privileged state.

1. User and server creation policies

address creating users with a

standard naming convention to allow

administrators to quickly determine

user information.

2. The Security Administrator refers and

adheres to organizational naming

standards when setting up domain

naming standards.

1.1.2 All domains/OU designs created must

ease the administration of user and

groups and facilitate enterprise wide

policy enforcement.

If the environment has servers and domains

that are not known or documented, there is

an increased risk that the security of the

domain will not be maintained.

1. Domain information must be

periodically reviewed to ensure that no

rogue domain exists. Multiple tools

exist to enumerate what domains exist

on the wire.

2. Use the Active Directory Users and

Computers snap-in to create

organization units according to the

organizational hierarchy.

3. Refer to:

https://technet.microsoft.com/en-

us/library/cc700835.aspx

9

1.1.3 All clients/servers in the domain shall

contribute to the security of the

domain.

All machines authorized to have access to

the network shall be part of the same

trusted domain. This feature eliminates

NTLM authentication susceptibility to man-

in-the- middle attacks from systems posing

as servers.

1. To increase security against man-in-

the- middle attacks, disable LM/NTLM

authentication by switching the

domain controller to native mode or

enabling NTLM blocking.

2. Refer to article:


us/library/jj134043.aspx

1.1.4 Domain trust relationships must support

the domain model and security that the

client uses.

If the trust relationships do not support the

planned domain model objective, protection

of domain resources can be compromised.

1. Remove trust relationships that do

not support the approved domain

model.

2. Periodically review the current trusts

that exist in the domain in order to

ensure that these trusts support the

domain model that is in use.

1.1.5 Delegation of authority must be used

to administer the network according

to organizational hierarchy.

Logging on routinely with an

administrator account can pose a

security risk.

1. Delegation of authority must be

well planned and be based on

well-defined organizational

policies and resource

classification.

2. Administrative delegation may be

defined in one of the three ways,

depending on the organization’s

Directory structure.

3. Delegations may be implemented by

using the Delegation Control Wizard.

https://technet.microsoft.com/en-us/library/jj134043.aspx

https://technet.microsoft.com/en-us/library/jj134043.aspx

10

1.2 NETWORK


1.2.1 IPsec should be configured to provide

encryption, authorization, and validation

of the network traffic that does not

natively have these attributes.

This provides another layer of defense for

ensuring the privacy, and integrity for the

network traffic.

1. Implement IPsec for those data flows

indicated in the CIMPLICITY Secure

deployment guide. These can be

found in Table 1 of that guide.

2. Block all TCP/IP protocols and ports

other than those that are explicitly

required to support the purpose of the

system.

3. Examine the list of open ports on a

system, and close unnecessary ports.

4. Refer to: IPSec

configuration appendix in

this guide.

11

1.2.2 Port filtering must be implemented on

IPNS controller Internet accessible

servers and Vulnerable Windows Server

2012 ports must be blocked by a packet-

filtering device (i.e., router or firewall).

Not securing vulnerable Windows Server

2012 ports at the router/firewall may allow

an external unauthorized user to obtain

information about the users, servers, and

services, and penetrate the network.

1. Use firewall hardware to block

sensitive ports (incoming and

outgoing) for all Internet accessible

Windows Server 2012 servers.

2. TCP and UDP Ports must be blocked

unless specific business justification

exists:

TCP: 135, 139, 445

UDP: 135, 137, 139, 445

1.2.3 Sensitive servers (containing confidential

or restricted data) must not broadcast

their existence on the network.

Advertising that a server exists and is

available on the network increases the

risk that a user may attempt to access the

server resources.

1. Disable NetBIOS on servers.

12

1.2.4 SMB signing of packets must be enabled. The use of SMB signing can decrease the

chances of SMB sessions being hi-jacked

using man-in-the middle attacks by a

potential intruder.

1. Enable SMB signing.

2. Refer to:



3. More information is available here:



4. Ensure the following 4 registries are set

to 1

HKLM\SYSTEM\CurrentControlSet\Services\lanmanwo

rkstation\parameters\EnableSecuritySignature

HKLM\SYSTEM\CurrentControlSet\Services\lanmanwo

rkstation\parameters\RequireSecuritySignature

HKLM\SYSTEM\CurrentControlSet\Services\lanmanser

ver\parameters\EnableSecuritySignature

HKLM\SYSTEM\CurrentControlSet\Services\lanmanser

ver\parameters\RequireSecuritySignature

1.2.5 The FTP Server Service must not be

started on Domain Servers.

Passwords may be transmitted in clear

text. This type of information is

considered an “enticement” and may

provide unauthorized piece information

that could be used to compromise the

security of the server.

1. Disable FTP Server Service.

https://technet.microsoft.com/en-%20us/library/cc731957.aspx

https://technet.microsoft.com/en-%20us/library/cc731957.aspx

https://technet.microsoft.com/en-us/library/cc512612.aspx


13

1.3 SYSTEMS


1.3.1 Apply current Service packs to the

Operating systems.

If the latest service packs are not applied,

unauthorized users may be able to exploit

weaknesses in the operating system that

would have been fixed with the service

pack.

1. Service Packs must be implemented on

all Servers within 90 days from the date

that they are approved and released.

1.3.2 Security patches identified as high risk

by the Information Security Office must

be tested and promptly installed.

If the latest security patches are not

applied, unauthorized users may be able

to exploit weaknesses in the operating

system.

1. All patches or hotfixes must be tested in

a test environment that duplicates the

production environment as closely as

possible before deploying them into the

production environment.

1.3.3 All services or applications installed on

the server must be the latest version

and/or have the latest security patches

installed (not be more than 3 minor

versions back).

Older versions of services and/or

applications may contain vulnerabilities that

could be used to gain access to domain

resources.

1. A periodic review of services ensures

that all applications and services are

maintained at the current version.

2. The Administrator must not install

patches if there are critical risks or

exposures involved with implementing

the latest patches.

1.3.4 Authenticating servers must have

adequate resources to handle the user

load.

If the client utilizes the authenticating

servers for other purposes (e.g., SQL),

there is an increased risk that the server

may not possess enough resources to

service O/S Authentication.

1. The Administrator must evaluate the

appropriateness of the services running

on the machine.

14

1.3.5 Storage Servers must have

adequate storage resources.

If the system does not have adequate

storage space, data loss or interruption to

critical applications may occur if the system

runs out of space.

1. The Administrator must routinely

evaluate if the servers have adequate

disk storage space for existing

applications and anticipated data volume.

1.3.6 Removable media must not be

accessible over the network and must

be securable.

Allowing access to removable media over

the network can allow malicious users to

install trojan programs or obtain data from

the removable media. Furthermore, if the

media is allowed to be removed from a

restricted machine the data can be

compromised by malicious users by

accessing the media in machines where

they have administrative rights.

1. Removable media must be allocated

only to the users who are currently

logged in.

2. Removable media must not be set

for sharing over the network.

3. Refer to:


us/library/cc771759(v=ws.10).aspx


us/library/dd349805(v=ws.10).as

px 1.3.7 The Autoplay feature for all drive types

must be disabled.

This could pose a serious security threat

since Autoplay automatically reads the drive

when media is inserted and automatically

launches any setup program located on the

media. If the media had any malicious code,

it would be executed once inserted into the

drive.

1. Disable Autoplay for all drive types

(fixed, removable, etc.).

1.3.8 Server configuration must prevent users

from starting alternative operating

systems.

If users are allowed to boot up the server

from alternative media or after altering

Windows Server 2012 boot files, there is an

increased risk that the security of files and

directories may be compromised if the user

can execute utilities that may allow bypass

of NTFS enforced security.

1. Access to the Windows Server 2012

boot partition and files must be

restricted.

2. Review the Boot.ini file for On

Screen Display software that starts

at boot time.

15

1.3.9 Password protected screen savers must

be used on all systems.

Systems left unattended with no password

protected screen savers increase the risk

that an unauthorized user could use the

server to gain unauthorized access to

resources

1. Screen savers lock out access to the

server after a 15 minute period of

inactivity.

2. Use Domain policy deployment tools

to ensure the use of screen savers

on the server.

1.3.10 Servers must be shutdown

unconditionally after the shutdown

command is issued.

If the server does not have the

AutoEndTasks registry entry enabled,

another user could cancel the shutdown

sequence in the event a program requires

user intervention to shutdown once the

original user has left and gain unauthorized

access.

1. Enable the AutoEndTask entry in the registry

to ensure that all servers shutdown in an

orderly fashion.

1.3.11 Audit: Shut down system immediately if

unable to log security audits. This policy

setting enables or disables shutting

down the computer if it is unable to log

security events. The Trusted Computer

System Evaluation Criteria (TCSEC)-C2

and Common Criteria certifications

require that the computer prevent the

occurrence of auditable events if the

audit system is unable to log them.

If the computer is unable to record events

to the security log, critical evidence or

important troubleshooting information may

not be available for review after a security

incident. Also, an attacker could potentially

generate a large volume of Security log

events to purposely force a computer

shutdown.

1. The option must be reviewed carefully

since it could be triggered by lack of log

space or compromise systems that

require a clean shutdown.

2. Refer to:


us/library/hh831424.aspx



16

1.4 REGISTRY


1.4.1 Registration entry files (*.reg) must not

be associated with the Regedit

program.

These files have the ability to place

malicious entries in the Windows registry.

A malicious user can cause damage to the

domain.

1. Change or delete the file association.

2. Guidance method would be to

utilize open/edit functionality of

notepad.

1.4.2 Remote access to the registry must be

limited to only to authorized

administrators.

There is an increased risk that an

unauthorized user may be able to gain

knowledge of the system and/or modify

the way the system behaves and

thereby compromise network security if

remote registry access is allowed.

1. Add administrators and set permissions

to allow only administrators that require

remote access to the system.

The Primary CIMPLICITY server needs to

be able to remotely access the secondary

server’s registry. With these configuration

settings the CIMPLICITY Service on the

primary and secondary servers needs to be

configured to run as a domain user that is in

the administrators group on both the primary

and secondary servers.

17

1.5 IMPLEMENTATION


1.5.1 An enterprise-wide security policy must

be deployed to ensure that there is

uniform security on all Windows Server

2012 R2 systems.

If security policies are not uniformly

deployed, there is an increased risk of

exposure to unauthorized access.

1. Depending on the role of the system a

policy template tailored to meet

business unit needs may be applied

enterprise wide.

1.5.2 Newer Windows Servers configurations

might need to replace some of the

security policies in use on Windows

Server 2012 R2 domain controller if the

server is upgraded.

The security policies in effect while the

system is running Windows Server 2012 R2

may no longer be effective after a transition

to a newer Windows Server version. This

might open up numerous security holes,

allowing unauthorized access. Newer

Windows versions in the environment will

have to be reviewed before implementation.

1. Review and evaluate the local (or

domain) security policy with respect to

the previous Windows configuration.

18

2 AUTHENTICATION, IDENTIFICATION, AND ACCOUNT MANAGEMENT

2.1 AUTHENTICATION AND IDENTIFICATION


2.1.1 A unique initial password must be

assigned to all new accounts and all

users must change passwords

immediately when using new accounts

for the first time.

Distributing passwords via e-mail or in

printed form increases the likelihood of an

unauthorized user compromising the user

ID/ password combination.

1. Initial system passwords must be

created and distributed in a secure

manner.

2.1.2 User authentication must use

strong passwords. Passwords

must:

Not be based on words found in a dictionary or a variation on the user name,

Must contain both alpha and numeric characters,

Not contain the user’s name or user ID,

Not contain consecutive digits (e.g., 12345678) or repeated characters (e.g., aaaabbbb),

Not be cyclical (i.e., skippy11, skippy12, skippy13, etc.),

Not be blank or null, and

Provide security administrators the ability to require use of special characters.

If the use of strong passwords is not

enforced, potential intruders may be able to

guess passwords and gain access to

system resources simply by running

dictionary/brute force attacks.

1. Users must be required to use

strong passwords for access to all

resources.

2. Strong passwords can be enforced

through the local (and/or domain) security

policy.

19

2.1.3 Passwords must be stored securely by

setting 'Store passwords using

reversible encryption' to 'Disabled.'

This policy allows Windows Server to

store password information in a way that

an attacker might be able to decrypt

user credentials.

1. Set 'Store passwords using reversible

encryption' to 'Disabled'.

2. Refer to:


us/library/hh994559(v=ws.10).aspx

2.1.4 Passwords are required to:

Not be blank,

Consist of a minimum of eight alpha and numeric characters for standard user accounts,

Consist of a minimum of ten

alpha, special and numeric characters for security

administrator accounts, and

Provide security administrators the ability to require use of special characters.

If minimum password standards are not

enforced by the system's technical

configuration, it is unlikely that such

standards shall be met.

1. Periodically review the password files

to assure they comply with policy on

password character length.

2. Refer to:

https://technet.microsoft.com/en

-

us/library/hh994572(WS.10).as

px

2.1.5 Passwords must be changed a minimum

of every 90 days for all non-privileged

accounts and 30 days minimum for all

privileged accounts.

If minimum password standards are not

enforced by the system's technical

configuration, the system may be

compromised allowing unauthorized

access and potential data loss.

1. Periodically review the password files

to assure they comply with policy.

2.1.6 Account names and passwords must not

be embedded in scripts, files or

applications unless encrypted or

protected against “world-readable.”

By embedding account names and

passwords in login scripts, files or

applications, anyone with read access to

the scripts, files or applications could

extract the usernames and passwords in

order to gain unauthorized access to the

system.

1. Periodically search world readable files

for password strings.

20

2.1.7 Logon credentials shall not be cached

on the system.

If an unauthorized user is able to obtain the

cached logon credentials, they may be able

to determine valid user-id/password

combinations through the use of password

crackers.

1. Verify that Credentials are not cached on

any Windows Server 2012 R2 systems.

Delete any that are.

2. Ensure that logons are not cached.

3. Refer to:


us/library/hh994565.aspx

2.1.8 The Master Key must be used for

enhancing security by using stronger

encryption of the SAM database.

Potential intruders may modify registry

entries by using trojan methods and turning

off the syskey feature. After this, System

Administrators who unknowingly run any

software that backs up the SAM (such as

ERD Commander or Windows Server 2012

Backup utility with the ERD option turned

on) recreate the repair data in the repair

directory using weaker encryption and an

intruder may exploit this data.

1. Review the value of the Secureboot

entry that Master Key enabled.

2. Setup monitoring procedures to

include changes to this value.

3. Refer to:


us/library/hh994564(v=ws.10).as

px

2.1.9 The “allowed paths” value must not

circumvent the security of the

domain.

The values contained in the “allowed

paths” registry key allow an anonymous

user to bypass security provided by the

security policy and increases the risk that

an unauthenticated user can compromise

the security of the domain.

1. The “allowed paths” value is modified

to prevent anonymous access to other

registry keys.

2. Remove all entries in the

AllowedPaths registry entry.

3. Refer to:



2.1.10 The “AutoAdminLogon” registry entry

must not be used.

There is an increased risk that an

unauthorized user may gain knowledge of

the admin username and password for the

domain as the use of this key embeds the

clear text password in the registry. By

default Windows Server 2012 R2 should

already have this disabled, but it must be

confirmed.

1. NEVER use the AutoAdminLogon key.

2. Ensure that group policies are used

to restrict the users from changing

the “AutoAdminLogon“value.

3. Establish monitoring to examine the data

for the AutoAdminLogon registry value.



21

2.1.11 Null session access must be limited. This increases the risk of unauthorized

users gaining access to system resources

or enumerating local or domain account

information.

1. Do not allow any null session shares

and null session pipes.

2. Refer to:


-

us/library/jj852166(v=ws.10).as

px 2.1.12 The username of the last user must not

be displayed upon logon.

Doing so increases the risk that an

unauthorized user may gain knowledge of

the client domain naming standards and

obtain a valid username for use in a brute-

force attack.

1. Disable displaying Interactive Logon. 2. Refer to:


us/library/cc785301(v=ws.10).aspx

o (for Server 2008 but will apply

to Server 2012)

https://support.microsoft.com/en-

us/kb/2741622

2.1.13 If Kerberos authentication is not being

used, the LANMAN password must be

prevented from being sent over the

network.

The LANMAN password is weakly

encrypted. If this password is “sniffed” off

the wire, there is an increased risk that a

user’s password may be decrypted by a

potential intruder using widely available

tools. Primarily, this is an NT convention

and should not affect machines using

NTLMv2.

1. LANMAN authentication level will be

changed using the authentication

protocol.

2. By defaults LANMAN is disabled

in Windows Server 2012 R2.

3. Confirm LANMAN disabled.

4. Refer to:


- us/library/cc960646.aspx

http://support.microsoft.com/kb/147706

2.1.14 User must logon to change passwords. Prevent users’ passwords from being

changed without logging into the

system.

1. Account policies must be established

or modified to meet company-

established requirements.

2.1.15 Limit which accounts can be used to log

on to domain controller consoles.

A user who is able to log on to the console

of a domain controller could maliciously

exploit the system and possibly

compromise the security of an entire

domain or forest.

1. Refer to:

https://benchmarks.cisecurity.org/tools2/wind

ows/CIS_Microsoft_Windows_Server_2012_

R2_Benchmark_v1.0.0.pdf

https://support.microsoft.com/en-us/kb/2741622


http://support.microsoft.com/kb/147706

22

2.2 ACCOUNT MANAGEMENT


2.2.1 A logon banner notice shall be

consistently applied across all systems

and platforms. It shall be validated by

discussions with the Legal department.

System banner messages shall not divulge

information that could be used to

circumvent security and shall notify any

would-be malevolent user that these

communications are for the sole use of

authorized users. Such messages shall not

provide specific information about the

organization, the computer operating

system, the network configuration, or other

internal matters until the user has

successfully provided both a user-ID and a

password. In general, legal notices present

to users that a particular system is

restricted for official use and that activity

may be monitored.

1. Ensure appropriate legal notices are

implemented prior to user

authentication.

2. The suggested banner is:

3. “You are about to access a private

computer network that is intended for

authorized users only. With the exception

of existing contracts, you shall have no

expectation of privacy in your use of this

network. Use of this network constitutes

consent to monitoring, retrieval, and

disclosure of any information stored

within or sent across the network for any

purpose including criminal prosecution.”

2.2.2 User account policies must contribute

to a secure domain structure.

Weak user account policies increase the

risk that unauthorized accesses to domain

resources may be granted by enabling

potential intruders to successfully mount

different methods of password attacks.

1. Account policies must be established

or modified to meet the company-

established policies.

2.2.3 Policies and procedures must exist

for communicating account

information to users.

Without adequate policies and procedures

to communicate account information the

risk is increased that an unauthorized

individual may obtain account information

and access system resources.

1. Account information is communicated

to users in a timely and secure

manner.

2.2.4 Account expiration must be used

for contractor and temporary user

IDs.

Account expiration ensures that temporary

and contract users are prevented from

gaining access to corporate resources after

their contracts expire. These accounts

increase the risk that accounts may be used

to gain unauthorized access by vendors or

other parties.

1. The user account expiration property

must be utilized in the account creation

process for temporary and contract

users.

2. Refer to:


ca/library/jj713507.aspx

23

2.2.5 All accounts within the domain will be

ensured as required and active.

Accounts that have experienced no

activity for more than 90 days must be

disabled. After 180 days of inactivity,

accounts must be permanently

removed.

Inactive accounts make it easier for

intruders to attempt to use brute force

methods in order to compromise the

security of the system.

1. If an account has not been in use for 91

days, it will be disabled. After 6 months,

it will be removed.

2.2.6 The Administrator must have a non-

administrative account for all routine

tasks.

The use of privileged accounts for

routine tasks may allow a potential

intruder to use Trojan techniques to

gain Administrative privileges.

1. Create accounts that reflect different

roles or functions (i.e., installer, help

desk, regular user, etc.).

2. Once dual accounts are created for

administrators, security

administrators will enable the access

needed.

2.2.7 Users and groups must have full names

and descriptions.

If the description field is not utilized when

creating users, administrators may not be

able to quickly identify the user or group

when required.

1. Use of the description field makes

the identification of users and

groups easier.

24

2.2.8 User Account Review must be used to

ensure that the security provided by

the domain account policy is not

overridden.

If user accounts are created and

maintained in an insecure manner,

unauthorized access may be granted.

1. Limit the use of the user properties

that override the domain setting.

2.2.9 User Profiles must be used in all areas

that are appropriate. The user

environment must provide proper security

and standardization.

If the user environment is not adequately

restricted, users may gain access to

functions not required for their job

responsibilities.

1. Utilize user profiles where possible

to increase the restriction of the

user’s environment and to present

a standard environment to all

users.

2. The use of mechanisms such as login

scripts and login host and time

restrictions are also suggested.

3. At the domain level, make sure that

user profiles and login scripts are

defined.

4. Refer to:

https://social.technet.microsoft.com/Forums/wi

ndowsserver/en-US/3f178a0e-128e-4f4f-870a-

90c8bbf1afeb/customize-the-default-local-user-

profile-in-windows-server-

2012?forum=winserver8gen

2.2.10 A home directory must be provided

for every network user.

If the user environment does not have not

adequately restricted home directories,

users may gain access to files not required

for their job responsibilities and information

may be compromised.

1. Create an assigned home directory for

each user with the appropriate

permissions.

2. No shared user accounts shall be

created.

2.2.11 The default Administrator account must

be renamed.

If the administrator account has not been

renamed, unauthorized users may attempt

to gain access to domain resources with

this default account through a brute force

attack.

1. Rename the administrator user ID.

2. Refer to:


ca/library/jj852273(v=ws.10).aspx

https://social.technet.microsoft.com/Forums/windowsserver/en-US/3f178a0e-128e-4f4f-870a-90c8bbf1afeb/customize-the-default-local-user-profile-in-windows-server-2012?forum=winserver8gen





25

2.2.12 In multiple domain controller

environments, Replicator accounts must

be adequately secured.

A potential intruder that compromises

the Replicator account can obtain

access to critical system functionality.

1. The security settings of the

Replicator group must be evaluated

and ensured as valid.

2. The only member of the Replicator

group must be a domain user account

used to log on the Replicator services of

a domain controller. Do not add user

accounts of actual users to this group.

3. Refer to:


us/library/cc785098(v=ws.10).as

px 2.2.13 The built-in Guest account must

be disabled.

If the built-in Guest account is not

disabled, this account may be used to

gain access to domain resources without

authentication.

1. Disable the Guest account.

2. Additionally, all users requiring access to

domain resources must have individual

accounts to gain access to network

resources, enforcing user accountability.

3. Refer to:

https://technet.microsoft.com/e

n-us/library/dn535492.aspx

26

2.2.14 Ensure that all groups in the domain

are necessary and required.

If a domain has unnecessary groups or

members that do not require their

specified levels of access, individuals

may be granted unauthorized access to

domain resources.

1. If a group is needed for non-security

purposes, a distribution group must be

created instead of a security group.

2. Review current groups and verify

their distribution groups.

3. Refer to:


n-us/library/dn487460.aspx

2.2.15 Limit group memberships into

powerful groups (e.g., administrative

groups).

These users may potentially gain access

to resources that are not required for their

job responsibilities.

1. To ensure that membership in powerful

groups is limited routinely review the

members of this group.

2.2.16 All Users must have different SIDS. If domain naming conventions do not

exist, support personnel will not be able

to identify the resources that they need.

1. User and server creation policies will

address creating users with a standard

naming convention to allow

administrators to quickly determine

user information.

2. Refer to:


n-ca/library/jj713507.aspx

2.2.17 No local user accounts may exist on

a server.

To minimize potential points of attack,

local user accounts other than the built-

in administrator account will not be

created.

1. Refer to:


n-ca/library/jj713507.aspx

27

3 ACCESS CONTROLS

3.1 FILE AND PRINTER SHARING


3.1.1 Default shares permissions shall

be removed or changed.

Default share permissions not being

removed or changed may provide

complete access to the system’s hard disk

where unauthorized user action may affect

productivity of the domain.

1. Default administrative shares are

disabled on Windows Server 2012 R2.

Confirm removal of the default shares

created by the system (e.g.,

Administrative shares such as C$, etc.).

2. Refer to:

https://support.microsoft.com/en-

us/kb/954422

o For 2008 but will work for 2012

https://mizitechinfo.wordpress.com/2014/08/0

1/simple-step-implementing-file-sharing-

permissions-in-windows-server-2012-r2/

3.1.2 Files and other resources must not be

shared over the network unless there

is a specific need to do so.

If a user does not modify access

permissions for new objects, inappropriate

access may be granted to unauthorized

users.

1. Access permissions on file shares must

be set appropriately based on the type

of data contained within the share to

allow the least access level required

(i.e., do not establish a Full Control

share if only a Read share is needed).

2. NTFS permissions must also be applied

to protect shared directories.

3. Do not rely solely on share permissions

to control access to data.

4. Use Data Classification policies to

determine the level of access

necessary for various data types.

5. Refer to:


us/library/jj730960.aspx#BKMK_5



https://mizitechinfo.wordpress.com/2014/08/01/simple-step-implementing-file-sharing-permissions-in-windows-server-2012-r2/



28

3.1.3 Only grant use of the ‘Everyone’ group

when appropriate for the job role

assigned by the manager.

These permissions may allow an intruder to

the network access to file and printer share

as well.

1. Evaluate the appropriateness of

granting access to an entire group.

2. If required, use the ‘Authenticated

Users’ group in place of the group

‘Everyone.’

3.1.4 Temporary Files Controls must exist

for temporary files that are created.

If the temporary file is not adequately

protected, unauthorized users may be able

to read or modify its contents.

1. The System Administrator will create a

policy addressing how applications (in-

house developed and off the shelf)

handle temporary files (e.g., Permissions,

policies and encryption).

3.1.5 Disable Memory Dump Files except

when troubleshooting or doing a kernel

dumps.

A potential intruder may be able to

glean useful information such as user

IDs and passwords from the dump file.

1. Enable dump file creation only when it is

absolutely required. Such instances

include an application development

environment or if trouble-shooting

process failures. Performing a kernel

dump is an acceptable means to acquire

system error log information.

2. Refer to:

http://blogs.technet.com/b/askcore/archiv

e/2012/09/12/windows-8-and-windows-

server-2012-automatic-memory-

dump.aspx

29

3.1.6 Bypass traverse checking setting

determines which users (or a process

that acts on behalf of the user’s account)

have permission to navigate an object

path in the NTFS file system or in the

registry without being checked for the

Traverse Folder special access

permission. The “authenticated users”

group must be removed from the

“allowed” groups for bypass traverse

checking.

The default configuration for the bypass

traverse checking setting is to allow all

users to bypass traverse checking.

Permissions to files and folders are

controlled though the appropriate

configuration of file system access control

lists (ACLs) because the ability to traverse

the folder does not provide any read or

write permissions to the user. The only

scenario in which the default configuration

could lead to a mishap would be if the

administrator who configures permissions

does not understand how this policy setting

works. For example, the administrator might

expect that users who are unable to access

a folder are unable to access the contents

of any child folders, when, in reality, they

could access it.

1. The Administrator shall disable the

‘Bypass traverse checking’ for the

Everyone and User groups.

2. Refer to:


3.1.7 The right to debug programs shall be

granted only to those that absolutely

require this capability.

A clever use of a debugger by a user with

non-administrative rights could find a way

to assume the administrator’s capabilities.

1. The Administrator will disable

‘Debug Programs’ for non-

administrator users by setting

registry value Computer

Configuration\Windows

Settings\Security Settings\Local

Policies\User Rights

Assignment\Debug programs to

only Administrators.

2. Refer to:

https://technet.microsoft.com/

en- us/library/cc753298.aspx

3.1.8 Access to Backup and Restore groups

must be limited to the very small group of

people with that job function.

If the backup and restore user rights are

granted to a large number of users, a

user may abuse these rights to gain

access to data.

1. Separate users with backup and

restore rights into different groups.

30

3.1.9 Sensitive directories must be

adequately protected.

If the user does not have adequate

security on sensitive files and directories,

there is an increased risk that access will

be granted to unauthorized users or

applications.

1. Data classification policies will be used

to identify sensitive data / resources.

Permissions will be assigned according

to the sensitivity of the data.

2. Refer to:


n-ca/library/dn408191.aspx

3.1.10 The user profiles directory must

be adequately secured.

If user profile directories are not

adequately secured, other users of the

domain may be able to gain access to

sensitive information contained within

them.

1. Adequately secure directories where

user profiles reside.

3.1.11 Access to sensitive printers must be

controlled and Administrators must

manage parameters to control and audit

those who use each printer.

Not controlling access to sensitive

printers can allow access to

unauthorized or confidential data.

1. Determine what access to printers is

required based on the printing functions

performed by the printer (i.e., check

printing, color printing).

31

3.1.12 Drivers for sensitive printer devices must

be secured.

Allowing any user to install printer drivers

increases the risk that an unauthorized

user may install a driver granting access

to a sensitive printer.

1. Restrict print driver installation to

only Administrators and Print

Operators.

2. Refer to:




us/library/dd349805(v=ws.10).aspx

3.1.13 Directories for print spooling must

be protected.

Anyone with Read access to this directory

and its contents can read spooled jobs using

a text editor.

1. Directory permissions limit the users that

have access to the printer spooler

directories. Set the security permissions

for this folder as appropriate.

2. Refer to:


ca/library/dn408191.aspx

32

3.1.14 Executables must be protected when

there is no forensics tool available for

the monitoring and protecting systems.

If adequate virus prevention or access

control does not exist, data or productivity

loss may occur in the event of an infection

or exploit.

1. Ensure that policies and procedures for

virus prevention exist and are being

enforced.

2. Suitable anti-viral software must be

installed and set to run automatically on

every system in the enterprise.

3. Additionally, file permissions and

attributes on executable and critical

data files may be set to prevent

modification.

3.1.15 Sensitive device drivers must be secured. Allowing any user to install device drivers

increases the risk that an unauthorized

user may install a driver that may

compromise system security by providing

a potential intruder with additional tools.

1. Restrict device driver installation

to Administrators.

2. Refer to:


n- us/library/cc753298.aspx

33

4 REMOTE ACCESS

4.1 ROUTING AND REMOTE ACCESS SERVICES (RRAS)


4.1.1 Only authorized users and systems shall

be allowed to remotely access the server

through secure channels.

To limit the risk of exposure and

possible access paths.

1. Review the list of authorized users

and evaluate security options on a

regular schedule.

2. Ensure that access to the server is

only made by secure connections.

4.1.2 Auditing will be enabled on the Routing

and Remote Access Service (RRAS).

If auditing is not used and reviewed for the

RRAS, unauthorized access attempts will

not be captured. Monitoring and reviewing

this log in a timely manner may help identify

the beginning of a potential intrusion

attempt.

1. Enable Auditing for RRAS for all servers

in the domain.

2. Refer to:


us/library/dn614140.aspx

4.1.3 To limit exposure, only required

protocols shall be set up.

Additional protocols can force attacks

from outside the LAN to use TCP/IP.

1. Refer to:



4.1.4 Unnecessary ports shall be restricted

from remote access use.

Only the necessary ports will be allowed

to communicate via RRAS to minimize

the likelihood of unauthorized activity.

1. Only necessary ports will be

allowed to communicate via

RRAS.

2. This can be implemented

through the IP Packet

filtering available in the

Routing and Remote Access

Service or via firewall

configuration.

3. Refer to:



https://technet.microsoft.com/en-us/library/jj730960.aspx#BKMK_5




34

4.1.5 RRAS access attempts must be limited

to five.

If the number of logon attempts prior to

disconnection is reduced, potential

intruders utilizing automated tools to attack

an account using brute force might be

deterred or slowed.

1. Only five authentication attempts will

be allowed before the user is

disconnected.

2. Refer to:



4.1.6 RRAS must be setup to answer after

six rings.

A modem that answers after multiple rings

increases the time required for an

unauthorized user to face a logon prompt.

This may deter some unauthorized users

who attempt to use automated brute force

techniques to gain access.

1. Modems will be set to answer after six

rings in order to deter unauthorized users

from attempting to gain access to

corporate resources.

2. Refer to:



35

4.1.7 RRAS access must be limited to roles

that require it for their job functions.

Improperly configured RRAS settings

and/or permissions will weaken effective

enterprise security. In the case that the

account is compromised, attaching to

RRAS with a lower privileged account may

limit the amount of damage caused by an

unauthorized user.

1. Specifically review domain or local

administrator level accounts that

possess RRAS access.

2. Refer to:



4.1.8 Deploy BitLocker encryption If the encryption feature is not used, a

third party may be able to use tools that

sniff sensitive logon information.

1. To setup BitLocker encryption refer to: https://technet.microsoft.com/en-ca/library/jj612864.aspx

4.1.9 The RRAS callback feature must be utilized.

The RRAS callback feature provides an

additional level of authentication security

by ensuring only pre-determined

numbers are called and/or that an

accurate log of the numbers used for

connection is maintained. These features

are not supported in Win Server 2012,

however; with the installation of

Adprep.exe certain features from

previous versions of Windows server can

be utilized.

1. Enable RRAS callback feature.

2. Review user dial-in profiles and note any

users who are authorized for dial-in but

do not have callback settings enabled.

3. Refer to:


us/library/dd464018%28v=ws.10%29.aspx

4.1.10 Domain security policies shall be

enforced on users dialing in to the

domain.

When users dial-into a domain through dial-

up networking, the domain security policy

may not be enforced on the user’s machine

under certain conditions. This may allow

users to circumvent domain security

settings.

1. Security profiles will be refreshed once

a user has established a dial-in

connection to the domain.

2. Refer to:


ca/library/cc772107.aspx

https://technet.microsoft.com/en-us/library/dd464018%28v=ws.10%29.aspx

https://technet.microsoft.com/en-us/library/dd464018%28v=ws.10%29.aspx

36

5 SERVICES

5.1 SERVICES


5.1.1 Only required services shall be installed

and started.

Any service or application is a potential

point of attack. Running unnecessary

services may compromise system security

by providing a potential intruder with

additional tools (e.g., the use of scheduler

service) or options.

1. Only required services shall be started.

5.1.2 Services running in the domain shall not

present users with enticement

information.

The messenger service can be used by

unauthorized persons to enumerate

additional information about machines on

the network.

1. The Messenger service is started

only if required for the operation of

the domain.

2. Refer to:

https://technet.microsoft.com/

en-ca/library/hh831669.aspx

5.1.3 Scheduled job service shall be

restricted only to administrator level

users.

If the schedule service is not restricted to

administrator level users, there is an

increased risk that a non-administrator

level unauthorized user can utilize the

schedule service to increase privileges

through execution of third party tools

using the “AT” command.

1. Ensure that the schedule service is

restricted to administrator users.

37

6 INTEGRITY AND AVAILABILITY

6.1 PHYSICAL


6.1.1 Windows Servers shall be housed in a

location containing proper controls to

prevent physical damage to the

hardware. These controls include a

separate Heating Ventilation and Air

Conditioning (HVAC) system, back-up

power, a dry pipe or gas- based fire

control system, a water detection system,

and raised floors.

In addition to security controls, physical

protection and disaster controls protect

hardware, software and data from

ongoing physical threats such as power

failures and disturbances, Heating

Ventilation and Air Conditioning (HVAC)

failures, environmental disasters, floods,

fire or explosions, earthquake and human

error, sabotage or espionage.

1. Maintain adequate environmental

control conditions.

2. Make sure that in an emergency

situation, someone can manually

power cycle the server and/or be

able to console into it.

38

6.2 CHANGE MANAGEMENT


6.2.1 Follow documented Change Control

policies and document all Windows

Servers changes.

Proper change management procedures

mitigate the risk of exposure through

misconfigurations and supply proper

documentation to ensure continuity in

server maintenance.

1. Formalized and documented change

control processes shall be followed for

the server hardware and underlying

operating system to control modifications

and maintenance.

2. The Windows Server shall be backed

up before and after configuration

changes.

6.2.2 In order to ensure the security of

your network, a Windows Server

must be functionally tested before

going into operation.

In order to ensure the proper functioning

of the server, it shall be tested, first in a

test network, then in the production

network.

1. Regularly review the Windows Server.

2. An independent third party shall

regularly perform an external audit.

39

6.3 PATCHES AND VULNERABILITY MANAGEMENT


6.3.1 Information systems security

administrators shall consistently review

all security related and vendor specific

updates and patches and facilitate these

upgrades.

Being abreast of the latest security news

enables the system administrator to work

toward proactively securing systems.

Failure to react to security alerts may

compromise overall security.

1. Subscribe to the appropriate mailing

lists and newsgroups. Consider using a

free mail accounts such as Yahoo or

GMail in order to minimize exposure

when posting to newsgroups or mailing

lists.

6.3.2 Patch levels shall be kept current (no

more than 3 minor revisions back) as

they correct software bugs and address

exploits that may compromise Windows

Server.

Vulnerabilities that pose a threat to

Windows Server emerge continually. It is

important that the system administrator

keeps abreast of emerging problems and

reacts accordingly.

The administrator shall subscribe to

different channels of notification, such as

CERT and hardware vendor related

forums. Patches to security problems shall

be applied as soon as they become

available, adhering to the change

management process.

1. Visit the vendor website for the

appropriate firewall/switch for the latest

patch information. Obtain the latest

patch, test it and install it using change

control procedures.

2. If available, subscribe to hardware

vendor mailing lists for updated

security information.

3. Ensure that Windows Server is at the

latest vendor supported security patch

level for the software installed.

40

6.4 BACKUP AND FAULT TOLERANCE


6.4.1 Active Directory must be made redundant. If redundant user account databases do

not exist in the domain, users attempting to

logon in the event of a Domain controller

failure will not be authenticated and a

timely recovery from a server crash would

be more difficult to accomplish.

1. Maintaining a minimum of two

domain controllers with replication

setup to ensure continued usability

and accessibility in the event of a

server failure.

6.4.2 Use UPS or Backup power supply to

ensure continued functioning and/or

proper shut down of the system in the

event of a power loss

In the event of a power failure, a UPS that

is not configured to shut down the server

in a controlled manner increases the risk

of data loss.

1. All servers must be equipped with a

UPS that can automatically shut down

the server and provide adequate power

to allow users to save their files and

disconnect before shutting down (where

appropriate and possible).

6.4.3 Backup procedures must exist for

all servers.

Lack of policies and procedures related to

backup and retention may result in

difficulties with the enforcement of backup

administration across the enterprise. If

backup policies are not enforced across the

enterprise, the ability to recover critical data

may be at risk.

1. Follow documented backup and

retention processes.

2. Refer to vendor solution

documentation on backup methods.

6.4.4 Critical systems must use fault

tolerant storage.

If the server does not have adequate fault

tolerant features, a disk failure may cause

a loss of sensitive data and/or interrupt

mission critical applications.

1. Utilize disk fault tolerance features

that enhance the reliability of

critical systems.

41

7 AUDITING, LOGGING, AND MONITORING

7.1 AUDITING, LOGGING, AND MONITORING


7.1.1 The audit policy shall record enough

detail to allow for the review of audit

events.

If the audit policy does not record enough

detail to adequately review events occurring

within the domain, unauthorized activities

and access attempts will not be tracked in a

timely manner. Additionally, if the client

does not capture successful logon events,

the client will not be able to track

unauthorized activity after it has occurred.

1. Set the audit settings to match

the following:

Logon Events - success and failure

Account Logon Events - success

and failure

File and Object Access - success

and failure

Privilege Use - failure

Account management - success

and failure

Policy Change - success and failure

System Events - success and failure

Process tracking - success and failure

Directory Service Access - none

2. Refer to:


ca/library/dn319078.aspx

7.1.2 The audit log must be reviewed quarterly. If procedures for audit log review are non-

existent or not performed in a timely

manner, unauthorized access to domain

resources may go undetected for an

extended period of time.

1. Ensure that policies and procedures

exist for reviewing system event logs in

a timely and consistent manner across

the enterprise.

42

7.1.3 Access to the event log files will be

controlled and allowed only to those

with this job function or security roles.

If file and directory permissions are weak

for event log files, unauthorized users may

copy the data. The event log files may

help a potential intruder by providing

information about users, services and

other network information that could be

used to exploit network resources further.

1. The monitoring and restriction of

directory permissions on the event log

files prevents their replication to

alternative media.

7.1.4 Log files shall be retained for an

adequate time period.

Failure to maintain log files after review

increases the risk that later events

discovered or reported will not be tracked

to the original occurrence in an accurate or

timely fashion.

1. The maintenance of log files on

alternate media for a minimum 90 days

online and 2 years offline facilitates

timely location of audit data.

2. Refer to:



7.1.5 Adequate disk space is allocated for

the event viewer.

If adequate disk space is not allocated,

events can be overwritten before they can

be reviewed and unauthorized activity may

go undetected.

1. Allocate and monitor adequate disk

space for the event logs.

2. Refer to:



7.1.6 Enable Successful Access auditing

for restricted or confidential data (file

and directory).

Auditing Successful Access for critical

resources will help in identifying

unauthorized users who may otherwise

have compromised system security.

1. Administrators will activate success

auditing on a file or folder containing

confidential or restricted data.

7.1.7 Successful access to sensitive registry

keys must be audited.

Auditing sensitive registry access will help

in identifying unauthorized users who may

otherwise have compromised system

security.

1. Activate success auditing on a registry

key.

2. File and Object success auditing

must be enabled in the local security

policy for these events to be logged.

43

7.1.8 Backup and restore privileges are audited. If auditing of backup and restore privileges

is not performed, there is an increased risk

that unauthorized use of these privileges

will not be tracked in a timely manner.

1. Audit backup and restore privileges

and review the audit logs frequently.

7.1.9 A current inventory of network

hardware and software must be

maintained.

Failure to maintain a current inventory of

network hardware and software increases

the risk that substandard or obsolete

software may be introduced into the

network or that software changes will not

be identified in a timely manner.

1. Documentation will be maintained

detailing all network hardware and

software.

44

8 DOCUMENTATION

8.1 POLICIES AND PROCEDURES


8.1.1 Policies and procedures will exist to

classify data based on information

content, value of data, and risks

associated with its loss.

In the event of a security compromise,

sensitive data may fall into the wrong

hands. Data classification will make it

easier to consistently implement and

enforce protection measures such as data

encryption for sensitive data across the

enterprise.

1. Ensure that data-classification policies

and procedures are practiced across

the enterprise.

8.1.2 Policies and procedures for software

procurement and licensing must be in

place and enforced.

If policies and procedures are not in place

for software procurement and licensing,

there is a risk of compromising enterprise

integrity and security with the use of

unauthorized software (from legal and

illegal sources).

1. Enforce the existence of policies

and procedures that address

software procurement, licensing,

and metering.

8.1.3 Policies and procedures must exist

regarding connections to remote

networks.

If users are not educated of the inherent

risks related to connections made with

remote networks, a user might

unknowingly compromise the security of

the domain.

1. Policies and procedures must exist

that address the risks inherent with

attaching to remote networks.

Type of networks permitted,

Type of connection methods, and

Business vs. personal use

file downloads and storage

45

8.1.4 Policies and procedures related to

mail attachments must be

implemented.

If users are not educated about the

inherent risks pertaining to mail

attachments, a user may unknowingly

compromise the security of the domain.

1. Develop policies and procedures

that address the risks inherent in

receiving mail from remote/unknown

users. Issues to be addressed

include:

Potential viral infection and

Security breaches via the use of trojan programs

8.1.5 A Domain Security Review will

be implemented.

Authorized or unauthorized users may

change the enterprise wide implementation

of domain security policies and procedures

if periodic security reviews are not

conducted.

1. Perform a periodic security evaluation of

the domain.

8.1.6 There must be a documented

Emergency Recovery Process in place.

In the event of a system disaster, an

Emergency Recovery Process will help

in bringing the system back to a

previous working state.

1. Established procedures must exist for

periodically testing and reviewing the

emergency recovery process.

8.1.7 Procedures must exist for periodic

server maintenance.

During maintenance periods, lack of

policies and procedures for maintenance

will decrease productivity by not allowing a

framework for performing and

communicating proper maintenance.

8.1.8 Procedures must exist for secure

Harddisk/ System access at the BIOS

level.

Protecting Harddisk or system access at

a BIOS level without any procedures in

place might make recovery/access of

data in a critical situation difficult (e.g.,

user of the machine is not available).

46

9 APPENDIX A IPSEC CONFIGURATION

9.1 IPSEC INTRODUCTION Configuring IPSec for the communication ports required for each data flow required for a machine can significantly increase confidentiality, and integrity of the communication for that data flow. The following dataflows should be considered for IPSec configuration.

Flow Description Origination Destination Destination ports *= default (configurable)

Encryption protocol

a View to Server connection

CIMPLICITY Viewer

CIMPLICITY Server

TCP/IP 32000 IP-SEC

b Alarm cast FPAM to FPS server. Requires Alarmcast enterprise license.

Alarm cast FPAM

Alarm cast FPS server

TCP/IP *8003 IP-SEC

c Historian collector to Archiver

Historian collector

Historian Archiver

TCP/IP 14000 IP-SEC

e Point manager synchronization

Primary CIMPLICITY Server

Secondary CIMPLICITY Server

TCP/IP 49152-65535+ IP-SEC

f Alarm manager synchronization



TCP/IP 49152-65535+ IP-SEC

g User registration manager synchronization



TCP/IP 49152-65535+ IP-SEC

h Reading Historian Data

CIMPLICITY Viewer

Historian Archiver

TCP/IP 14000 IP-SEC

j Historian to Historian collection

L3 Historian L4 Historian TCP/IP 14000 IP-SEC

k Router ping for redundancy



TCP/IP *4000 IP-SEC

m Router ping for redundancy



TCP/IP *4000 IP-SEC

n License server Any License Client – e.g.

GE License Server

TCP/IP 3333 IP-SEC

p Project Primary server identity broadcast

CIMPLICITY primary server

Any CIMPLICITY client

UDP 32000 IP-SEC

47

Table 1, Data flows to consider for IPSec configuration

Figure1 Dataflow diagram.

Routing

Firewall / DPI

Managed

Switch

Supervisory

Control

L2-VLAN

(Level 2)

Basic Control

& Safety

L1-VLAN

(Level1)

Routing

Firewall / DPI

DMZ1

(Level 3.5)

Operations

L3-VLAN

(Level 3)

Business LAN

Internet

(Level 4)

Enterprise Proficy HistorianInternet

WAN(if applicable)

CimView

HMI

RUN

FLT

BATT

FORCE

Dh485

Rs232

SLC 5/05 CPU

RUN PROGREM

INPUT

DC-SINK

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

POWER

ALLEN BRADLEY

!

INPUT

DC-SINK

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

OUTPUT

RELAY

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

PLC

RUN

FLT

BATT

FORCE

Dh485

Rs232

SLC 5/05 CPU

RUN PROGREM

INPUT

DC-SINK

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

POWER

ALLEN BRADLEY

!

INPUT

DC-SINK

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

OUTPUT

RELAY

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

PLC

RUN

FLT

BATT

FORCE

Dh485

Rs232

SLC 5/05 CPU

RUN PROGREM

INPUT

DC-SINK

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

POWER

ALLEN BRADLEY

!

INPUT

DC-SINK

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

OUTPUT

RELAY

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

PLC

RUN

FLT

BATT

FORCE

Dh485

Rs232

SLC 5/05 CPU

RUN PROGREM

INPUT

DC-SINK

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

POWER

ALLEN BRADLEY

!

INPUT

DC-SINK

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

OUTPUT

RELAY

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

PLC

RUN

FLT

BATT

FORCE

Dh485

Rs232

SLC 5/05 CPU

RUN PROGREM

INPUT

DC-SINK

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

POWER

ALLEN BRADLEY

!

INPUT

DC-SINK

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

OUTPUT

RELAY

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

PLC

CimView

HMI

Legend

Traffic: Originating traffic from source to destination

Black = Not allowed

Red = Needs strict control

Orange = Needs control

Green = Allowed

ProficyHistorain

Data Push Data Request

j

SIEM

Patch StagingVirus Definition

WindowsGE Patches

WorkstationWorkstation Workstation

WebSpaceCimView

DMZ2

(Level 3.5)

Backup Services

TerminalServicesCimView

MS SQL and SIEM agent

Patch Staging:Virus Definition

WindowsGE Patches

NTP

DomainController

cc

AlarmCastFPS Server

GE License Server

CIMPLICITY Primary SCADA Server

Alarm Cast GW + FPAM

CIMPLICITY Secondary SCADA Server

Alarm Cast GW + FPAM

CimEdit/

Engineeringd

efg

hh

GE LicenseServer

GE LicenseServer

MS SQL

d

km

n

nn

nn

n

n

o

a a a a

p

p

p

b b

48

9.2 IPSEC CONFIGURATION PROCEDURE 1. “Run” wf.msc to open Windows Firewall with Advanced Security 2. In Tree, highlight "Windows Firewall with advanced Security", then from menu bar select Action, then Properties 3. In Windows Firewall with Advanced Security on Local Computer dialog select IPsec Settings tab, then in IPSec Defaults frame, select Customize button 4. In Customize IPsec Defaults dialog, in Key Exchange Main Mode frame, select the Advanced radio button, then Customize button

49

5. In Customize Advanced Key Exchange Settings dialog, select Add button to display the Add Security Method dialog. It is here that you select your desired Cryptography. These settings need to be identical on each machine.

A typical example would be to set Integrity algorithm to SHA-384; Encryption algorithm to AES-CBC 256; Key Exchange algorithm to Elliptic Curve Diffie-Hellman P-384, then select OK button

50

6. Back in Customize Advanced Key Exchange Settings dialog, move SHA-384… to top of list. It is recommended to “Remove” all other options, then select OK button

7. Back in Customize IPsec Defaults dialog, in Data Protection (Quick Mode) frame, select the Advanced radio button, then Customize button 8. In Customize Data Protection Settings dialog, check the "Require encryption for all connection and security rules that use these settings" checkbox

51

9. In Data Integrity and encryption frame, select the Add button

52

10. In Add Integrity and Encryption Algorithms dialog, select ESP radio button and set your desired Algorithms. For example, set Encryption Algorithm to AES-GMC 256; Integrity Algorithm to AES-GMAC 256, then select OK button

53

11. In Customize Data Protection Settings, move ESP AES-GCM 256… to top of list. It is recommended to “Remove” all other options, then select OK button

54

12. In Customize IPsec Defaults dialog, in Authentication Method frame select desired authentication method (Kerberos V5 etc.)

13. During testing a Preshared key was used. This is not recommended in a production environment. As an example though, the next instructions described

how to set a Preshared key. Although this is also where you would set your “certificate” if you are using that authentication method.

55

14. In Authentication Method frame, select Advanced radio button, then Customize button

56

15. In Customize Advanced Authentication Methods dialog, under First Authentication methods frame, select Add button

57

16. Add First Authentication Method dialog, is where you would set your certification authority (CA) certificate if using that authentication method

17. Select the Preshared key radio button and enter any name. For example: inetwork , then select OK button

58

18. In Customize Advanced Authentication Methods dialog, move your desired method (in this example Preshared key) to top of list, then select OK button

19. Back in Customize IPsec Defaults dialog, select OK button, then back in Windows Firewall with Advanced Security on Local Computer dialog, select OK button to close all dialogs

20. In Tree, highlight “Connection Security Rules” then from menu bar select Action, then New Rule to open New Connection Security Rule Wizard 21. On Rule Type page, select Custom radio button, then select Next button

59

22. On Endpoints page, select Any IP address radio buttons for both Endpoint 1 and Endpoint 2, then select Next button

60

23. On Requirements page, select “Require authentication for inbound and outbound connections” radio button, then select Next button

24. On Authentication Method page, select Default (Use the authentication methods specified in IPsec settings) radio button, then select Next button

61

25. On Protocol and Ports page, set Protocol Type to TCP; Endpoint 1 port to All Ports; Endpoint 2 port to Specific Ports and set port a port that you are securing from Table 1, then select Next button. For example, if you are securing the CIMPLICITY client server communication you would enter TCP port 32000 for data, and UDP port 32000 for project broadcasts.

62

CIMPLICITY Broadcast Port

26. On Profile page, select when to apply rule as appropriate (Domain, Private and/or Public), then select Next button 27. On Name page, enter any name, for example: CIMPLICITY Protocol, and optional Description, then select Finish button 28. Your rule should now be displayed in Connection Security Rules list. Enabled should be Yes. If not, right click on rule and select Enable Rule

NOTE: On Windows 2012 R2 and Windows 8 and 8.1 you also need to open up UDP port 500 1. “Run” wf.msc to open Windows Firewall with Advanced Security 2. In tree, highlight Inbound Rules, then from menu bar select Action, then New Rule to open New Inbound Rule Wizard 3. On Rule Type page, select Custom radio button, then select Next button 4. On Program page, select All programs radio button, then select Next button

63

5. On Protocol and Ports page, set Protocol Type to UDP; Local Port to Specific Ports and set it to: 500, then select Next button

6. On Scope page, select Any IP address radio buttons for both Local OP and Remote IP, then select Next button 7. On Action page, select Allow the connection radio button, then select the Next button 8. On Profile page, select when to apply rule as appropriate (Domain, Private and/or Public), then select Next button 9. On Name page, enter any name, for example: CIMPLICITY IPSec UDP, and optional Description, then select Finish button

64

10. Your rule should now be displayed in Inbound Rules list. Enabled should be Yes. If not, right click on rule and select Enable Rule.

To verify that IPsec cryptology is being used 1. Start a CIMPLICITY Project on the SCADA Server and CIMPLICITY View node machines (or Webspace Client session) 2. On CIMPLICITY SCADA and CIMPLICITY View node machines (or Webspace server), “run” wf.msc to open Windows Firewall with Advanced Security 3. In tree under Monitoring > Security Associates, select Main Mode. Main Mode list box displays a line containing information about connection.

If nothing is listed and your CIMPLICITY view node (or Webspace client session) is displaying data from CIMPLICITY SCADA node then your setup is invalid and IPSec is not being used.

WINDOWS HARDENING GUIDE and RECOMMENDATIONS

Documents

Transcript of WINDOWS HARDENING GUIDE and RECOMMENDATIONS