Policies index:

• Workstation security
• Clean desk
• E-mail
• Password
• Encryption keys
• Information logging
• Server security
• Database credentials
• Storage equipment disposal
• Remote acces
• Router and switch security
• Social engineering awareness

Workstation Security Policy

Scope
This policy applies to all Tuxis’s employees, contractors, workforce members, vendors and agents with a Tuxis-owned or personal-workstation connected to the Tuxis office network.

Policy
Appropriate measures must be taken when using workstations to ensure the confidentiality, integrity and availability of sensitive information and that access to sensitive information is restricted to authorized users.

Workforce members using workstations shall consider the sensitivity of the information that may be accessed and minimize the possibility of unauthorized access.

Tuxis will implement physical and technical safeguards for all workstations that access sensitive information to restrict access to authorized users.
Appropriate measures include:

Restricting physical access to workstations to only authorized personnel.
Securing workstations (screen lock or logout) prior to leaving area to prevent unauthorized access.
Enabling a password-protected screen saver with a short timeout period to ensure that workstations that were left unsecured will be protected. The password must comply with the Tuxis Password Policy.
Ensuring workstations are used for authorized business purposes only.
Never installing unauthorized software on workstations.

Never store sensitive information on workstation unencrypted.

Ensuring workstations are left on but locked or logged off in order to facilitate after-hours updates.

Exit running applications and close open documents

Clean Desk Policy

Overview
A clean desk policy is an important tool to ensure that all sensitive/confidential materials are removed from an end user workspace and locked away when the items are not in use or an employee leaves his/her workstation. It is one of the top strategies to utilize when trying to reduce the risk of security breaches in the workplace. Such a policy can also increase employee’s awareness about protecting sensitive information.

Purpose
The purpose for this policy is to establish the minimum requirements for maintaining a “clean desk” – where sensitive/critical information about our employees, our intellectual property, our customers and our vendors is secure in locked areas and out of sight. A Clean Desk policy is part of standard basic privacy controls.

Scope
This policy applies to all Tuxis’s employees and affiliates.

Policy
Employees are required to ensure that all sensitive/confidential information in hardcopy or electronic form is secure in their work area at the end of the day and when they are expected to be gone for an extended period.
Any Restricted or Sensitive information must be removed from the desk and locked in a drawer when the desk is unoccupied and at the end of the work day.
Keys used for access to Restricted or Sensitive information must not be left at an unattended desk.
Passwords may not be written down.
Printouts containing Restricted or Sensitive information should be immediately removed from the printer.
Upon disposal Restricted and/or Sensitive documents should be shredded in the official shredder bins or placed in the lock confidential disposal bins.
Whiteboards containing Restricted and/or Sensitive information should be erased.
All printers and fax machines should be cleared of papers as soon as they are printed; this helps ensure that sensitive documents are not left in printer trays for the wrong person to pick up.

E-mail policy

Overview

Electronic email is pervasively used in almost all industry verticals and is often the primary communication and awareness method within an organization. At the same time, misuse of email can post many legal, privacy and security risks, thus it’s important for users to understand the appropriate use of electronic communications.

Purpose
The purpose of this email policy is to ensure the proper use of Tuxis email system and make users aware of what Tuxis deems as acceptable and unacceptable use of its email system. This policy outlines the minimum requirements for use of email within Tuxis Network.

Scope
This policy covers appropriate use of any email sent from a Tuxis email address and applies to all employees, vendors, and agents operating on behalf of Tuxis

Policy
All use of email must be consistent with Tuxis policies and procedures of ethical conduct, safety, compliance with applicable laws and proper business practices.
Tuxis email account should be used primarily for Tuxis business-related purposes; personal communication is permitted on a limited basis, but non-Tuxis related commercial uses are prohibited.
All sensitive data contained within an email message or an attachment must be secured according to the Data Protection Standard.
Users are prohibited from automatically forwarding Tuxis email to a third party email system.

Individual messages which are forwarded by the user must not contain Tuxis confidential or above information.
Users are prohibited from using third-party email systems and storage servers such as Google, Yahoo, and MSN Hotmail etc. to conduct Tuxis business, to create or memorialize any binding transactions, or to store or retain email on behalf of Tuxis
Tuxis employees shall have no expectation of privacy in anything they store, send or receive on the company’s email system.
Tuxis may monitor messages without prior notice. Tuxis is not obliged to monitor email messages.

Password Policy

Overview
Passwords are an important aspect of computer security. A poorly chosen password may result in unauthorized access and/or exploitation of Tuxis’s resources. All users, including contractors and vendors with access to Tuxis systems, are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.

Purpose
The purpose of this policy is to establish a standard for creation of strong passwords and the protection of those passwords.

Scope
The scope of this policy includes all personnel who have or are responsible for an account (or any form of access that supports or requires a password) on any system that resides at any Tuxis facility, has access to the Tuxis network, or stores any non-public Tuxis information.

Policy
Password Protection
Passwords must not be shared with anyone. All passwords are to be treated as sensitive, Confidential Tuxis information.
Do not write passwords down and store them anywhere in your office.
When passwords are stored in a file on a computer system or mobile devices (phone, tablet) it must have an AES 256 bits encryption or better.

The “Remember Password” feature of applications (for example, web browsers) must be protected with a master password. The application must encrypt the stored passwords.

Any user suspecting that his/her password may have been compromised must report the incident and change all passwords.

Password Creation

All user-level and system-level passwords must conform to the Password Construction Guidelines.
Users must not use the same password for Tuxis accounts as for other non-Tuxis access (for example, personal ISP account, option trading, benefits, and so on).
Where possible, users must not use the same password for various Tuxis access needs.

All passwords should meet or exceed the following guidelines:

Contain at least 12 alphanumeric characters.

Contain both upper and lower case letters.

Contain at least one number (for example, 0-9).

Contain at least one special character (for example,!$%^&*()_+|~-=\\`{}[]:”;'<>?,/).

Cannot be found in a dictionary, including foreign language, or exist in a language slang, dialect, or jargon.

Must not contain personal information such as birthdates, addresses, phone numbers, or names of family members, pets, friends, and fantasy characters.

Must not contain work-related information such as building names, system commands, sites, companies, hardware, or software.

Must not contain number patterns such as aaabbb, qwerty, zyxwvuts, or 123321.

Must not contain common words spelled backward, or preceded or followed by a number (for example, terces, secret1 or 1secret).

May not be some version of “Welcome123” “Password123” “Changeme123”

End User Encryption Key Protection Policy

Overview
Encryption Key Management, if not done properly, can lead to compromise and disclosure of private keys use to secure sensitive data and hence, compromise of the data. While users may understand it’s important to encryption certain documents and electronic communications, they may not be familiar with minimum standards for protection encryption keys.

Purpose
This policy outlines the requirements for protecting encryption keys that are under the control of end users. These requirements are designed to prevent unauthorized disclosure and subsequent fraudulent use. The protection methods outlined will include operational and technical controls, such as key backup procedures, encryption under a separate key and use of tamper-resistant hardware.

Scope
This policy applies to any encryption keys listed below and to the person responsible for any encryption key listed below. The encryption keys covered by this policy are:

encryption keys issued by Tuxis
encryption keys used for Tuxis business
encryption keys used to protect data owned by Tuxis.

The public keys contained in digital certificates are specifically exempted from this policy.

Policy
All encryption keys covered by this policy must be protected to prevent their unauthorized disclosure and subsequent fraudulent use.

Secret Key Encryption Keys

Keys used for secret key encryption, also called symmetric cryptography, must be protected as they are distributed to all parties that will use them. During distribution, the symmetric encryption keys must be encrypted using a stronger algorithm with a key of the longest key length for that algorithm authorized in Tuxis’s Acceptable Encryption Policy.

Symmetric encryption keys, when at rest, must be protected with security measures at least as stringent as the measures used for distribution of that key.

Public Key Encryption Keys

Public key cryptography, or asymmetric cryptography, uses public-private key pairs. The public key is passed to the certificate authority to be included in the digital certificate issued to the end user. The digital certificate is available to everyone once it issued. The private key should only be available to the end user to whom the corresponding digital certificate is issued.

Tuxis’s Public Key Infrastructure (PKI) Keys
The public-private key pairs used by the Tuxis’s public key infrastructure (PKI) are generated on the tamper-resistant smart card issued to an individual end user. The private key associated with an end user’s identity certificate, which are only used for digital signatures, will never leave the smart card. This prevents the Infosec Team from escrowing any private keys associated with identity certificates. The private key associated with any encryption certificates, which are used to encrypt email and other documents, must be escrowed in compliance with Tuxis policies.

Access to the private keys stored on a Tuxisissued smart card will be protected by a personal identification number (PIN) known only to the individual to whom the smart card is issued. The smart card software will be configured to require entering the PIN prior to any private key contained on the smart card being accessed.

Other Public Key Encryption Keys
Other types of keys may be generated in software on the end user’s computer and can be stored as files on the hard drive or on a hardware token. If the public-private key pair is generated on smartcard, the requirements for protecting the private keys are the same as those for private keys associated with Tuxis’s PKI. If the keys are generated in software, the end user is required to create at least one backup of these keys and store any backup copies securely. The user is also required to create an escrow copy of any private keys used for encrypting data and deliver the escrow copy to the local Information Security representative for secure storage.

The Infosec Team shall not escrow any private keys associated with identity certificates. All backups, including escrow copies, shall be protected with a password or passphrase that is compliant with Tuxis Password Policy. Infosec representatives will store and protect the escrowed keys as described in the Tuxis Certificate Practice Statement Policy.

Commercial or Outside Organization Public Key Infrastructure (PKI) Keys
In working with business partners, the relationship may require the end users to use public-private key pairs that are generated in software on the end user’s computer. In these cases, the public-private key pairs are stored in files on the hard drive of the end user. The private keys are only protected by the strength of the password or passphrase chosen by the end user. For example, when an end user requests a digital certificate from a commercial PKI, such as VeriSign or Thawte, the end user’s web browser will generate the key pair and submit the public key as part of the certificate request to the CA. The private key remains in the browser’s certificate store where the only protection is the password on the browser’s certificate store. A web browser storing private keys will be configured to require the user to enter the certificate store password anytime a private key is accessed.

PGP Key Pairs
If the business partner requires the use of PGP, the public-private key pairs can be stored in the user’s key ring files on the computer hard drive or on a hardware token, for example, a USB drive or a smart card. Since the protection of the private keys is the passphrase on the secret keying, it is preferable that the public-private keys are stored on a hardware token. PGP will be configured to require entering the passphrase for every use of the private keys in the secret key ring.

Hardware Token Storage
Hardware tokens storing encryption keys will be treated as sensitive company equipment, as described in Tuxis’s Physical Security policy, when outside company offices. In addition, all hardware tokens, smartcards, USB tokens, etc., will not be stored or left connected to any end user’s computer when not in use. For end users traveling with hardware tokens, they will not be stored or carried in the same container or bag as any computer.

Personal Identification Numbers (PINs), Passwords and Passphrases
All PINs, passwords or passphrases used to protect encryption keys must meet complexity and length requirements described in Tuxis’s Password Policy.

Loss and Theft
The loss, theft, or potential unauthorized disclosure of any encryption key covered by this policy must be reported immediately to The Infosec Team. Infosec personnel will direct the end user in any actions that will be required regarding revocation of certificates or public-private key pairs.

Information Logging Standard

Overview

Logging from critical systems, applications and services can provide key information and potential indicators of compromise. Although logging information may not be viewed on a daily basis, it is critical to have from a forensics standpoint.

Purpose

The purpose of this document attempts to address this issue by identifying specific requirements that information systems must meet in order to generate appropriate audit logs and integrate with an enterprise’s log management function.

The intention is that this language can easily be adapted for use in enterprise IT security policies and standards, and also in enterprise procurement standards and RFP templates. In this way, organizations can ensure that new IT systems, whether developed in-house or procured, support necessary audit logging and log management functions.

Scope

This policy applies to all production systems on Tuxis Network.

Standard

General Requirements

All systems that handle confidential information, accept network connections, or make access control (authentication and authorization) decisions shall record and retain audit-logging information sufficient to answer the following questions:

What activity was performed?
Who or what performed the activity, including where or on what system the activity was performed from (subject)?
What the activity was performed on (object)?
When was the activity performed?
What tool(s) was the activity was performed with?
What was the status (such as success vs. failure), outcome, or result of the activity?
Activities to be Logged
Therefore, logs shall be created whenever any of the following activities are requested to be performed by the system:

Create, read, update, or delete confidential information, including confidential authentication information such as passwords;
Create, update, or delete information not covered in #1;
Accept a network connection;
User authentication and authorization for activities covered in #1 or #2 such as user login and logout;
System, network, or services configuration changes, including installation of software patches and updates, or other installed software changes;
Application process startup, shutdown, or restart;
Application process abort, failure, or abnormal end, especially due to resource exhaustion or reaching a resource limit or threshold (such as for CPU, memory, network connections, network bandwidth, disk space, or other resources), the failure of network services such as DHCP or DNS, or hardware fault; and
Detection of suspicious/malicious activity such as from an Intrusion Detection or Prevention System (IDS/IPS), anti-virus system, or anti-spyware system.
Elements of the Log
Such logs shall identify or contain at least the following elements, directly or indirectly. In this context, the term “indirectly” means unambiguously inferred.

Type of action – examples include authorize, create, read, update, delete, and accept network connection.
Subsystem performing the action – examples include process or transaction name, process or transaction identifier.
Identifiers (as many as available) for the subject requesting the action – examples include user name, computer name, IP address, and MAC address. Note that such identifiers should be standardized in order to facilitate log correlation.
Identifiers (as many as available) for the object the action was performed on – examples include file names accessed, unique identifiers of records accessed in a database, query parameters used to determine records accessed in a database, computer name, IP address, and MAC address. Note that such identifiers should be standardized in order to facilitate log correlation.
Before and after values when action involves updating a data element, if feasible.
Date and time the action was performed, including relevant time-zone information if not in Coordinated Universal Time.
Whether the action was allowed or denied by access-control mechanisms.
Description and/or reason-codes of why the action was denied by the access-control mechanism, if applicable.
Formatting and Storage
The system shall support the formatting and storage of audit logs in such a way as to ensure the integrity of the logs and to support enterprise-level analysis and reporting. Note that the construction of an actual enterprise-level log management mechanism is outside the scope of this document. Mechanisms known to support these goals include but are not limited to the following:

Microsoft Windows Event Logs collected by a centralized log management system;
Logs in a well-documented format sent via syslog, syslog-ng, or syslog-reliable network protocols to a centralized log management system;
Logs stored in an ANSI-SQL database that itself generates audit logs in compliance with the requirements of this document; and
Other open logging mechanisms supporting the above requirements including those based on CheckPoint OpSec, ArcSight CEF, and IDMEF.

Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.