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:
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
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:
https://technet.microsoft.com/en-
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.
10
1.2 NETWORK
Security Requirement Purpose Implementation Guidelines
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:
https://technet.microsoft.com/en-
us/library/cc731957.aspx
3. More information is available here:
https://technet.microsoft.com/en-
us/library/cc512612.aspx
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.
13
1.3 SYSTEMS
Security Requirement Purpose Implementation Guidelines
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:
https://technet.microsoft.com/en-
us/library/cc771759(v=ws.10).aspx
https://technet.microsoft.com/en-
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:
https://technet.microsoft.com/en-
us/library/hh831424.aspx
16
1.4 REGISTRY
Security Requirement Purpose Implementation Guidelines
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
Security Requirement Purpose Implementation Guidelines
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
Security Requirement Purpose Implementation Guidelines
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:
https://technet.microsoft.com/en-
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:
https://technet.microsoft.com/en-
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:
https://technet.microsoft.com/en-
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:
https://technet.microsoft.com/en-
us/library/cc959392.aspx
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:
https://technet.microsoft.com/en
-
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:
https://technet.microsoft.com/en-
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:
https://technet.microsoft.com/en
- 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
22
2.2 ACCOUNT MANAGEMENT
Security Requirement Purpose Implementation Guidelines
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:
https://technet.microsoft.com/en-
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:
https://technet.microsoft.com/en-
ca/library/jj852273(v=ws.10).aspx
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:
https://technet.microsoft.com/en-
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:
https://technet.microsoft.com/e
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:
https://technet.microsoft.com/e
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:
https://technet.microsoft.com/e
n-ca/library/jj713507.aspx
27
3 ACCESS CONTROLS
3.1 FILE AND PRINTER SHARING
Security Requirement Purpose Implementation Guidelines
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:
https://technet.microsoft.com/en-
us/library/jj730960.aspx#BKMK_5
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:
https://technet.microsoft.com/en-us/library/cc772211.aspx
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:
https://technet.microsoft.com/e
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:
https://technet.microsoft.com/en-
us/library/cc753298.aspx
https://technet.microsoft.com/en-
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:
https://technet.microsoft.com/en-
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:
https://technet.microsoft.com/e
n- us/library/cc753298.aspx
33
4 REMOTE ACCESS
4.1 ROUTING AND REMOTE ACCESS SERVICES (RRAS)
Security Requirement Purpose Implementation Guidelines
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:
https://technet.microsoft.com/en-
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:
https://technet.microsoft.com/en-
us/library/jj730960.aspx#BKMK_5
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:
https://technet.microsoft.com/en-
us/library/dn408189.aspx
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:
https://technet.microsoft.com/en-
us/library/dn641937.aspx
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:
https://technet.microsoft.com/en-
us/library/dn408189.aspx
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:
https://technet.microsoft.com/en-
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:
https://technet.microsoft.com/en-
ca/library/cc772107.aspx
36
5 SERVICES
5.1 SERVICES
Security Requirement Purpose Implementation Guidelines
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
Security Requirement Purpose Implementation Guidelines
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
Security Requirement Purpose Implementation Guidelines
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
Security Requirement Purpose Implementation Guidelines
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
Security Requirement Purpose Implementation Guidelines
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
Security Requirement Purpose Implementation Guidelines
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:
https://technet.microsoft.com/en-
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:
https://technet.microsoft.com/en-
us/library/cc766178.aspx
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:
https://technet.microsoft.com/en-
us/library/cc766178.aspx
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
Security Requirement Purpose Implementation Guidelines
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
Primary CIMPLICITY Server
Secondary CIMPLICITY Server
TCP/IP 49152-65535+ IP-SEC
g User registration manager synchronization
Primary CIMPLICITY Server
Secondary CIMPLICITY Server
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
Primary CIMPLICITY Server
Secondary CIMPLICITY Server
TCP/IP *4000 IP-SEC
m Router ping for redundancy
Secondary CIMPLICITY Server
Primary CIMPLICITY Server
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.