DRAFT
TARGETED RMIS INFRASTRUCTURE SECURITY STANDARD
(Covers network and server operating system security)
Modified: 2/13/2016
These standards are intended to be implemented within RMIS for the protection of systems and data and to facilitate compliance to legal and other mandates. Where there are
technical or operational limitations, compensating controls will be implemented with the approval of the ETSS IAS area.
ISO
17799
Section
#
ISO 17799
Security
Category
ISO 17799
Control
Objective
Baseline RMIS
Security Controls
Security Control Details
Red Zone
(High Security)
Current or planned Devices or Solutions
Responsible
Parties
Yellow Zone
(Moderate
Security)
Green Zone
(Normal
Security)
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Recommended
Recommended
Recommended
Recommended
Recommended
Recommended
ComTech
ComTech
ComTech
ComTech
Mandatory
Mandatory
Recommended
Mandatory
Recommended
Mandatory
ComTech
ComTech
Mandatory
Mandatory
Recommended
ComTech
Mandatory
Mandatory
Mandatory
Mandatory
Recommended
Recommended
ComTech
ComTech
Mandatory
Mandatory
Recommended
ComTech
Mandatory
Mandatory
Optional
ComTech
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Optional
ComTech
ComTech
Mandatory
Mandatory
Optional
ComTech
Mandatory
Mandatory
Optional
ComTech
Mandatory
Mandatory
Recommended
ComTech
Mandatory
Mandatory
Mandatory
Mandatory
Recommended
Recommended
ComTech
ComTech
NETWORK SECURITY
10
Communicatio
n and
operation
management
Ensure
correct and
secure
operations
A.
Diagram
B.
Patch
management
C.
Device
security,
configuration
protection &
protocols/ser
vices control
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
11
Access Control
Control
access to
information
D.
Network
device
access
management
12.
13.
14.
15.
16.
17.
18.
19.
Author: Leo Howell, CISSP
Maintain accurate detailed network diagram
Treat network diagram as High Security Data
Test critical patches before application
Apply relevant critical (as defined by relevant
network administrator) patches within 2 weeks of
release
Apply relevant non-critical patches at least annually
Encrypt passwords, keys, SNMP community strings,
etc. stored in active and backup configuration files
Treat device configuration files as High Security
Data
Backup appropriate system configuration files
Change vendor default passwords (e.g., SNMP
community strings, privilege accounts, setup
accounts, etc.) and default security settings
Harden network switches, routers, firewalls, IDSes,
VPN concentrators, NMSes, etc. by disabling all
unnecessary services, protocols, ports
Disable all clear text management protocols (e.g.,
TELNET) and limit access on a need-to- know basis
Disable or isolate inactive network switch ports
Use central AuthN to authenticate access to network
devices
15. Use central AuthZ for authorization of actions
on network devices
16. Use central Accounting to log individually
identifiable successful or unsuccessful AuthN
requests
Use central Accounting to log individually
identifiable actions on network devices
For local access management:
Delete all non-essential accounts
Disable all inactive access accounts (e.g., temporary
vendor accounts)
1
DRAFT
E.
Limit VLAN
Distance
F.
Secure
network
management
G.
Secure
securitymanagement,
monitoring,
testing
Virtual-zone
access
control
H.
Author: Leo Howell, CISSP
20. Disable anonymous access
21. Use strong passwords (see University password
policies)
22. Enforce password changes for privilege user
accounts
23. Configure break-in detection (maximum strikes,
based on University policies)
24. Configure devices to take appropriate actions if
break-in is detected (e.g., automatically disabling
account)
25. Configure individually identifiable AuthN
accounting (to be able to map successful or failed
logon attempts to individual access accounts); E.g.,
have administrators accessing devices with their
own unique id
26. Configure individually identifiable AuthZ
accounting (to be able to map actions taken to
individual access accounts)
27. Synchronize all device system clocks with
University approved time servers
28. Configure logging to show date and timestamps
29. Limit physical locations covered per VLAN (e.g.,
avoid having single VLANs that spans multiple
buildings)
30. Provide logical and/or physical separation of
management systems and management traffic (e.g.,
out of band (OOB) network management, separate
physical network, virtual private networks, etc.)
31. Provide logical and/or physical separation of
security monitoring and testing systems and traffic
(e.g., separate physical network, virtual private
networks, etc.)
Mandatory
Mandatory
Mandatory
Mandatory
Recommended
Recommended
ComTech
ComTech
Mandatory
Mandatory
Optional
ComTech
Mandatory
Mandatory
Optional
ComTech
Mandatory
Recommended
Optional
ComTech
Mandatory
Recommended
Optional
ComTech
Mandatory
Recommended
Optional
ComTech
Mandatory
Mandatory
Mandatory
ComTech
Mandatory
Mandatory
Recommended
Recommended
Recommended
Recommended
ComTech
ComTech
Mandatory
Mandatory
Recommended
ComTech, IAS
Mandatory
Mandatory
Recommended
ComTech, IAS,
ISS
32. Create and maintain inter-zone diagram
33. Filter inbound traffic (ingress filtering) to prevent
entry of packets with invalid source or destination
addresses (e.g., RFC 1918 filtering – i.e., filter
traffic from the Internet with spoofed private IP
addresses)
34. Filter all Internet access to this zone
35. Filter general campus access to this zone
36. Filter outbound traffic (egress filtering) to prevent
exit of packets with invalid source or destination
addresses (e.g., RFC 2827 filtering – i.e., filter
traffic from within the network with non-University
assigned Internet source addresses)
37. Limit traffic from the Internet inbound to this zone
to that required for documented University
requirements (e.g., approve all firewall rules on an
event-by-event basis)
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
IAS
ComTech
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Optional
Optional
Mandatory
ComTech
ComTech
ComTech
Mandatory
Mandatory
Optional
ComTech, IAS
2
DRAFT
SERVER OPERATING SYSTEM (OS) SECURITY
Communicatio
Ensure
I.
Secure
ns and
correct and
Platform
operations
management
10
secure
operations
J.
Patch
management
38. Use University approved encrypted communication
for all remote access (e.g., IPSec or SSL VPN,
HTTPS, etc.). Telecommuting is an example of
remote access.
39. Use University approved encrypted communication
for all extranet access (e.g., network link to partners
or vendors)
40. Use University approved encrypted communication
for all mobile device access (e.g., hand-held,
laptops).
41. Limit traffic allowed through VPN tunnels to that
required for documented University requirements
(e.g., setup ACLs for traffic allowed in VPN
tunnels)
42. Use at least 128-bit keys for all secure tunnels,
including VPN, SSL, SSH, etc.
43. Limit traffic from any other zone to that required for
documented University requirements
44. Disable all non-essential wireless network cards on
devices in this zone
45. Prevent direct Internet connection to privilege tools
Mandatory
Mandatory
Optional
ComTech
Mandatory
Mandatory
Optional
ComTech
Mandatory
Mandatory
Optional
ComTech
Mandatory
Mandatory
Optional
ComTech
Mandatory
Mandatory
Optional
ComTech
Mandatory
Mandatory
Mandatory
ComTech
Mandatory
Mandatory
Optional
ComTech, ETSS
Mandatory
Recommended
Optional
ComTech, ETSS
46. Use only hardware and software for which vendor
support for security patches exist
Mandatory
Mandatory
Recommended
47. Test/evaluate critical patches before application,
within 1 month of release (except in cases of
emergencies where patches may need to be applied
more quickly)
Mandatory
Mandatory
Recommended
ISS/HSS/DES: Currently leverage information from
industry watch-dog groups like CERT, vendor
recommendations and collaborate with other Novell and
Microsoft users group to help determine when patches are
safe to apply.
Patches currently applied typically within 1 month
ETSS
ETSS
Emergency patches are applied much more quickly.
Some less critical machines are set to auto-update
48. Apply relevant critical patches within 1 month of
acceptance testing
Mandatory
Mandatory
Recommended
49. Apply relevant non-critical patches at least quarterly
Mandatory
Mandatory
Recommended
DES: All patches have to be reviewed by the NDS-Tech
group. Patches are applied at least quarterly
ISS/HSS: At least quarterly
Most of password, keys, SNMP strings, etc. are stored
encrypted by default.
ETSS
ETSS
HSS/ISS: This group is moving to SNMPv3 to make use
of added security features in that protocol, e.g., encrypted
transmission
Where possible, local system passwords are centralized
Some applications/tools like, HPSIM and rsh communicate
in clear-text
DES: This group has one app that stores passwords in
clear text
Author: Leo Howell, CISSP
3
DRAFT
K.
Server OS
security and
configuration
protection
50. Encrypt passwords, keys, SNMP community strings,
etc. stored in active and backup server configuration
files
51. Treat server operating system and appliance (e.g.,
Netscaler) configuration files as High Security Data
52. Backup configuration files and system states as
needed
53. Change vendor default passwords (e.g., SNMP
community strings, guest accounts, setup accounts,
etc.) and change vendor default security settings
54. Harden servers by disabling or removing all
unnecessary applications, services or protocols
Mandatory
Mandatory
Recommended
Yes
ETSS
Mandatory
Mandatory
Recommended
Mandatory
Mandatory
Recommended
Yes
ETSS
Mandatory
Mandatory
Recommended
For the most part this is done.
ETSS
ETSS
However, some defaults still exist, like some SNMP
community strings.
Mandatory
Mandatory
Recommended
Also databases or database management tools have been
identified in the past with no passwords
Currently have internal documented best practice
procedures for building Windows and Linux servers (Eric
Sillberberg to provide Server Deployment Guideline
document) _
ETSS
ISS is currently working on standard server images based
on requirements and best practices
Standard VMware images exists for different groups –
Unified Infrastructure Project
55. Disable all clear text management protocols (e.g.,
TELNET)
56. Separate operating system and application
operational context, where appropriate (e.g., run OS
on separate partition)
Mandatory
Mandatory
Recommended
Mandatory
Mandatory
Optional
DES has installation guides and configured based on
vendor specs.
TELNET, FTP, RSH is still in use for management
Generally done in Unix environment with allocated disk
space/partitions for OS separate from apps.
ETSS
ETSS
Data is well separated from Apps and OS since most
systems make use of the SAN for storage
L.
Secure
server
management
57. Synchronize all server system clocks with
University approved time servers
Mandatory
Mandatory
Recommended
58. Provide logical and/or physical separation of
management systems and management traffic (e.g.,
out of band (OOB) system management, separate
physical network, virtual private networks, etc.)
Mandatory
Mandatory
Recommended
Limitations exists in some vendor applications that expects
a single drive/partition
Yes, all clocks currently synchronized with University
approved time server. Currently using PS Stratum 0 time
servers.
ISS/HSS: There is currently an established management
VLAN, however some management tools currently live in
the production networks
ETSS
ETSS
DES: Management tools live on the production network,
but implementation is currently underway to created a
firewalled management subnet by March 2007
ISS (Brian Brezina) is currently working on a project
for build management network(s) for all management
systems
Author: Leo Howell, CISSP
4
DRAFT
M.
Server
access
management
59. Use central AuthN to authenticate access to server
Mandatory
Mandatory
Optional
Novell: Mainly authN through eDir and accounts are
synchronized to local accounts
ETSS
Windows: AuthN is mainly through Active Directory;
users log on via AD, However, sometimes local logon is
required
There is no local to domain sync in the windows servers
60. Use central AuthZ for authorization of actions on
server
Mandatory
Mandatory
Optional
UNIX: Predominantly Sun’s Network Information
Services (NIS).
WINDOWS: The full AuthN, AuthZ and Accounting
(AAA) features of AD is used for central access
management of windows servers
ETSS
UNIX: Role based access control (RBAC) via (NIS). This
is done on a group level, e.g., HSS, ISS, ESI, however, all
users within a group have full privileges.
There is also local authN and AuthZ controls especially for
programmers and developers for them to connect to
specific boxes.
LDAP is currently being evaluated as a replacement for
NIS.
61. Use central Accounting to log individually
identifiable successful or unsuccessful AuthN
requests
62. Use central Accounting to log individually
identifiable actions on servers
Mandatory
Mandatory
Optional
Novell: Group-based authZ is setup with different levels of
access for different groups. E.g., DES administrators have
full access to the NCS.NCSU container, but Client
Services have limited access.
WINDOWS: GPO is setup for enhanced auditing;
ETSS
UNIX: auditing is configured
Mandatory
Mandatory
Optional
NOVELL: RedLine project being looked at for eDir log
monitoring and auditing.
WINDOWS: GPO is setup for enhanced auditing;
ETSS
UNIX: auditing is configured
NOVELL: RedLine project being looked at for eDir log
monitoring and auditing.
63. For local access management:
64. Delete/Disable and/or rename all non-essential
accounts and groups (e.g., guest on windows
systems)
Mandatory
Mandatory
Optional
Windows: Guest is disabled unless needed; Admin
accounts are renamed;
ETSS
ETSS
Unix: “nobodyuser” is disabled/deleted on Unix
DES: Backdoor admin accounts are created for emergency
management. These passwords are changed on a regular
basis and upon disgruntled terminations
Author: Leo Howell, CISSP
5
DRAFT
65. Disable all inactive accounts (e.g., temporary vendor
accounts) as directed by the RISSP-Identity and
Access management services security standard.
66. Disable unwanted anonymous access to operating
system service
67. Limit users with access to root, domadmin, or
administrator password by business necessity
68. Limit root, domadmin or administrator logon to
absolute documented business necessity
Mandatory
Mandatory
Optional
Neither DES, HSS, ISS has any inactive or temporary
accounts
ETSS
Mandatory
Mandatory
Optional
Current practice
ETSS
Mandatory
Mandatory
Recommended
Current practice.
ETSS
Optional
However, under the Unified Infrastructure Project,
different levels of privileges will be established.
Users in ISS, HSS are required to login with individual
accounts and change context to root (e.g., “su”) is required
on a task-by-task basis.
ETSS
Mandatory
Mandatory
ISS and HSS also has a script that watches for login as root
and displays a message to users about the rule to login with
own accounts. Logs from this script is reviewed by ISS
(Jim McDonald and Don Waterman).
69. Use strong passwords (see University password
policies)
70. Configure break-in detection as directed by RISSPIdentity and Access Management services security
standard
Mandatory
Recommended
Mandatory
Mandatory
Recommended
71. Limit user privileges by account or groups
72. Configure individually identifiable AuthN
accounting (to be able to map successful or failed
logon attempts to individual accounts)
Mandatory
Mandatory
73. Configure individually identifiable AuthZ
accounting (to be able to map actions taken to
individual accounts)
Mandatory
74. Configure logging to show date and timestamps
75. Send copies of security logs to central ETSS log
correlation system
Mandatory
Mandatory
76. Disable wireless cards “ad-hoc” features on devices
in this zone
Author: Leo Howell, CISSP
Mandatory
Recommended
Mandatory
Optional
Recommended
ISS/HSS is also investigating SUDO-based command
control for access under UNIX.
Current practice
DES: Break-in detection is currently configured for all
server login. [Vic Lynn to provide details].
HSS/ISS: Break-in detection is currently configured for all
windows servers. The current settings are 3 invalid
attempts result in an automatic lockout with auto-enable
after 30 minutes. [BRIAN Brezina to verify]
Current practice
Current practice.
ETSS
ETSS
ETSS
ETSS
DES: However, DES administrators sometimes login with
super eDir accounts. When this happens, the source IP
address for the communication is logged.
Mandatory
Recommended
Only 2 persons have “tree” root password in eDir
Current practice.
ETSS
DES: However, DES administrators sometimes login with
super eDir accounts. When this happens, the source IP
address for the communication is logged.
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Optional
Only 2 persons have “tree” root password in eDir
Current practice.
Currently all PCN servers are covered.
ETSS
ETSS
Optional
Project is in progress to send all server, directory, security
systems and other logs to the ETSS central log correlation
system.
Servers do not currently have wireless cards.
ETSS
6
DRAFT
N.
O.
Browser
security
Malware
protection
77. Install management systems, privileged systems and
tools with access to sensitive systems in locations
with similar physical security controls (e.g.,
privileged workstations used access server consoles
should not be left on unmanned, unsecured in
opened offices)
78. Disable all non-essential input/output devices (e.g.,
USB, CD-RW) on devices in this zone, unless
justified for University business reasons
Mandatory
79. Use central proxy for server-based browsing
Mandatory
Mandatory
Optional
Automatic password-protected screen savers are used
ETSS
Office doors are locked when unmanned for long periods
of time.
Mandatory
Recommended
Mandatory
Optional
Not done currently;
ISS
Optional
Need central management tool e.g., Sentinel) to control
input/output devices on servers
Browsing from servers is generally discouraged.
ETSS
80. Limit server-based browsing to absolute necessity
81. Keep web browsers up-to-date
Mandatory
Mandatory
Mandatory
Mandatory
Recommended
Mandatory
82. Configured browser for strong encryption (at least
128-bit)
83. Disable Java scripting,
Mandatory
Mandatory
Recommended
Mandatory
Mandatory
Recommended
84. Disable downloading of Unsigned ActiveX controls
or Java applets
85. Disable downloading of signed ActiveX controls or
Java applets
86. Disable 1st - party cookies
87. Disable 3rd-party cookies
88. Disable browser credentials management (no asking
to remember credentials)
89. Install and enable antivirus software
Mandatory
Mandatory
Mandatory
Proxy for server-base browsing needs to be created;
including content management and white-listed sites.
Currently encouraged but not enforced nor facilitated.
Current practices, but takes into consideration application
dependencies.
Current practice
ETSS
ETSS
ETSS
ETSS
Recommended
Current practice unless needed for documented University
business
Current practice
Mandatory
Recommended
Current practice
ETSS
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Recommended
Recommended
Mandatory
Current practice
Current practice
Current practice
ETSS
ETSS
ETSS
Mandatory
Mandatory
Mandatory
Windows: All windows servers, except maybe 3% have
antivirus installed. AV conflicts with some vendor
applications, so some servers do not have AV and/or “realtime protection” is disabled.
ETSS
90. Update Antivirus software according to University
policies
91. Enable “real time” protection features
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
92. Perform daily signature updates
93. Perform weekly full system scan
Mandatory
Recommended
Mandatory
Recommended
Recommended
Recommended
UNIX/Novell: No current antivirus software. Novell AV
will be implemented by summer ‘07
Current practice
Current practice, unless there is conflict with a production
application
Current practice
HSS/ISS: performs full daily system scans
ETSS
ETSS
ETSS
ETSS
ETSS
DES: Full daily scan of user shares is performed
Author: Leo Howell, CISSP
7
DRAFT
94. Register antivirus client with a central University
management system
Mandatory
Mandatory
Recommended
DES: All DES AV clients register with campus AV
System, which in turn registers with Symantec.
ETSS
ISS/HSS: AV clients registers with local AV system,
which in turn registers with Symantec.
95. Use file integrity checkers to verify operating
system (OS) file integrity
Recommended
Recommended
Optional
Under the Unified Infrastructure Project, a tiered ETSS
AV system will be implemented with local regions for
DES, HSS, ISS, etc. by 2008
Currently being investigated;
ETSS
COMPLIANCE - CENTRAL MONITORING AND REPORTING
15
Compliance
Avoid
breaches of
any law,
statutory,
regulatory
or
contractual
obligations,
and security
requirement
s
P.
Legal
requirements
, Intellectual
property
rights (IPR),
University
PRR
96. Perform annual review of RMIS Infrastructure
Security Standards
Mandatory
Mandatory
Mandatory
Post-RISSP implementation
IAS
Q.
Security and
Compliance
Testing
97. Perform ongoing internal and external security
testing and remediation (e.g., scanning servers and
network devices for up-to-date patches)
Mandatory
Mandatory
Recommended
Annual vulnerability scan is performed against all internetfacing ETSS servers;
RMIS
Monthly vulnerability scans are performed against the
PCN
Periodic internal vulnerability scanning.
R.
Reporting
98. Provide separate staging VLAN for preparing
systems for production
Mandatory
Mandatory
Recommended
Currently being investigated.
RMIS
99. Provide logical and/or physical separation of
security monitoring and testing systems and traffic
(e.g., separate physical network, virtual private
networks, etc.)
Mandatory
Mandatory
Recommended
Planned.
IAS, ComTech,
ISS
100. Provide ongoing technical and executive
Infrastructure Security and Compliance reports
Mandatory
Mandatory
Recommended
Development underway.
IAS
References


International Standards Organization, ISO 17799: Code of Practice for Information Security Management
National Institute of Standards and Technology, Special Publication 800-53: Recommended Security Controls for Federal Systems
Author: Leo Howell, CISSP
8