Select Page

Network Security Policy

{Company name as you’d like it to appear in your policy:6} Network Security Policy

Last Updated:{date_today:9}

Created By: {user_displayname:10}


Network Security Policy

The network of computing resources in use at {Company name as you’d like it to appear in your policy:6} is a critical asset, and therefore requires adequate protection, as outlined in this policy.

Key Takeaways

  • Networks and systems in use at {Company name as you’d like it to appear in your policy:6} must be designed and implemented with data security in mind.
  • Network access requires proper identification and authentication; additional controls may be required for certain highly privileged users or actions.
  • Wireless Access must be properly configured in accordance with acceptable encryption standards.

Overview, Purpose, and Scope

Effective security is a team effort, which means everybody at {Company name as you’d like it to appear in your policy:6} has a crucial role to play. The network of computing resources in use at {Company name as you’d like it to appear in your policy:6} is a critical asset, and therefore requires adequate protection.

This Network Security Policy applies to all networks used to generate, process, transmit, or retrieve data at {Company name as you’d like it to appear in your policy:6}.

Roles & Responsibilities

All networks in use at {Company name as you’d like it to appear in your policy:6} must have adequate security controls and associated procedures. {Company name as you’d like it to appear in your policy:6} management is responsible for assigning appropriate personnel with relevant skills and authority to identify the security needs of networks in use, and implement the required safeguards.

{Company name as you’d like it to appear in your policy:6} management reviews and approves this policy, but if you identify an issue you should bring it to the attention of your manager.

Requirements

General Network Security

Network Security at {Company name as you’d like it to appear in your policy:6} requires a proactive approach to ensure the confidentiality, integrity, and availability of our data, systems, and networks. As such, there are several requirements for the design and maintenance of network.

Design & Architecture

Network design should follow an approach of compartmentalization, whereby high risk networks, systems, and data are logically segregated from lower-risk assets. This may be achieved through the use of VLANs, strict traffic/data flow rules implemented via firewalls, or entirely segregated systems (e.g. a cloud-hosted production system isolated from an internally-hosted test environment. Higher risk assets must receive greater priority when security controls are put in place, including additional logging, monitoring, and redundant capacity.

All network design decisions must be documented in a network diagram. This diagram and all components in the network should be subject to adequate change management procedures to ensure all changes are thoroughly reviewed and tested. Once changes are completed, the diagram must be updated to document the current state.

For any network devices or elements which are not directly controlled by {Company name as you’d like it to appear in your policy:6}, adequate support contracts should be in place with the manufacturer or other authorized support agency.

Monitoring and Logging

{Company name as you’d like it to appear in your policy:6}’s networks and systems must have monitoring and logging capabilities commensurate with the data they store, transmit, or process. The table below details the minimum requirements for each classification level (see Data Security Policy for definitions of the classification levels). A system’s classification level is the highest level of data stored, transmitted, or processed by that system.

Classification Level Should Have: Must Have:
Public

Edit 

Yes

– Inbound and Outbound Firewall – Denial of Service Protection(s)

– Basic identity logging and record of the action taken (e.g. IP Address)

Internal

Edit 

Yes

– Intrusion Detection/Prevention System (IDS/IPS)

– Data Loss Prevention (DLP)

All the above, as well as:

– Logging sufficient to uniquely identify an individual and the action taken (e.g. username)

– Inbound and Outbound Firewall

Restricted

Edit 

Yes

– DLP

– Security Incident and Event Management (SIEM) or a Managed Security Service for continuous monitoring

All the above, as well as:

– Routine review of logs, and logs must contain sufficient information to uniquely identify an individual and action taken

– IDS/IPS (alerting systems triggered by suspicious or unusual activity are acceptable)

Logging must be enabled for all devices which store, transmit, and/or process Restricted or Internal data; logging should be enabled for devices with Public data as well. This includes network devices.

Logs should be reviewed on a routine basis to identify any suspicious activity, which should be investigated according to the Incident Response Policy.

Logs must be retained for at least 90 days in easy to retrieve format, and then for a period of at least one (1) year in archives.

Audits and Testing

The security of {Company name as you’d like it to appear in your policy:6} networks must be reviewed on a routine basis. These reviews may include:

  • Audits: Internal reviews of configurations, settings, logs, and documentation to ensure the environment as it exists matches the secure design.
  • Internal Testing: testing by qualified personnel or appropriate tools to identify flaws, vulnerabilities, or misconfigurations. This may take the form of network scanning, vulnerability scanning, or penetration testing.
  • External Testing: similar to internal testing, but performed by a third party. This can be done to identify gaps or holes not obvious to internal employees, or to gain access to specialized skills at a security testing firm.

Network Access and Authentication

Accounts

Access to all {Company name as you’d like it to appear in your policy:6} resources must be done using a unique identifier where possible. This may be a username, ID badge, biometric measurement, etc.

Systems or circumstances which do not support unique ID should have compensating controls in place such as additional audit trails, e.g the use of a printer log to track users with hardcopy data.

Adequate account setup & termination procedures must exist, and most cover the following aspects of account management:

  • Formal request/approval must be made for account creation, privilege changes, and termination
  • Accounts must be granted only the minimum necessary set of privileges to enable employees to perform assigned job functions
  • Reviews of account privileges should be conducted {How often would you like to review account privileges?:17}, and any inappropriate access revoked in a timely manner
  • Accounts should be structured so that key business functions are separated, e.g. the same user is not able to enter and approve a sensitive transaction by herself

Authentication

All access to {Company name as you’d like it to appear in your policy:6} resources must require authentication of a user’s identity via one or more factors listed below. Access to highly sensitive resources (e.g. Restricted data) should require the use of multi-factor authentication:

  • Knowledge: a password, passphrase, answer to personal security questions, etc.
  • Possession: a one time use code, physical token (such as an RFID badge), etc.
  • Characteristic: biometric measurement such as hand geometry, fingerprint, voiceprint, typing pattern, etc.

Passwords in use on network devices must meet the criteria documented in the Acceptable Use Policy. Passwords in use at {Company name as you’d like it to appear in your policy:6} must be changed at least {How often would you like to review account privileges?:17} at a minimum, and changed immediately if there is a suspected compromise.

Access to data classified as Public is exempted from the requirement for user identification and authentication.

Privileged Accounts

Privileged accounts typically include administrator-level privileges, and may be assigned to network, server, and application support staff. Due to the elevated level of access granted to these accounts, one or more of the following additional security features must be used for such accounts:

  • Unique Admin Accounts: Administrators are granted a unique account to be used for their administrator duties. This may be an entirely separate user ID, or the use of privilege escalation such as sudo .
  • Additional Authentication Credentials: Administrative tasks require the use of additional authentication factors, such as a one time code or possession of an SSH cryptographic key.
  • Privileged Access Manager (PAM) : A PAM tool requires users to check out credentials when using them for assigned administrative functions. The tool provides additional accountability and oversight.

Session Locks/Timeout

Any {Company name as you’d like it to appear in your policy:6} system which requires user identification and authentication should support the locking or timing out a user’s session after a defined period of inactivity. Examples of session locks include:

  • Application level: the app logs the user out after 15 minutes of inactivity
  • Network level: a Network Access Control device disconnects the user after a defined period of inactivity, and requires reauthentication (e.g. the VPN disconnects and requires the user to reconnect)
  • Hardware level: a workstation enters a screensaver or power save mode which requires the user to reauthenticate in order to continue using the system

Systems or network connections processing highly sensitive data may also require re-authentication after a defined period regardless of user activity, e.g. a VPN may require the user to reauthenticate once every 24 hours even if the user is still active.

Suspicious Activity

All {Company name as you’d like it to appear in your policy:6} systems and networks which require the use of unique user accounts and authentication must provide the ability to generate an audit trail of user activity. This audit trail must be examined for suspicious activity on a routine basis.

Systems and networks must provide adequate protection against brute force attacks, such as guessing username and password combinations. Protections against such attacks may include investigation of any alerts generated when multiple failed logins are detected, or countermeasures such as account lockouts or time-delayed retries for user credentials.

If appropriate, monitoring should be employed to detect and generate alerts when unauthorized access attempts are made to systems, network, or data. Installation or execution of unauthorized software should also be monitored and investigated. Such monitoring should be performed based on the criticality of information stored or processed by a system.

Remote Access and VPN

{Company name as you’d like it to appear in your policy:6} may choose to provide remote access to its systems and networks; any such access must be adequately protected. Services which provide secure connectivity regardless of location are the preferred method for secure remote access, e.g. the use of a web application that uses HTTPS to secure traffic is preferable to an app that does not use encryption and requires additional controls to achieve security.

Remote access procedures must include provisions for any additional security considerations which may be required, such as:

  • Use of {Company name as you’d like it to appear in your policy:6}-managed and -approved solutions: Employees should be restricted from using personally-owned or unapproved devices for remote access
  • Network Segmentation: Remote connections may be segregated and more tightly controlled through the use of VLANs, firewall blocks, etc.
  • Monitoring: Traffic originating from remote users may be monitored with additional tool such as Intrusion Detection Systems (IDS) or proxies for suspicious activity, and may be subject to increased levels of logging.

VPN solutions in use at {Company name as you’d like it to appear in your policy:6} must meet the encryption requirements set out in the Data Security Policy. VPN connectivity should require the use of multi-factor authentication.

Vulnerability Scanning and Management

Systems and networks in use at {Company name as you’d like it to appear in your policy:6} should undergo vulnerability assessment on a routine basis. The scope of such scanning should include any system processing or storing information classified as Internal or Restricted.

Any vulnerabilities identified during scanning should be resolved within 90 days of being reported. Coverage and frequency of vulnerability scans, as well as disposition requirements for any findings from such scans, should be documented in vulnerability management procedures.

Guest Access

Guests who require access to {Company name as you’d like it to appear in your policy:6} systems and networks must follow all relevant Network Access and Authentication requirements, as well as our Acceptable Use Policy. Guest access may be granted to visitors, contractors, external maintenance/support personnel, and business partners of {Company name as you’d like it to appear in your policy:6}.

Due to the increased risk when guests access to our systems and networks, additional additional requirements for their accounts must be met where technically possible:

  • Limited access: Guest access should be granted only to the system(s) the guest requires, e.g. rather than granting a guest access to the entire network, a local account is created on the specific system the guest needs to access.
  • Time limits: Guest access should be set to expire at the end of the required period, rather than at the same time as normal accounts. For example, if a support engineer is accessing a system for one week, her access should only be valid for seven (7) days, rather than 90 days for internal users.
  • Guest Machines: Guest users should ideally use a {Company name as you’d like it to appear in your policy:6}-issued machine for access to our systems and networks. If this is not possible, compensating controls such as additional logging/monitoring, data loss prevention (such as preventing downloads or screen printing, etc.) should be employed.

Wireless Access

All wireless network access used at {Company name as you’d like it to appear in your policy:6} must meet the Encryption in Transit requirements laid out in the Data Security Policy. Wireless networks in use must meet the following requirements:

  • Use of WPA2: {Company name as you’d like it to appear in your policy:6} wireless networks must use WPA2 for security. WEP and WPA are not allowed.
  • Segregated Guest Access: Guests wireless access must be logically segregated from other traffic, ideally through the use of a separate wireless network.
  • Untrusted networks: Per the provisions of the Data Security Policy, adequate compensating controls must be in place when untrusted networks are used, such as {Company name as you’d like it to appear in your policy:6}-managed encryption.

Wireless network hardware should be deployed, configured, and maintained by {Company name as you’d like it to appear in your policy:6} personnel with appropriate skills to properly secure the network created. Such hardware should be part of standard patch and configuration management procedures to maintain adequate security.

Enforcement

Any exceptions to this policy must be approved by senior management in writing.

Any user found to have violated this policy will be subject to disciplinary actions, up to and including termination of employment.

You don't have credit card details available. You will be redirected to update payment method page. Click OK to continue.