Download a printable version of the Access Control Security Standards rtf format of    Enterprise Access Control Security Standards   file size 9MB  

 

Reference #: Ent-Std-Sec-AccCtl-11.4.2
Issue #: No.  Pri #17 Final v. 0.01
Issue Date:  May 14, 2012


Table of Contents

Executive Summary
Applicability
Scope
Network Trust
Requirements
1. Business Requirement for Access Control
2. User Access Management
3. User Responsibilities
4. Network Access Control
5. Operating System Access Control
6. Application and Information Access Control
7. Mobile Computing and Teleworking
Related Documents
Contact
Terms
Document History

Executive Summary

This document provides guidance on implementing the minimum Enterprise standards needed for compliance with the requirements of the Enterprise Access Control Policy. 

Section 11 “Access Control” of the ISO/IEC 27002:2005, “Information technology - Security techniques - Code of practice for information security management” is the basis for that policy and these standards.

Entities governed by the Enterprise Access Control Security Policy must adhere to the standards detailed in this document.


Applicability

This standard applies to:

  • Any entity that uses ITD-controlled resources to access the Commonwealth's wide area network (MAGNet).
  • Executive Department Agencies.
  • Vendors that provide information technology goods and services to agencies that are subject to this policy.

Other Commonwealth entities are encouraged to adopt this or a similar standard.


Scope

This document defines standards based upon Section 11 “Access Control” of the ISO/IEC 27002:2005, “Information technology - Security techniques - Code of practice for information security management”:

1.        Business Requirement for Access Control

2.        User Access Management

3.        User Responsibilities

4.        Network Access Control

5.        Operating System Access Control

6.        Application and Information Access Control

7.        Mobile Computing and Teleworking

These standards will help ensure that data, information, and other resources are protected from malicious or accidental events commensurate with their level of sensitivity.

These standards are effective as of the published date of this document.

Application systems in production prior to the effective date of this standard, upon major changes, must be brought into conformance.

These standards are not platform specific. Following these standards will contribute to the development and deployment of secure application systems by Commonwealth entities.

VARIANCES

Any request for a variance or a time extension, relative to meeting compliance requirements, must:

  • Be submitted to the ITD Security Office,
  • Include a documented plan which;
    • Articulates the reason for the request,
    • Enumerates the changes required for compliance,
    • Details what alternative compensating controls are proposed that will ensure all the requisite control objective(s) of the policy and standards will be met.
    • These requests will be processed according to the requirements of Enterprise Policies for variance requests.

OBSOLESCENCE

These standards replace the following Enterprise Security Standards:

  • Enterprise Public Access Standards for e-Government Applications: Application Security
  • Enterprise Public Access Standards for e-Government Applications: Network Security
  • Enterprise Wireless Security Standards: Wireless Local Area Networks
  • Enterprise Wireless Security Standards: Wireless Mobile Communications
  • Enterprise Wireless Security Standards: Wireless Personal Area Networks
  • Enterprise Wireless Security Standards: Wireless Wide Area Networks

 

 


Requirements

1. Business Requirement for Access Control

Commonwealth entities must have an access control policy that clearly states access control rules and rights for each user or group of users.  The policy should provide a clear direction for the logical and physical access controls needed to meet the business requirements.  These business requirements include access to: information, information processing facilities, and business processes.

1.1.    Access control policy

To comply with this requirement, the policy must address the following:

Security requirements of individual business applications.

  • Identification of all information related to the business applications and the risks the information is facing.
  • Policies for information dissemination and authorization, e.g. the “need to know principle” and security levels and classification of information.
  • Consistency between the access control and information classification policies of different systems and networks.
  • Relevant legislation and any contractual obligations regarding protection of access to data or services.
  • Standard user access profiles of common job roles in the organization.
  • Management of access rights in a distributed and networked environment which recognizes all types of connections available.
  • Segregation of access control roles, e.g. access request, access authorization, access administration.
  • Requirements for formal authorization of access requests.
  • Requirements for periodic review of access controls.
  • Removal of access rights.

2.    User Access Management

All stages in the life-cycle of user access, from the initial registration of new users to the final de-registration of users who no longer require access to information systems and services, must be documented. 

2.1.   User Registration

Access control procedures for user registration and de-registration must include:

  • Using unique user IDs to enable clear identification of user access and related activities;
  • Validation of user’s authorization for the use of the information system or service from the system or service owner;
  • Validation that the level of access granted to the user is appropriate to the user’s role and associated business functions;
  • Providing users with a written statement of access rights, responsibilities, and conditions of access;
  • Enabling access that is contingent upon each user’s signed statement which shall reflect the conditions of access;
  • Enabling access that is contingent upon completion of all authorization procedures;
  • Maintaining documentation of all users authorized to use the information system or service;
  • Administration of changes to users’ access privileges must be commensurate with the timing of changes in job function or employment status, e.g. a terminated employment status must be reflected in the users’ access privileges immediately upon termination being carried out;
  • Limit use of multiple access credentials by a single user for accessing systems and services,  e.g. restricting issuance of multiple access credentials to a user for access to a given information system or service;
  • Restricting re-issuance of previously issued access credentials to multiple users and;
  • Providing clear remediation steps and appropriate disciplinary actions for instances where unauthorized access is attempted or obtained by individuals.
2.2.   Privilege Management

The allocation and use of privileges must be restricted and controlled by:

  • Identifying access privileges that are associated with each product supporting a given system, e.g. operating system, database management system and each application. 
  • Allocating privileges to individuals on a need-to-use basis and on an event-by-event basis thereby providing the minimum requirement for their functional role; i.e. security principle of Least Privilege.
  • Maintaining access privilege documentation.
  • Developing and using system routines and programs to avoid the need to grant privileges to users, e.g. using an identity management provisioning solution.
  • Assigning enhanced privileges to a different user ID as opposed to a user ID that is designated for normal business use.
  • Protecting against inappropriate use of system privileges, e.g. any feature or facility of an information system that enables the user to override system or application controls.
2.3.   User Password Management

The allocation of passwords must be controlled and managed through a formal process by:

  • Obtaining signed statement from users acknowledging personal responsibilities that include keeping personal passwords confidential and keeping group passwords solely within the members of the group.
  • Providing users initially with a secure temporary password which they are forced to change upon initial login.
  • Implementing identity verification procedures when providing new, replacement or temporary passwords e.g. challenge questions etc.
  • Delivering temporary passwords to users in a secure manner; the use of third parties or unprotected (clear text) electronic mail messages must be avoided whenever feasible.
  • Requiring that temporary passwords given to an individual be unique and not easily guessed whenever possible.
  • Requiring users to acknowledge receipt of passwords.
  • Avoiding storage of passwords on computer systems in unprotected form.
  • Requiring password reset requests to include multiple validation checks prior to enabling a reset, e.g., notification to the reporting manager of the person requesting the reset, a verbal confirmation to phone number associated with the requestor, insider related information, caller ID, etc.
  • Changing default passwords.
2.4.   Review of User Access Rights

Users’ access rights must be reviewed at regular intervals through a formal process that requires:

  • Regular review of users’ access rights, after any change to access rights as a result of a change in employment status or duties, and more frequent reviews for special privileged access rights.
  • Reallocating or revoking user access rights when an individual moves from one role to another within the organization.
  • Privilege allocations must be checked at regular intervals to ensure that unauthorized privileges have not been obtained.
  • Logging changes to user access rights.

3.    User Responsibilities

Users are responsible for protecting their access to systems and information. 

3.1.   Password Use

 Users  must:

  • Keep passwords confidential.
  • Avoid keeping a record on passwords unless the record can be stored securely.
  • Change password at any indication of system or password compromise.
  • Select quality passwords that are commensurate with the security classification of the system or data being accessed.
  • Change temporary passwords at first log-on.
  • Eliminate use of automated log-on processes, e.g. stored in a macro or function key.
  • Prohibit sharing of individual user passwords.
  • Avoid using the same password for business and non-business purposes.
3.2.    Unattended User Equipment

To protect unattended equipment, users are required to:

  • Terminate active sessions when finished, unless they are secured by an appropriate locking mechanism.
  • Log-off systems when finished (i.e. not just switch off the PC screen or terminal).
  • Secure equipment from unauthorized access, e.g. Lock the device/display, etc.
3.3.   Clear desk and clear screen policy

A clear desk and clear screen policy must be adopted requiring users to address the following:

  • Sensitive or critical business information either hardcopy or electronic storage must be secured from unauthorized access.
  • Computers and terminals must be protected with a screen and keyboard locking mechanism controlled by a password, when unattended.
  • Protect incoming and outgoing mail and facsimiles in a manner that is consistent with the associated data classifications.
  • User must comply with any controls set to protect against unauthorized use of networked copiers, scanners, multi-function devices, digital cameras and other duplicating technology in a manner that is consistent with the associated data classifications.
  • Immediately remove documents containing highly sensitive information from plain sight locations such as printers or desktops. 

4.    Network Access Control

The following network access controls must be applied.

4.1.        Policy on Use of Network Services

The security principle of Least Privilege must be applied for access.

4.2.        User Authentication for External Connections

All remote users must be uniquely authenticated using a minimum of two-factor authentication prior to gaining access to any Commonwealth networked service. An encrypted channel must be used for authentication.  Two-factor authentication of remote users must be achieved using a cryptographic based technique, hardware tokens, or a challenge/response protocol.

4.2.1. Remote access is limited to the following approved Commonwealth enterprise remote access methods by users including employees, contracted business partners, and statutory business partners.  

o    ITD approved Business Partner Solution

o    Enterprise VPN Solution

4.2.2. Remote access to MAGNet networks and systems for system management and administrative purposes must use the Commonwealth enterprise approved methods.

o    Remote access via the Enterprise VPN Solution must not result in unauthorized bridging of networks to MAGNet (e.g. split tunneling). 

o    Remote system administration must be from an internal host, within a protected subnet dedicated to system management, with access logging enabled and available for review/auditing.

    • Access from the jump hosts to machines to be managed must be restricted based upon specific authorization (i.e., imposing “least privilege on the access for the device and device user).  For example – jump hosts for administrators to manage the Linux environments – should be restricted to just those Linux environments.

o    System administration architectures that should be considered include: using a virtual desktop “jump” host to ensure all communications from the managing host to the managed device is from a trusted platform.

o    All systems management must use secure communications between the management devices and the managed devices, (e.g., SSH, SSL, IPSec)

4.2.3. Remote client devices must be configured to adhere to the following Remote Access Standards including;

o   Antivirus solutions deployed, with up to date virus definitions and personal firewall configured on remote devices accessing MAGNet based systems/applications

o   Transport Layer Security (TLS) or Secure Socket Layer (SSL) must be used between a web server and browser to authenticate the web server and, optionally, the user’s browser. Implementations of TLS and SSL will provide a secure communications channel for client authentication.

o   IP Security (IPSec) or Advanced Encryption Standard (AES) 128-bit or stronger must be used to extend the IP communications protocol, providing end-to-end confidentiality for data packets traversing the Internet. The appropriate mode of IPSec and/or strength of encryption standards used commensurate with the level of security required for the data being transmitted.

4.3.        Equipment Identification in Networks

Network Access Control (NAC) must be used as a means to authenticate connections from specific locations and equipment.

4.3.1. NAC must be enforced via a secure communication channel to control access to MAGNet, services and systems; devices must be configured to adhere to the following Standards including:

          • Endpoint Protection solutions deployed and maintained to secure systems and data against sophisticated malware, such as botnets and zero-day attacks, and blocks noncompliant systems and unauthorized devices that attempt to access MAGNet based systems/applications and data.

o   All client security software solutions must be maintained: Antivirus software and definitions; patching; threats and malware detection solutions.

4.4.        Remote Diagnostic and Configuration Port Protection

Physical and logical access to systems for diagnostic and configuration purposes must be controlled in a manner that provides confidential communications with authorized access limited to diagnostic and configuration ports.

4.4.1. Use of secure channel and strong authentication.

4.4.2. In instances where remote diagnostics and configuration ports are not required for the IT Resource, the configuration ports, remote diagnostics functionality and related services must be disabled or removed.

4.4.3. In instances where such access is required to support legitimate business needs, remote access for diagnostic purposes must use an approved remote access method and mitigate risks by providing restricted access to required systems including minimizing the risk to the wider network community, MAGNet.

o   Limit access to the IT Resource with login time constraints, logging of all related activities and local Commonwealth Entity oversight of the IT Resource during the remote diagnostic session.

4.4.4. Access to networks and systems for management and monitoring purposes must be executed within protected subnets using secure/encrypted communications.

4.5.        Segregation in Networks

Networks must be segregated to control communication between users, information services, organizational structures and business functions.  Firewalls, VPNs, Network Access Control Lists (ACLs), and VLANs, are examples of methods acceptable for achieving Network segregation.

  • The following principles apply to both physical and virtualized as well as wireline and wireless environments.
  • Network segregation decisions must be based upon a risk assessment with consideration given to the following:
    • Data/System Classification (e.g. High Sensitivity, Low Sensitivity)
    • Regulatory Requirements (e.g. HIPAA, PCI)
    • Organizational Boundaries (e.g. Branches of Government, Regional Offices)
    • Network Boundaries (e.g. Internet, Internal)
    • LAN services – (e.g. File/Print servers, Printers)
    • LAN end nodes – (e.g. further separation by business function)
    • Wireless devices – (e.g. Access Points, Mobile devices)
    • Server Role – (e.g. Databases, Web servers, Application servers)
    • Environment Role – (e.g. DMZ, Prod, Dev, Test)
    • Management/Maintenance – (e.g. Update Services, System Management)
    • Storage – (e.g. SANs, NAS, Backups)
  • Segregate internal network domains from external facing network domains or DMZs.  

4.5.1. Segregate MAGNet network domains.

o   An ITD managed Common Criteria EAL4 certified firewall must be used to segregate internal network domains from external facing network domains or DMZs.      

o   Network communications and access is restricted to adjacent Layer/Tiers of a given solution.

o   Firewall or secure gateway is required to protect the internal trusted network from an external network.

o   Use public key cryptography to provide: (1) assurance that both the sender and the recipient of a message or transaction will be uniquely identified, (2) assurance that the data has not been accidentally or deliberately altered, (3) verifiable proof of the integrity and origin of the data. 

4.5.2. Agency networks must be segregated based upon organizational boundaries.

4.6.        Network Connection Control

Communications between segregated networks should be controlled to limit information services, users, and information systems’ network connections within the boundaries of applicable access control policy and requirements of the business applications.

State Entities must deploy the necessary network connection controls to limit access to the required resources and applications by Agency authorized information services, users, and information systems. 

4.6.1. Network access must be limited through network gateways that are able to manage traffic based on pre-defined tables or rules, e.g. SSL VPN gateway, Proxy, XML gateway, etc.

4.6.2. Network connection controls must include an ability to enforce user access based on criteria such as time/schedule needs.

4.6.3. State Entities must restrict access to shared networks, aligned with the access control policy and requirements of the business applications.

4.6.4. State Entities must document, test, monitor and enforce their network connection controls to ensure compliance.

4.7.   Network Routing Control

Routing controls must be properly implemented at the various layers of the network through the routing tables defined in the routers and switches with ACLs, firewalls and security gateways to further restrict and control the routing of the traffic between networks based upon the actual source and destination address, not the translated or proxy addresses.

4.7.1. Web based applications are required to provide defense in depth through the use of network routing controls within N-tiered architectures.   Standard elements of N-tiered web based applications include:

o  Web Tier – Web and Proxy services

    • Application Tier – Application services
    • Database Tier  – Database Services

The following diagram depicts the standard patterns for Allowed Inbound Network Services:

The following diagram depicts the standard patterns for Allowed Inbound Network Services:  

The following tables in this section represent the security standard patterns for approved network services.  These security patterns implement compliant standards with Internet Assigned Number Authority (IANA).

The use of IANA unassigned port range should be avoided; IANA dynamic port range (49152-65535) is designated for this purpose, port assignments for this range are reviewed and approved by ITD. 

IANA provides port assignment for some services that are not explicitly permitted in the tables below.  Many of these port assignments are not acceptable to the commonwealth e.g. “ftp”, etc.  The tables below are comprehensive to all current accepted Commonwealth traffic patterns.  Network communications that are not explicitly permitted (not listed in tables below) require a variance.

Access to DMZ Services from the INTERNET

All servers that are to be available for access from the Internet must be located in an Internet facing network that is located off of an ITD Managed Firewall, referred to as a DMZ. 

ServiceDescription / ControlTCP/UDP Port
DNS

Domain Name Server

Must connect to the ITD managed DNS service which exposes only internet facing server names

TCP 53

UDP 53

Simple Mail Transfer Protocol (SMTP)

Simple Mail Transfer 

Must be routed via the ITD SMTP services (Anti-virus/Anti-SPAM)

TCP 25
HTTPWorld Wide Web HTTPTCP 80
HTTPS

HTTP protocol over TLS/SSL

All encapsulated traffic must be filtered through a dedicated protocol level gateway (e.g. XML Gateway, Application Firewall) or terminate on a secure dedicated server (e.g. Web servers).

TCP 443
FTP

File Transfer [Control]

Anonymous GETS only

TCP 21
FTPS
FTP protocol, control, over
TLS/SSL

All file transfer requirements must be met by using  a secure file transfer service

TCP 990
FTPES
FTP over explicit TLS/SSL
All file transfer requirements must be met by using  a secure file transfer service

TCP 21

(Data Range 61408-61908)

SSH

SFTP-SSH

The Secure Shell Protocol

All encapsulated traffic must be filtered through a dedicated protocol level gateway (e.g. XML Gateway, Application Firewall) or terminate on a secure dedicated server (e.g. Web servers).

Must be located in a dedicated DMZ.

TCP 22
Secure Tunnel Services (IPSEC)All encapsulated traffic must terminate on an ITD managed VPN gatewayTCP 50, 51 UDP 500

Table 1

 

Access to DMZ Services From Internal 

 

ServiceDescription / ControlTCP/UDP Port
DNS

Domain Name Server

Must connect to the ITD managed DNS service which exposes only internet facing server names

TCP 53

UDP 53

NTP

Network Time Protocol

Network time services provided by ITD Internet DNS servers

UDP 123
Simple Mail Transfer Protocol (SMTP)

Simple Mail Transfer 

Must be routed via the ITD SMTP services (Anti-virus/Anti-SPAM)

TCP 25
HTTPWorld Wide Web HTTPTCP 80
HTTPS

HTTP protocol over TLS/SSL

All encapsulated traffic must be filtered through a dedicated protocol level gateway (e.g. XML Gateway, Application Firewall) or terminate on a secure dedicated server (e.g. Web servers).

TCP 443
FTP

File Transfer [Control]

File Transfer Anonymous GETS only

TCP 21
FTPS
FTP protocol, control, over
TLS/SSL

All file transfer requirements must be met by using  a secure file transfer service

TCP 990

SSH

SFTP-SSH

The Secure Shell Protocol

All encapsulated traffic must be filtered through a dedicated protocol level gateway (e.g. XML Gateway, Application Firewall) or terminate on a secure dedicated server (e.g. Web servers).

Must be located in a dedicated DMZ.

TCP 22
Secure Tunnel Services (IPSEC)All encapsulated traffic must pass through a dedicated ITD managed VPN serviceTCP 50, 51 UDP 500

Table 2

 

Access to Application xDMZ Services From DMZ

All servers located in an Application xDMZ can be accessed from other DMZs but not directly from the Internet.  Application xDMZ that is accessed from an Internet facing DMZ must be managed by ITD.

ServiceDescription / ControlTCP/UDP Port
HTTPWorld Wide Web HTTP

TCP 80

TCP 8080

HTTPS

HTTP protocol over TLS/SSL

All encapsulated traffic must be filtered through a dedicated protocol level gateway (e.g. XML Gateway, Application Firewall) or terminate on a secure dedicated server (e.g. Web servers).

TCP 443

TCP 8443

 

LDAP

Lightweight Directory Access Protocol

Must connect to a secure LDAP server

TCP 389
LDAPS

LDAPS protocol over TLS/SSL

Must be used if authentication is required, must connect to a secure LDAP server

TCP 636
SSH/SFTP

The Secure Shell Protocol

All encapsulated traffic must be filtered through a dedicated protocol level gateway (e.g. XML Gateway, Application Firewall) or terminate on a secure dedicated server (e.g. Web servers).

TCP 22
FTP

File Transfer [Control]

Anonymous GETS only

TCP 21
FTPS
FTP protocol, control, over
TLS/SSL

All file transfer requirements must be met by using  a secure file transfer service

TCP 990

Table 3

 

Access to Data Services xDMZ From xDMZ

All servers located in either a Data Services xDMZ can be accessed from other xDMZs in support of Security best practice of defense in depth, but not directly from the Internet.

ServiceDescription / ControlTCP/UDP Port
HTTPWorld Wide Web HTTP

TCP 80

TCP 8080

HTTPS

HTTP protocol over TLS/SSL

All encapsulated traffic must be filtered through a dedicated protocol level gateway (e.g. XML Gateway, Application Firewall) or terminate on a secure dedicated server (e.g. Web servers).

TCP 443

TCP 8443

LDAP

Lightweight Directory Access Protocol

Must connect to a secure LDAP server

TCP 389
LDAPS

LDAPS protocol over TLS/SSL

Must be used if authentication is required, must connect to a secure LDAP server

TCP 636
SSH/SFTP

The Secure Shell Protocol

All encapsulated traffic must be filtered through a dedicated protocol level gateway (e.g. XML Gateway, Application Firewall) or terminate on a secure dedicated server (e.g. Web servers).

TCP 22
MS SQL Server

Microsoft SQL Server

Must connect to secure, dedicated database server within a protected subnet or XDMZ

TCP 1433
Netezza

Netezza appliance must be located within a protected subnet or xDMZ.

(Not registered with IANA, but is currently allowed)

TCP 5480

(Unauthorized use per IANA)

SQL-Net

(SQL*Net)

SQL-Net

Must connect to secure, dedicated database server within a protected subnet or xDMZ.

(Not registered with IANA, but is currently allowed)

TCP 66

(IANA assigned)

 

TCP 1521

(Unauthorized use per IANA)

MySQL

MySQL

Must connect to secure, dedicated database server within a protected subnet or xDMZ.

TCP 3306
NFS

Network File System

Must connect using NFS v4 or above

TCP 2049

Table 4

 

The following diagram depicts the standard patterns for allowed outbound Network Services:

The following diagram depicts the standard patterns for allowed outbound Network Services:

 

To Internet From DMZ & xDMZs Outbound Allowed Services 

ServiceDescription / ControlTCP/UDP Port
DNS

Domain Name Server

Must connect to the ITD managed DNS service which exposes only internet facing server names

TCP 53

UDP 53

NTP

Network Time Protocol

Network time services provided by ITD Internet DNS servers

UDP 123
Secure Tunnel Services (IPSEC)All encapsulated traffic must terminate on an ITD managed VPN gatewayTCP 50, 51 UDP 500
Simple Mail Transfer Protocol (SMTP)

Simple Mail Transfer

Must be routed via the ITD SMTP services (Anti-virus/Anti-SPAM)

TCP 25
HTTP

World Wide Web HTTP

Consideration must be given to address Data Loss Prevention (DLP)

TCP 80

TCP 8080

HTTPS

HTTP protocol over TLS/SSL

All encapsulated traffic must be filtered through a dedicated protocol level gateway (e.g. XML Gateway, Application Firewall) or terminate on a secure dedicated server (e.g. Web servers).

Consideration must be given to address Data Loss Prevention (DLP)

TCP 443

TCP 8443

LDAPS

LDAPS protocol over TLS/SSL

Must be used if authentication is required, must connect to a secure LDAP server

TCP 636
LDAP

Lightweight Directory Access Protocol

Must connect to a secure LDAP server

TCP 389

Table 5

 

To Internet From MAGNet Outbound Allowed Services 

ServiceDescription / ControlTCP/UDP Port
HTTP

World Wide Web HTTP

Consideration must be given to address Data Loss Prevention (DLP)

TCP 80

 

HTTPS

HTTP protocol over TLS/SSL

All encapsulated traffic must be filtered through a dedicated protocol level gateway (e.g. XML Gateway, Application Firewall) or terminate on a secure dedicated server (e.g. Web servers).

Consideration must be given to address Data Loss Prevention (DLP)

TCP 443

 

LDAPS

LDAPS protocol over TLS/SSL

Must be used if authentication is required, must connect to a secure LDAP server

TCP 636
LDAP

Lightweight Directory Access Protocol

Must connect to a secure LDAP server

TCP 389
FTP

File Transfer [Control]

File Transfer Anonymous GETS only

TCP 21
FTPES
FTP over explicit TLS/SSL

All file transfer requirements must be met by using  a secure file transfer service

TCP 21

(Data Range >1023)

Table 6

 

5. Operating System Access Control

Prevent unauthorized access to operating systems.

5.1.    Secure Log-on Procedures

Access to operating systems must be controlled by secure log-on procedures that:

  • Suppress the display of system or application identifiers until the log-on process has been successfully completed;
  • Display a general notice warning that the computer should only be accessed by authorized users;
  • Suppress help messages during the log-on procedure that would aid an unauthorized user;
  • Validate the log-on information only on completion of all input data. If an error condition arises, the system should not indicate which part of the data is correct or incorrect;
  • Limit the number of unsuccessful log-on attempts allowed, e.g.  three attempts, and address:
    • Recording unsuccessful and successful attempts;
    • Forcing a time delay before further log-on attempts are allowed or rejecting any further attempts without specific authorization;
    • Disconnecting data link connections;
    • Sending an alert/message to the system console if the maximum number of log-on attempts is reached;
  • Limit the maximum time allowed for the log-on procedure. If exceeded, the system should terminate the log-on;
  • Set the number of password retries and the minimum length of the password relative to the value of the system being protected;
  • Consider displaying the following information on completion of a successful log-on: 
    • Date and time of the previous successful log-on;
    • Details of any unsuccessful log-on attempts since the last successful log-on;
  • Redact the password being entered or consider hiding the password characters by symbols;
  • Prohibit the transmission of identification and authentication data (e.g., passwords) without the use of industry accepted encryption standards

 

5.2.        User Identification and Authentication

All users must have a unique identifier, UserID for use with an authentication mechanism that substantiates the user’s identity so that:

5.2.1.    User actions are traceable to the responsible individual to maintain accountability;

5.2.2.    Privileged accounts are restricted to authorized use

5.2.3.    In instances where strong authentication and identity verification is required, authentication methods alternative to passwords, such as cryptographic means, smart cards, tokens or biometric means, should be used.

5.3.        Password Management

Password management must:

  • Allow users to select and change their own passwords and include a confirmation procedure to address input errors.
  • Enforce password changes.
  • Force users to change temporary passwords at the first log-on.
  • Maintain a record of previous user passwords and prevent re-use.
  • Redact passwords on the screen when being entered.
  • Store password files separately from application system data.
  • Store and transmit passwords in protected (e.g. encrypted or hashed) form.
  • Require the use of a non-shared and a unique password on each account on IT systems, including local, remote access and temporary accounts.
  • Require strong password complexity, commensurate with the level of sensitivity of the systems to be accessed, on devices that support it, with a minimum of eight characters in length; and use at least three of the following four attributes:
  • Special characters;
  • Alphabetical characters;
  • Numerical characters;
  • Combination of upper case and lower case letters.
  • Require passwords on mobile devices such as tablets, PDAs and smart phones. For mobile phones that do not support stronger password complexity, use a pin number with a minimum of 4 digits.
  • Require that default passwords be changed immediately after installation.
  • Configure IT systems to allow users to change their password at most, once per 24 hour period commensurate with the level of data sensitivity of those systems.
  • Require users of IT systems to change their passwords after a defined period (e.g.  42 days) commensurate with the level of data sensitivity of those systems.  The password expiration interval should not exceed 90 days.  The Security Office within ITD will manage the process relative to password expiration utilizing automated tools.
  • Require that IT system users immediately change their passwords and notify the ISO if they suspect their passwords have been compromised.
  • Configure IT systems to maintain at least the last 9 passwords used in the password history files to prevent the reuse of the same or similar passwords commensurate with the level of data sensitivity of those systems.
  • Provide a unique initial password for each new account of sensitive IT systems and require that the IT system user changes the initial password upon the first login attempt.
  • Implement procedures to handle lost or compromised passwords and/or tokens.
  • Set an account lockout threshold of not greater than 10 invalid attempts and the lockout duration for at least 15 minutes.
5.4.        Use of System Utilities

The use of utility programs that might be capable of overriding system and application controls must be restricted wherever possible to ensure that: 

5.4.1.    Utility program use is limited to perform authorized procedures and is limited to the minimum practical number individuals.

5.4.2.    System utilities are segregated from application software.

5.4.3.    Specific authorization procedures are enforced for ad hoc use of systems utilities.

5.4.4.    The availability of the system utilities are limited, e.g. for the duration of an authorized change.

5.4.5.    System utility usage is logged.

5.4.6.    All unnecessary software based utilities and system software is removed or disabled.

5.4.7.    Application of appropriate segregation of duties by individuals that are authorized to access system utilities.

5.5.        Session Time-out

A time out facility must be employed to protect inactive sessions from unauthorized access. 

  • Inactive sessions must time out after a defined period of inactivity that is reflective of the classification of the information that is being handled and associated regulatory requirements.
  • Implement a screen saver lockout period after a maximum of 15 minutes of inactivity for devices with access to sensitive systems.  Devices in less physically secure environments must have a lower time out interval.
5.6.        Limitation of Connection time

Connection time for applications and systems, commensurate with their level of data sensitivity, must be controlled by methods such as: 

  • Using predetermined time slots, e.g. for batch file transmissions, or regular interactive sessions of short duration;
  • Restricting connection times to normal office hours if there is no requirement for overtime or extended-hours operation and;
  • Re-authentication at timed intervals.

6.    Application and information access control

Access to an application and the information contained within must be restricted to authorized users.

6.1.   Information Access Restrictions 

Access to information and application system functions must be restricted in accordance with a defined access control policy through methods such as:

  • Providing customized menus to limit access to application functions;
  • Controlling the access rights of users, e.g. read, write, delete, and execute;
  • Controlling access rights of other applications and;
  • Ensuring that outputs from application systems handling sensitive information contain only the information relevant to the use of the output and are sent only to authorized terminals and locations.

6.1.1.    Data classification must be taken into account when providing access to information to ensure compliance with documented legal and/or business reasons.

6.1.2     All sensitive data in transit must be protected from unauthorized disclosure, for example, by using encryption. When encryption is used, the minimum standard is 3DES, 128 bit SSL or AES.

6.1.3.    Data classified as high sensitivity must be protected while at rest (within a data store) through methods such as access controls, encryption, masking, and tokenization.

6.1.4.    Information, commensurate with its level of data sensitivity, must not be stored in hidden fields that are part of the application interface.

6.1.5    Privileged account access must have stronger credentialing and require stronger user authentication than non-privileged accounts.

6.1.6    All applications must be monitored for malicious or suspicious activity and follow documented published procedures for reporting and escalation of incidents. Refer to the Enterprise IT Security Incident Response Policy & Procedures for more information.

6.2.        Sensitive System Isolation

Sensitivity of an application system must be explicitly identified and documented by the application owner.  Systems must have a computing environment that is adequately isolated and protected from intrusions and disruptions originating from other computing environments commensurate with the sensitivity classification of the system through the:

  • Use of dedicated computing environments;
  • Use of shared resources limited to trusted application systems with comparable regulatory requirements, sensitivity and data classification.
    • Application systems that run in a shared environment must be evaluated for exposed risk to both the business owner as well as to the other occupants of the shared environment.
    • When a sensitive application will use shared resources in a computing environment, the application systems with which it will share resources and the corresponding risks should be identified and accepted by the owner of the sensitive application.
    • All occupants of a shared environment must be explicitly informed and must accept known risks based on the sensitivity of the application systems within the shared environment.

 

6.2.1.      Application code must never run from a system level account with unlimited privileges such as “root” or “administrator.”

6.2.2.      Application system code must never run from or operate out of the same directory storage location as the host operating system.

6.2.3.      Presentation/application tiers must be segregated from data stores.

6.2.4.      Internal data stores must be segregated and protected from un-trusted endpoint access. One method of accomplishing this separation is through the use of controlled network environments.

6.2.5.      If an application system fails, the system must fail securely by at minimum terminating all client sessions, preventing new connections, and recording incomplete transactions.

6.2.6.      All systems must be hardened in order to mitigate against known exploits and/or unauthorized access through the use of a combination of tools, e.g., vendor hardening guides, templates, scripts, other inherent tools/resources.

6.2.7.      All systems and applications must be maintained and follow the recommended remediation advice per relevant vendor alerts as appropriate to their environment.

6.2.8.      At a minimum access and event logging must be available for regular reviews.  Recommended best practice is real-time monitoring.

6.2.9.      No systems or databases containing sensitive information will be directly accessible from an untrusted network or system.

6.2.10.   If the application communicates with an ITD-managed host, addresses must be registered with ITD.

6.2.11.   DMZ servers cannot be both the sender and recipient of the same port unless the service is passed through a dedicated protocol level gateway.

6.3.        Logging & Monitoring


Application systems must employ logging & monitoring using the following measures:

6.3.1.      At a minimum, access and event logging must be available for regular reviews as required to meet regulatory requirements and security objectives.  Recommended best practice is daily review and real-time monitoring.

6.3.2.      System logs should be forwarded and stored on a dedicated log server.

6.3.3.      Any issues identified during reviews of logs must be addressed in a timely manner and in compliance with the Enterprise Incident Response Policy .

6.3.4.      File integrity and system configurations must be monitored for unauthorized changes. These files include, but are not limited to critical system files, configuration files, program files, binaries for operating system kernel files, etc.

6.3.5.      Operating system and anti-malware updates must be monitored for validation that the system updates are occurring and up to date.

6.4.   Deployment and Maintenance

Application systems must be securely deployed and maintained by the following measures:

6.4.1.      Production, QA and development environments must be segregated based upon functional boundaries. 

6.4.2.      Production, QA and Development environments must each be isolated from MAGNet.

6.4.3.      Application systems must protect against common vulnerabilities and threats including but not limited to:

    • SQL Injection
    • Cross-Site Scripting
    • Command Injection
    • Cookie/Session Poisoning
    • Buffer Overflow Exploits
    • Parameter/Form Tampering/Hidden Field Manipulation
    • Forceful Browsing
    • Error Message Interception
    • Server configuration errors or exposure
    • Aged patching levels
    • Application back doors
    • Web Site Defacement

6.4.4.      All application systems must be deployed from trusted networks.

6.4.5.      Physical security must be adequate to satisfy the security and control objectives of the application system.

6.4.6.      User activity must be regularly logged and audited by the application owner on an ongoing basis for abuses, incorrect role assignments, and other unexpected activity.

6.4.7       Vulnerabilities must be promptly addressed when identified in applications or their environments

6.5.        Application/Sub-Systems/Middleware

Applications deployed using containers that provide execution environments distinct from the underlying operating system, must employ controlled access to configuration and management functions provided by such environments.  (Examples of such environments include Java EE containers and database stored procedure platforms.)

Where such containers are used, effective procedures and controls must be in place to ensure that:

6.5.1.      Access to configuration and management functions is subject to authentication of strength commensurate with the sensitivity of the application(s) and data accessible by authenticated users;

6.5.2.      Use of configuration and management functions is limited to authenticated individuals authorized to perform such functions related to the specific container;

6.5.3.      Use of configuration and management functions is limited to those functions needed for the deployment, configuration and execution of applications deployed to the container;

6.5.4.      Use of configuration and management functions is logged, together with the User ID that uniquely identifies the user  performing the function and such logs are routinely reviewed to detect breaches; and

6.5.5       Unnecessary management functions provided by the container are removed or disabled.

7.    Mobile computing and teleworking

Mobile computing and teleworking environments and associated devices must be considered untrusted due to the inability of an organization to impose physical and logical security controls on the environment equal to those imposed within the organization’s facilities.  Therefore adequate security measures must be adopted to protect against the additional risks associated within those environments

7.1.         Mobile computing and communications  

Commonwealth entities must have a formal mobile computing and communications control policy.  The policy should provide clear direction for the logical and physical access controls.  To comply with this requirement, the policy must address the following:

  • Acceptable devices and usage
  • User responsibilities
  • Device Controls including:
    • Authentication (Logon)
    • Authorization
    • Cryptographic techniques
    • Back-ups
    • Malware protection
    • Mobile device management
  •   Rules on connecting mobile devices to networks.

Security measures must be adopted that:

  • Ensure connection of acceptable devices
  • Require users to sign statement of acceptance of their responsibilities
  • Prevents unauthorized use of a device
  • Prevents unauthorized access to a network
  • Prevents data loss
  • Prevents data leakage
  • Provides malware protection
  • Address device loss (e.g. device wipe, geo location services).
7.1.1.      Untrusted Remote Access Networks
Wireless and wired mobile communications are vulnerable and must be treated like untrusted remote access networks rather than members of an internal (i.e., MAGNet) trusted network.
Commonwealth entities must ensure that wireless users cannot bridge wired and wireless LANs. All remote access into MAGNet must be controlled through an ITD-managed firewall.
7.1.2.      Wireless auditing must be performed on a regular basis to protect against rogue/unauthorized networks and devices on MAGNet.
7.1.3.      Monitor Network Security

            Wireless network traffic and devices must be managed and monitored. Intrusion detection/prevention capability is recommended.

7.1.4.      Authentication & Encryption

          Authentication strength levels to validate user identity must be commensurate with the classification of the system and associated information being accessed.

          Entities must be aware that outward facing applications (e.g., customer and vendor programs) may be running across insecure wireless networks at the customer or vendor site. Entities must design such applications to enforce data security through encryption at the application level (for example, SSL 128-bit encryption within browser for e-mail, or SSL web interface to customer facing systems). All such mobile applications must support Internet browsers with a minimum encryption level of 128-bit (SSL).

            Use strong passwords (as defined in section 5.3 on Password Management in this standard) where technically feasible.

7.1.5.      Network Segment Isolation

            Unauthenticated public access is not allowed on the Commonwealth LAN or MAGNet network. Any LAN that allows unauthenticated access must be separated from the LAN/MAGNet and treated as a separate DMZ external to the secure network.

            The network access standards defined in Section 4 must be adhered to in order to access LAN/MAGNet resources.

7.1.6.      Least Privilege Applied

All remote access points must be able to restrict device and user access to only those resources for which they are explicitly authorized to access (e.g., by firewall rules and application controls).

All Vendor, Business Partner, and Contractor device access must be restricted to accessing only the resource(s) of the Commonwealth entity with whom they are contractually engaged.  The contractual obligation must include an agreement to adhere to this limitation and to all applicable Commonwealth Policies and Standards relevant to their access (e.g., “Acceptable Use” policies).

7.1.7. Local Caching, Storing and Printing

Users must not store data classified as having high sensitivity on remote devices unless encrypted and explicitly allowed.  Entities must address this risk, in compliance with the Commonwealth’s enterprise security policies and relevant data confidentiality acts such as Executive Order 504, HIPAA, PCI, FIPA, or FERPA, based on the type of data involved.

7.1.8.      Registration and Management of Devices

Entities must require registration of each wireless device prior to the device being admitted and/or connected to the entity’s LAN.   Serial numbers, phone numbers, FCC ID, IP address, MAC address, etc., as appropriate and obtainable for each wireless communications device, must be recorded. This information must be made available to ITD Technology Office upon request.

Where technically possible, security mechanisms on mobile devices must be used. These include encryption, remote tracking of the device for physical recovery, remote wipe and/or hard drive destruction, password or biometric protection, and automatic wipe after a predetermined number of failed password attempts.   Mobile device management must be configured at a minimum to:

  • Set granular policies for passwords, applications, Web interfaces, data cards, WIFI, bluetooth and enforce device encryption.
  • Locate devices including current location.
  • Lock a lost device and assign a device password.
  • Enforce application white-listing and black-listing.
  • Isolate devices that violate policy and disable network connectivity.
  • Remotely reset device password.
  • Wipe (delete) data from device.
  • Alert of potential risk and issues via email and/or notifications via management console.
7.1.9.      Protection of Connected Devices

Any mobile device or computer subject to network connection controls must be configured at a minimum with: up-to-date malware protection including antivirus, spyware detection and removal tools, personal firewall, manufacturer supported operating system with current updates, if available for the device and agency supported remote access software as prerequisites for network connectivity including remote access to Commonwealth IT systems.

  • Information stored on portable devices must be protected in a way commensurate with the classification of the information.  Protection of mobile devices must have power-on authentication for device access – either a strong password (as defined in section 5.3 on Password Management in this standard) where technically feasible, or four digit PIN (personal identification number), or equivalent, such as a biometric (fingerprint scanner), voice recognition, etc. This first tier authentication helps to protect any data physically stored on the device.
  • In order to access LAN/MAGNet resources, devices must utilize an ITD-approved VPN solution (e.g., SSL and IPSEC) to protect transmissions end-to-end and must use two factor authentication, e.g. certificate and password; secureID card and password, etc.).
  • Any browser-enabled devices must use, at minimum, SSL 128 bit encryption technologies.
7.1.10.   Ownership of Connected Devices

Communications devices used in mobile computing and teleworking that access MAGNet must either be owned by the Commonwealth or explicitly authorized by the Secretariat CIO or equivalent position for non-Executive Branch Commonwealth entities.

Entities that choose to allow employees to connect personally owned portable devices (smartphones, tablets, etc.) to agency owned equipment must provide an exception and approval process by which the entity grants and documents approval to attach the device.

  • Personal devices must NOT be used for direct system administration of Commonwealth systems.
  • Entities that allow personal devices to be used must treat those personal devices as untrusted and subject to, at a minimum, all requirements applied to Commonwealth owned devices. 
  • Additional requirements/restrictions should be considered and applied to the use of personal devices (e.g., restricting access to browser-based/virtual desktop-based access, restricting access to non-sensitive applications and data only).
  • Any device used to access Commonwealth resources must be an approved device as deemed by the Commonwealth CTO and the Secretariat CIOs in conjunction with ITD Executive staff.  At a minimum, the SCIO, or their designee, is required to approve each individual device’s connection to the network.
7.1.11.   User Agreement

Commonwealth entities retain, and when reasonable and in pursuit of legitimate needs for supervision, control, and securing the environment,  will exercise the right to inspect any user's computer or device (tablet, smartphone, etc.) device that is used to connect to Commonwealth resources, any data contained in it, and any data sent or received by the device, insofar as such data is related to the user’s work with respect to the Commonwealth or the security of Commonwealth IT resources.  Use of Commonwealth resources (network and systems) constitutes express consent for the entity to monitor and/or inspect any data that users create or receive, any messages they send or receive, and any web sites that they access, insofar as such data, messages, or access relate to the user’s work with respect to the Commonwealth or the security of Commonwealth IT resources

All users of wireless mobile communications devices to connect to Commonwealth resources must complete and sign a user agreement that includes:

  • Acceptance and acknowledgement that the Commonwealth entity and ITD may scan/monitor mobile devices and their communications during connections to the wireless LAN/MAGNet and resources.
  • Stating the names of the individuals who can use the device.
7.2.   Teleworking

Commonwealth entities must have a formal teleworking policy that is in alignment with the Commonwealth Human Resource Division Telecommuting Policy.  The policy should provide a clear direction for authorization of teleworking activities based upon appropriate security measures and controls in effect that comply with enterprise policy and access standards.  To comply with this requirement, the policy must address the following:

  • Physical security of teleworking environment;
  • Communication security requirements with consideration for remote access to internal systems,  the sensitivity of the data being accessed;
  • Threat of unauthorized access by persons who use the same environment, e.g. friends and family;
  • Security controls required when using home networks;
  • Applicability of policies and procedures of the organization and the Enterprise within the teleworking environment;
  • Availability of Commonwealth owned devices or equipment for teleworking purposes;
  • Software licensing agreements that may potentially cause organizations to become liable for licensing of client software on workstations owned privately by teleworking users;
  • Maintenance of anti-malware protection and firewall requirements;
  • Formal policies that define work permitted, hours of work, classification of information that may held and internal systems and services that the teleworker is authorized to access;
  • Provisions for insurance of equipment or teleworking environment;
  • Revocation of authority and access rights including return of equipment upon termination of teleworking activities.

 

 


Related Documents

Enterprise Access Control Policy

OWASP: The Ten Most Critical Web Application Security Vulnerabilities 

OWASP: A Guide to Building Secure Web Applications and Web Services


Contact

Standards@state.ma.us

 


Terms

Key terms used in this policy have been provided below for your convenience.  For a full list of terms please refer to the Information Technology Division’s web site where a full glossary of Commonwealth Specific Terms is maintained.

Controlled Networks: Are physically or operationally controlled and security managed by a specific Commonwealth entity. Controls include physical, operating system, application, and patch security.

Uncontrolled Networks: Are not physically or operationally controlled by a specific Commonwealth entity. Examples include the Internet, or networks behind firewalls that connect to partners and are not directly managed by a State agency. Uncontrolled networks may also be referred to as “Untrusted networks”.

DMZ: Also referred to as a ‘Demilitarized Zone’, is a combination of computers, routers, and software that separates Controlled networks from Uncontrolled networks. Specific policies or rules govern the types of traffic allowed between DMZs and Controlled/Uncontrolled networks, and, likewise, traffic originating from or terminating in DMZ networks. Located at the edge of a controlled network, these zones are tightly restricted, all systems are security hardened, and trust relationships between systems and services always originate or terminate in these zones.  Port/Protocol communications between DMZs may be controlled through the use of a TCP/IP firewall that meets Common Criteria EAL4 certification at the discretion of the agency network security administrator. 

Common Criteria: defines a set of IT requirements of known validity which can be used in establishing security requirements for prospective products and systems. For more information, go to http://www.commoncriteriaportal.org/.

 


Appendix: Device Baseline Requirements

Firewalls:

All port connections must traverse a Common Criteria EAL4 certified firewall.  Internal name space must be protected from all external access. 

XML Aware Device:

Use of XML-aware device for web services that can perform schema validation, message authentication and encryption based on open standards, XDoS (XML Denial-of-Service) attacks, and buffer overrun checks


Document History

DateAction

Effective Date

Next Review Date
05/14/2012Ref #11.4.2 Enterprise Access Control Policy published05/14/201204/30/2013
    
    
    

 

 



[1] The Executive Department is comprised of the Executive Branch minus the Constitutional Offices, i.e., the State Auditor, State Treasurer, the Attorney General, and the Secretary of the Commonwealth.