Policies index

• Acceptable Use Policy
• Abuse Policy
• CVD Policy
• Peering Policy
• Workstation security
• Clean desk
• E-mail
• Password
• Encryption keys
• Information logging
• Server security
• Database credentials
• Storage equipment disposal
• Remote access
• Router and switch security
• Social engineering awareness

Acceptable Use Policy

VERSION 2014-01-01

Through this document Tuxis Internet Engineering (hereinafter Tuxis) means to point out the responsibilities accompanying Tuxis’s services to clients and users of Tuxis’s services (hereinafter user[s]). When provisions of this Acceptable Use Policy are violated, Tuxis can take measures, as defined in the Abuse Policy, to counter the continuation or repetition of the offence.

Purpose
The objectives of the Acceptable Use Policy include:

• offering users safe and reliable internet services.
• contributing to the open nature of the internet and the value of the internet as a platform for freedom of speech.
• promoting the responsible use of the internet and counteracting practices that negatively affect the value of the internet.
• protection of the rights, privacy and (internet) security of individuals and organizations.
• indicating the rights and obligations, in addition to statutory rights and obligations, Tuxis provides users with.

Rules of Conduct

• The starting point is that users behave as proper and careful internet users and do not cause any inconvenience to the other users and/or networks on the internet.
• The user shall follow reasonably formulated instructions from Tuxis regarding the offered internet services
• The user shall refrain from transmitting any material through or posting any material, of any form, on the internet, which can be regarded as illegal, unlawful, threatening, discriminatory, libellous, encouraging or triggering conducts that can be considered criminal, which could give civil liability to, or could otherwise result in a conflict with the Dutch law or international laws and regulations.
• The user will do everything reasonably possible to prevent a computer virus or other malicious program from being posted on or transmitted through the internet or Tuxis’s infrastructure.
• The user will do everything reasonably possible to only connect systems with adequate security to the internet.
• Tuxis is extremely careful with their users’ confidential information (including passwords) and expect the same degree of care from its users.
• The users will inform Tuxis as soon as possible if any confidential data from or provided by Tuxis has come into the hands of unauthorized parties, or in case of suspicion thereof.
• The user will inform Tuxis as soon as possible when unauthorized parties have had access to the services, or in case of suspicion thereof.

Abuse
The user shall refrain from any attempt, in any way whatsoever, to:

• invade third-party systems or using third-party accounts without authorization.
• gain access to data not intended for the user.
• carry out any denial of service attacks.
• intercept or manipulate third-party network traffic without consent.
• send spam.
• manipulate electronic messages (including email headers).

Revision
Tuxis reserves the right to revise this Acceptable Use Policy unilaterally in accordance with social and technological developments.

 

Abuse Policy

VERSION 2014-01-01

Through this document Tuxis B.V. (hereinafter Tuxis) wants to point out the consequences of violating the Acceptable Use Policy (AUP) to clients and users of Tuxis’s services (hereinafter user[s]). This document also describes how internet users can report a breach of the AUP at Tuxis.

For reports of AUP violations regarding unlawful and/or illegal content on the internet, Tuxis uses a separate Notice and Take Down (NTD) procedure, as described below. Below that, the procedure applicable to other types of AUP violations is stipulated.

Notice and Take Down
Tuxis uses a specific Notice and Take Down (NTD) procedure for reporting violations of the Acceptable Use Policy regarding unlawful and/or illegal content on the internet. This procedure is based on, and thus endorses, the 2008 NTD code of conduct. We distinguish between reports by companies and individuals on the one hand, and actions, interventions and request from/by (government) authorities on the other. We use the NTD procedure described here to handle reports. In case of actions and requests of authorities, we act solely on the basis of a strong, legal underpinning such as a judgment or order. 

Submitting reports
o The detector should first contact the content provider to come to an agreement.
o A report to Tuxis must contain the following information for it to be taken into consideration:

• indication that the report concerns an NTD request, detectors contact information
• description of the failed attempt to come to an agreement with the content provider
• the data Tuxis needs to assess the content, including at least the location of the illegal and/or criminal content (URL)
• a description of why the content is illegal and/or criminal according to the detector
• an explanation as to why Tuxis is approached as the most suitable agent to act
• an explicit indemnity against claims by the content provider as a result of taking measures for dealing with the report
• the report should be mailed to abuse@tuxis.nl
• the detector is responsible for a correct and complete notification

Handling reports
After Tuxis has received the NTD report, Tuxis will respond substantively within to working days of the notification and indicate which of the following options applies. Tuxis may decide to ask a third party to evaluate the content of the report in cases that exposure to the content is suspected to be harmful to Tuxis or the assessing employee. The personal data of the detector and content provider will not be provided to the third party in these cases. When providing information to the detector and/or content provider, the personal data of the detector or content provider will not be shared without permission. If either Tuxis or the third party finds that the report is:

• unmistakably illegal and/or undoubtedly punishable and Tuxis knows that an investigation is important for the content to be accessible, Tuxis will not proceed to make the content inaccessible. Tuxis will inform the detector of this.
• unmistakably illegal and/or undoubtedly punishable and there is an emergency that warrants no further delay, Tuxis will immediately proceed to disabling the access to the content when proportionally possible. Tuxis will inform the content provider and detector of this.
• unmistakably illegal and/or undoubtedly punishable, Tuxis will inform the content provider about the report and request to have the content made inaccessible within two working days. Tuxis will inform the detector of this. If the content provider:
  • has made the content inaccessible within two working days, Tuxis will inform the detector of this.
  • has not made the content inaccessible within two working days and informs Tuxis of an investigation requiring the content to remain accessible, Tuxis will not proceed to make the content inaccessible. Tuxis will inform the detector of this.
  • has not made the content inaccessible within two working days, Tuxis will do that when proportionally possible. Tuxis will inform the content provider and detector of this.
• not unmistakably illegal and/or undoubtedly punishable, Tuxis will inform the content provider of the report. Tuxis will inform the detector of this.

Other Abuse
Violations of the AUP other than unlawful and/or illegal content on the internet is subject to the following procedure.

Abuse with complaint

Submitting abuse complaints
A complaint is expected to contain the following information to be taken into consideration by Tuxis:

•    an indication that the report is an abuse complaint
•    the contact information of the detector
•    a description of the abuse
•    the data Tuxis requires to confirm the abuse, such as IP addresses, logs, etcetera

The abuse complaint should me emailed to abuse@tuxis.nl

Handling complaints
After Tuxis has received the abuse complaint, Tuxis will respond substantively within two working days. Tuxis gives as much cooperation as possible from the complaining party to be able to investigate the complaint as best as possible. No confidential information will be provided. If a complaint proves to be justified, Tuxis may decide to suspend a service to the causing party, until consultations between the affected user and a Tuxis employee have been concluded. In case this consultation does not result in a satisfactory solution for Tuxis, Tuxis may decide to discontinue the service to the user and terminate the contract with immediate effect. 

Abuse without complaint
When Tuxis registers conducts in conflict with the AUP, Tuxis may decide to suspend a service to the causing party, until consultations between the affected user and a Tuxis employee have been concluded. In case this consultation does not result in a satisfactory solution for Tuxis, Tuxis may decide to discontinue the service to the user and terminate the contract with immediate effect. 

Revision
Tuxis reserves the right to revise this Abuse Policy unilaterally in accordance with social and technological developments.

CVD Policy

The purpose of this Coordinated Vulnerability Disclosure policy (CVD) is to contribute to the security of our ICT systems and those of others by sharing knowledge about vulnerabilities. We will share the knowledge with one or more potentially vulnerable organisations in order to arrive at a joint solution for the vulnerability found in cooperation with the reporter. In order to limit or prevent damage as much as possible, it is important that the organizations affected have sufficient time to resolve vulnerabilities have sufficient time to resolve vulnerabilities or protect systems. Our starting point is the disclosure of knowledge about the vulnerabilities after they have been resolved.

For which vulnerabilities can you file a CVD report?

You can report vulnerabilities to us that pose a risk to the security of a system. Examples are vulnerabilities that make it possible to bypass a login form or gain unintended access to a database or storage with personal data.

Not every anomaly in a system is a vulnerability. In general, the following anomalies do not lead to an unsafe situation. We therefore kindly request that you do not submit a CVD report to us for the anomalies listed below:

• An anomaly that has no impact on the availability, integrity or confidentiality of information.
• The availability of WordPress xmlrpc.php and alike functionality when its misuse is limited to a so-called ping-back denial-of-service.
• The possibility of cross-site scripting on a static website or on a website on which no sensitive (user) information is processed.
• The availability of version information via, for instance, an info.php file. A possible exception to this is when the version information shows that the system uses software with known vulnerabilities.
• The absence of HTTP security headers as used by, for example, Cross-Origin Resource Sharing (CORS), unless this absence demonstrably leads to a security problem.

If you are unsure whether the anomaly you have found falls under one of the above exceptions, you can of course simply report it to us. We will then determine whether it is a vulnerability and take the appropriate follow-up actions.

How do you file a CVD report with us?

Send an e-mail to abuse[at]tuxis.nl with the title CVD report. In your report, describe as clearly as possible how the vulnerability can be reproduced, used or abused; this contributes to a rapid solution. Also, the IP address or the URL of the affected system and a description of the vulnerability is sufficient, but for more complex vulnerabilities more information may be required. We will contact you about this. Please use a valid e-mail address or telephone number so that we can contact you in case of questions. Communication via e-mail is preferred.

Make sure that:

• Report it as soon as possible after discovering the vulnerability.
• Do not share the information about the security problem with others until you hear from us whether it has been resolved.
• You use the knowledge of the security problem responsibly, for example, by not taking any action that goes beyond what is necessary to prove the security problem.

What should you not do?

Always avoid the following actions:

• Placing malware.
• Copying, changing or deleting data in a system.
• Making changes to the system.
• Repeatedly accessing the system or sharing access with others.
• Using brute force to gain access to a system.
• Using denial-of-service or social engineering.

Handling reports
After Tuxis has received the CVD report, Tuxis will respond substantively within two working days of the notification.

The fundamentals of our CVD policy

If you make the report according to the procedure, we have no reason to attach legal consequences for your report. We will treat your report as confidential and will not share personal data with third parties without your permission, unless required to do so by law or court order. Only with your permission will we mention your name as the discoverer of the reported vulnerability. We will send you a confirmation of receipt within one working day. We will respond to your report within three working days with an assessment of the report. We will keep you informed of the progress in resolving the issue. Tuxis aims to solve your reported security problem in a system within 60 days at the latest. After solving the problem, we will decide if and how it will be published. Tuxis offers a reward to thank you for your help. Depending on the seriousness of the security problem and the quality of the report, this reward can vary from a T-shirt to gift vouchers. It must be a serious security problem, as yet unknown to Tuxis.

Revision
Tuxis reserves the right to revise this CVD Policy unilaterally in accordance with social and technological developments.

Peering Policy

We will peer with anyone who wants us.
Peering on multiple locations and with all available routers is preferred.
Tuxis does not require MNDA’s or written peering agreements, but if your company does, we will be happy to sign them (if we agree to the content).
Tuxis prefers to setup peerings on both IPv4 and IPv6

For more information: https://www.peeringdb.com/asn/197731

---

Workstation Security Policy

Purpose

The purpose of this policy is to provide guidance for workstation security for Tuxis workstations in order to ensure the security of information on the workstation and information the workstation may have access to.

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 Tuxis issued 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 smart card, 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, smart cards, USB tokens, etc., will not be stored or left connected to any end user’s computer when not in use. For end users travelling 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.

---

Server Security Policy

 

Overview

Unsecured and vulnerable servers continue to be a major entry point for malicious threat actors. Consistent Server installation policies, ownership and configuration management are all about doing the basics well.

Purpose

The purpose of this policy is to establish standards for the base configuration of internal server equipment that is owned and/or operated by Tuxis. Effective implementation of this policy will minimize unauthorized access to Tuxis proprietary information and technology.

Scope

All employees, contractors, consultants, temporary and other workers at Tuxis and its subsidiaries must adhere to this policy. This policy applies to server equipment that is owned, operated, or leased by Tuxis

Policy

General Requirements

• Servers must be registered within the corporate management system. At a minimum, the following information is required to positively identify the point of contact:
• Server contact(s) and location, and a backup contact
• Hardware and Operating System/Version
• Main functions and applications, if applicable
• Information in the corporate management system must be kept up-to-date.
• For security, compliance, and maintenance purposes, authorized personnel may monitor and audit equipment, systems, processes, and network traffic.

Configuration Requirements

• Services and applications that will not be used must be disabled where practical.
• Access to services should be logged and/or protected through access-control methods such as a web application firewall, if possible.
• The most recent security patches must be installed on the system as soon as practical, the only exception being when immediate application would interfere with business requirements.
• Trust relationships between systems are a security risk, and their use should be avoided. Do not use a trust relationship when some other method of communication is sufficient.
• Always use standard security principles of least required access to perform a function. Do not use root when a non-privileged account will do.
• If a methodology for secure channel connection is available (i.e., technically feasible), privileged access must be performed over secure channels, (e.g., encrypted network connections using SSH or IPSec).
• Servers should be physically located in an access-controlled environment.
• Servers are specifically prohibited from operating from uncontrolled cubicle areas.

Monitoring

All security-related events on critical or sensitive systems must be logged and audit trails saved as follows:

• All security related logs will be kept online for a minimum of 1 week.
• Daily full backups will be retained for at least 7 days.
• Monthly full backups of logs will be retained for at least 1 month.

---

Database Credentials Coding Policy

 

Overview

Database authentication credentials are a necessary part of authorizing application to connect to internal databases. However, incorrect use, storage and transmission of such credentials could lead to compromise of very sensitive assets and be a springboard to wider compromise within the organization.

Purpose

This policy states the requirements for securely storing and retrieving database usernames and passwords (i.e., database credentials) for use by a program that will access a database running on one of Tuxis’s networks.
Software applications running on Tuxis’s networks may require access to one of the many internal database servers. In order to access these databases, a program must authenticate to the database by presenting acceptable credentials. If the credentials are improperly stored, the credentials may be compromised leading to a compromise of the database.

Scope

This policy is directed at all system implementer and/or software engineers who may be coding applications that will access a production database server on the Tuxis Network. This policy applies to all software (programs, modules, libraries or APIS that will access a Tuxis, multi-user production database. It is recommended that similar requirements be in place for non-production servers and lap environments since they don’t always use sanitized information.

Policy

General

In order to maintain the security of Tuxis’s internal databases, access by software programs must be granted only after authentication with credentials. The credentials used for this authentication must not reside in the main, executing body of the program’s source code in clear text. Database credentials must not be stored in a location that can be accessed through a web server.

Specific Requirements

Storage of Data Base User Names and Passwords

• Database user names and passwords may be stored in a file separate from the executing body of the program’s code. This file must not be world readable or writeable.
• Database credentials may reside on the database server. In this case, a hash function number identifying the credentials may be stored in the executing body of the program’s code.
• Database credentials may be stored as part of an authentication server (i.e., an entitlement directory), such as an LDAP server used for user authentication. Database authentication may occur on behalf of a program as part of the user authentication process at the authentication server. In this case, there is no need for programmatic use of database credentials.
• Passwords or pass phrases used to access a database must adhere to the Password Policy.

Retrieval of Database User Names and Passwords

• If stored in a file that is not source code, then database user names and passwords must be read from the file immediately prior to use. Immediately following database authentication, the memory containing the user name and password must be released or cleared.
• The scope into which you may store database credentials must be physically separated from the other areas of your code, e.g., the credentials must be in a separate source file. The file that contains the credentials must contain no other code but the credentials (i.e., the user name and password) and any functions, routines, or methods that will be used to access the credentials.
• For languages that execute from source code, the credentials’ source file must not reside in the same browseable or executable file directory tree in which the executing body of code resides.

Access to Database User Names and Passwords

• Every program or every collection of programs implementing a single business function must have unique database credentials. Sharing of credentials between programs is not allowed.
• Database passwords used by programs are system-level passwords as defined by the Password Policy.
• Developer groups must have a process in place to ensure that database passwords are controlled and changed in accordance with the Password Policy. This process must include a method for restricting knowledge of database passwords to a need-to-know basis.

---

Storage Equipment Disposal Policy

 

Overview

Storage equipment often contains parts which cannot simply be thrown away. Proper disposal of equipment is both environmentally responsible and often required by law. In addition, hard drives, USB drives, CD-ROMs and other storage media contain various kinds of Tuxis’s data, some of which is considered sensitive. In order to protect our constituent’s data, all storage mediums must be properly erased before being disposed of. However, simply deleting or even formatting data is not considered sufficient. When deleting files or formatting a device, data is marked for deletion, but is still accessible until being overwritten by a new file. Therefore, special tools must be used to securely erase data prior to equipment disposal.

Purpose

The purpose of this policy it to define the guidelines for the disposal of technology equipment and components owned by Tuxis

Scope

This policy applies to any storage devices that are no longer needed within Tuxis including, but not limited to the following: hard drives, tablets, smart phones, or handheld computers, compact and floppy discs, portable storage devices (i.e., USB drives and backup tapes.
All Tuxis employees and affiliates must comply with this policy.

Policy

Storage Equipment Disposal

• All storage mediums or devices with internal storage that have reached the end of their useful life should be securely erases in accordance with current industry best practices.
• All data including, all files and licensed software shall be removed from equipment using disk sanitizing software that cleans the media overwriting each and every disk sector of the machine with zero-filled blocks.
• Hard drives may also be removed and rendered unreadable (drilling, crushing or other demolition methods).

 

---

Remote Access Policy

 

Overview

Remote access to our corporate network is essential but in many cases this remote access originates from networks that may already be compromised or are at a significantly lower security posture than our corporate network. While these remote networks are beyond the control of Tuxis’s policy, we must mitigate these external risks the best of our ability.

Purpose

The purpose of this policy is to define rules and requirements for connecting to Tuxis’s network from any host. These rules and requirements are designed to minimize the potential exposure to Tuxis from damages which may result from unauthorized use of Tuxis resources. Damages include the loss of sensitive or company confidential data, intellectual property, damage to public image, damage to critical Tuxis internal systems, and fines or other financial liabilities incurred as a result of those losses.

Scope

This policy applies to all Tuxis employees, contractors, vendors and agents with a Tuxis-owned or personally-owned computer or workstation used to connect to the Tuxis network. This policy applies to remote access connections used to do work on behalf of Tuxis, including reading or sending email and viewing intranet web resources. This policy covers any and all technical implementations of remote access used to connect to Tuxis networks.

Policy

• It is the responsibility of Tuxis’s employees, contractors, vendors and agents with remote access privileges to Tuxis’s corporate network to ensure that their remote access connection is given the same consideration as the user’s on-site connection to Tuxis
• When accessing the Tuxis network from a personal computer, Authorized Users are responsible for preventing access to any Tuxis computer resources or data by non-Authorized Users. Performance of illegal activities through the Tuxis network by any user (Authorized or otherwise) is prohibited. The Authorized User bears responsibility for and consequences of misuse of the Authorized User’s access.
• Authorized Users will not use Tuxis networks to access the Internet for outside business interests.

Requirements

• Secure remote access must be strictly controlled with encryption (i.e., Virtual Private Networks (VPNs)) and strong pass-phrases.
• Authorized Users shall protect their login and password from anyone.
• While using a Tuxis-owned computer to remotely connect to Tuxis’s corporate network, Authorized Users shall ensure the remote host is not connected to any other network at the same time, with the exception of personal networks that are under their complete control or under the complete control of an Authorized User or Third Party.
• All hosts that are connected to Tuxis internal networks via remote access technologies must be kept upt-to-date.

 

---

Router and Switch Security Policy

 

Purpose

This document describes a required minimal security configuration for all routers and switches connecting to a production network or used in a production capacity at or on behalf of Tuxis.

Scope

All employees, contractors, consultants, temporary and other workers at Tuxis and its subsidiaries must adhere to this policy. All routers and switches connected to Tuxis production networks are affected.

Policy

Every router must meet the following configuration standards:

• The enable password on the router or switch must be kept in a secure encrypted form. The router or switch must have the enable password set to the current production router/switch password from the device’s support organization.
• The following services or features must be disabled:
  • IP directed broadcasts
  • Incoming packets at the router/switch sourced with invalid addresses such as RFC1918 addresses
  • TCP small services
  • UDP small services
  • All source routing and switching
  • All web services running on router
  • Telnet, FTP, and HTTP services
  • Auto-configuration
• The following services should be disabled unless a business justification is provided:
  • Discovery protocols
  • Dynamic trunking
  • Scripting environments, such as the TCL shell
• The following services must be configured:
  • Password-encryption
  • NTP configured to a corporate standard source
• Access control lists must be used to limit the source and type of traffic that can terminate on the device itself.
• Access control lists for transiting the device are to be added as business needs arise.
• The router must be included in the corporate enterprise management system with a designated point of contact.
• Telnet may never be used across any network to manage a router, unless there is a secure tunnel protecting the entire communication path. SSH version 2 is the preferred management protocol.
• The corporate router configuration standard will define the category of sensitive routing and switching devices, and require additional services or configuration on sensitive devices including:
  • IP access list accounting
  • Device logging
  • Incoming packets at the router sourced with invalid addresses, such as RFC1918 addresses, or those that could be used to spoof network traffic shall be dropped
  • Router console and modem access must be restricted by additional security controls

---

Social Engineering Awareness Policy

 

Overview

The Social Engineering Awareness Policy bundle is a collection of policies and guidelines for employees of Tuxis In order to protect Tuxis’s assets, all employees need to defend the integrity and confidentiality of Tuxis’s resources.

Purpose

This policy has the following purposes:

• To make employees aware that:
  • fraudulent social engineering attacks occur.
  • there are procedures that employees can use to detect attacks.
• Employees are made aware of techniques used for such attacks.
• Employees recognize they are an important part of Tuxis’s security. The integrity of an employee is the best line of defense for protecting sensitive information regarding Tuxis’s resources.
• To create specific procedures for employees to follow to help them make the best choice when:
  • Someone is contacting the employee – via phone, in person, email, fax or online – and elusively trying to collect Tuxis’s sensitive information.
  • The employee is being “socially pressured” or “socially encouraged or tricked” into sharing sensitive data.

Scope

Includes all employees of Tuxis, including temporary contractors or part-time employees participating with help desk customer service.

Policy

Sensitive information of Tuxis will not be shared with an unauthorized individual if he/she uses words and/ or techniques such as the following:

• An “urgent matter”
• A “forgotten password”
• A “computer virus emergency”
• Any form of intimidation from “higher level management”
• Any “name dropping” by the individual which gives the appearance that it is coming from legitimate and authorized personnel.
• The requester requires release of information that will reveal passwords, model, serial number, or brand or quantity of Tuxis resources.
• The techniques are used by an unknown (not promptly verifiable) individual via phone, email, online, fax, or in person.
• The techniques are used by a person that declares to be “affiliated” with Tuxis such as a sub-contractor.
• The techniques are used by an individual that says he/she is a reporter for a well-known press editor or TV or radio company.
• The requester is using ego and vanity seducing methods, for example, rewarding the front desk employee with compliments about his/her intelligence, capabilities, or making inappropriate greetings (coming from a stranger).