Security Policy

Agiloft support staff have bent over backwards to help us solve problems, even when we caused them ourselves!

-Brian Pollock, DCG Systems



The Information Security department of Agiloft is responsible for defining, implementing, and enforcing security policy. The department coordinating other IT functions necessary for the smooth running and secure operation of company and client resources, as well as protection of data.

Risk Assessment Policy

1.0 Purpose

To empower Information Security to perform periodic information security risk assessments (RAs) for the purpose of determining areas of vulnerability, and to initiate appropriate remediation.

2.0 Scope

Risk assessments can be conducted on any entity within Agiloft or any outside entity that has signed a Third Party Agreement with Agiloft. RAs can be conducted on any information system, to include applications, servers, and networks, and any process or procedure by which these systems are administered and/or maintained.

3.0 Policy

The execution, development and implementation of remediation programs are the joint responsibility of Information Security and the department responsible for the systems area being assessed. Employees are expected to cooperate fully with any RA being conducted on systems for which they are held accountable. Employees are further expected to work with the Information Security Risk Assessment Team in the development of a remediation plan.

4.0 Risk Assessment Process

For additional information, go to the Risk Assessment Process.

5.0 Enforcement

Any employee found to have violated this policy is subject to disciplinary action, up to and including termination of employment.


Term Definitions

Entity – Any business unit, department, group, or third party, internal or external to Agiloft, responsible for maintaining Agiloft assets.

Risk – Those factors that could affect confidentiality, availability, and integrity of Agiloft’s key information assets and systems. Information Security is responsible for ensuring the integrity, confidentiality, and availability of critical information and computing assets, while minimizing the impact of security procedures and policies upon business productivity.

Secure Channel – Out-of-band console management or channels using strong encryption. Non-encrypted channels must use strong user authentication (one-time passwords).

Spam – Unauthorized and/or unsolicited electronic mass mailings.

Un-Trusted Network – Any network firewalled off from the corporate network to avoid impairment of production resources from irregular network traffic (lab networks), unauthorized access (partner networks, the Internet etc.), or anything else identified as a potential threat to those resources.

Third Party Testing

Because no code is changed in order to build or configure a custom solution, all applications built in Agiloft share the same core set of security characteristics. The software and hosting infrastructure is subject to regular review and testing by independent security analysts.

We no longer publish the most recent security audit results. Security best practices requires that the test details be redacted from the report before publication. Without this information they are not substantially useful. In addition, customers such as the U.S. Air Force (USAF) who review such documents often prefer to conduct their own tests.

We, therefore, lease dedicated servers on a weekly basis to customers who wish to test the application/infrastructure security. These servers are configured identically to the production servers. We cooperate fully with the customers’ choice of internal or third-party security firm and provide whatever information they need in order to execute a comprehensive security review. Incidentally, we passed the USAF audit and have passed all other external security audits to date.

Agiloft Application Policies

In addition to compliance with other policies, the Agiloft applications, and the servers dedicated to this function, have a number of features designed to enhance security and reliability. These features are detailed in this section.

Non-essential Ports Closed

All non-essential ports are closed. In particular, the database port is closed except to processes on the same machine and port 80 is closed.

Authentication and Integrity

Agiloft uses login names and passwords to authenticate users against a standard server such as LDAP or the internal user table. Unique IDs for each user are created to establish individual accountability. Authorization is controlled by highly granular group permissions that control access to table, record, and field levels. Accounts with extremely limited privileges can easily be created to support data input from untrusted users. Users communicate with the system using strong SSL encryption to ensure privacy. Login sessions are automatically expired and terminated after a period of inactivity.

Hyperlinks generated by Agiloft that include implicit authentication are secured by a public key encryption algorithm and have an expiration time embedded.

Audit trails are provided at the record and field level for changes to both the data and metadata. Integrity is maintained at both a physical level through a transactional database with foreign key integrity constraints and at the business/logical level through an active integrity manager.

Server Host Security

Hosted Agiloft knowledgebases are on servers dedicated to that function, and run under a secure Linux release. The server only has Agiloft hosting and maintenance services enabled and is further protected by a firewall and a “defense-in-depth” layering of security features including running all services and monitoring with minimum privileges, if possible in chroot jails, and by limiting maintenance access and file transfer to and from the server to logged, encrypted connections from specific IP addresses. Both remote and physical access is limited to specifically authorized personnel. Servers are monitored closely for signs of unusual activity. Security patches and updates are kept up to date with all security advisories. Servers are housed in a commercial data center providing a high level of physical security and reliability. System backups are performed nightly.

The only software and services installed are those required by the installation, logging and audit information is increased and the kernel is patched if necessary, fire walling and individual services are configured to provide limited or local access only to appropriate network interfaces and IP addresses; unnecessary startup scripts and cron activities disabled, and security checksumming is done on vulnerable programs and files.

Related systems used for backup or providing other services (SMTP, DNS, etc.) are secured similarly, appropriate to the services provided.

Data Separation

Protections are in place to ensure that data from different clients hosted on one server are kept distinct and separate. Data on a shared server belongs to the same database but is logically isolated so that users of one knowledgebase cannot access tables and records in a different KB. For customers with particularly strict requirements, a dedicated server option is available, ensuring that the data is physically as well as logically separated.

Backup, Failover, and Disaster Recovery

Agiloft provides multiple redundancies of hardware and data for high availability and disaster recovery:

  • All data, both the knowledgebase and any associated files, are stored in RAID 1 or RAID 10 arrays to protect against hard drive failure.
  • This data is replicated in real-time to a secondary system. This ensures that we can recover immediately even from a catastrophic RAID failure. This secondary or slave is at a separate location or in a different AWS availability zone.

    Redundant server configurations are available where the data is mirrored onto a failover redundant server in real time via a dedicated 1 GB connection. The primary and redundant servers communicate via a heartbeat and the redundant server is configured to automatically take over from the primary if the primary server dies.

  • Snapshots are created on the secondary server every four hours. These snapshots allow you to roll back in time if there is any corrupted data on the server. Snapshots are automatically restored to a test server every two weeks and subjected to database integrity checks.
  • Every knowledgebase is backed up daily and stored on at least two redundant servers. This backup can be used to transfer data to another server or for data restorations. If the customer has a dedicated server, this backup can be made available for daily downloads to their facility.

Data Destruction and Media Disposal Policy

1.0 Purpose

The purpose of this policy is to communicate the types of data and the proper methodologies for secure destruction and disposal to prevent unauthorized access to data and breaches of data privacy.

2.0 Scope

This policy applies to all Agiloft employees, contractors, consultants, temporaries, suppliers, and other workers. This policy is applicable for all network systems, databases, files, applications, electronic records, and services of Agiloft.

3.0 Policy

Agiloft personnel who are authorized to use restricted data products must certify that they have properly destroyed the following:

  • Physical media on which the restricted data products were distributed
  • Derived copies of all restricted data files. This may require destruction or secure erasure of the storage device(s) on which the derived files are stored.
  • Email backups
  • Cloud database copies

3.1 Destruction Procedures

All restricted data files—for example, all copies of the original restricted data and all files derived in whole or in part from the restricted data—must be destroyed when required. There are multiple approaches that can be taken to make such files inaccessible. Restricted data users should choose one of the options listed below:

  • Secure erasure of storage media followed by reformatting
  • Physical destruction of the device(s) on which the restricted data files were stored, such as HDDs, SSDs, USB media or DVDs
  • Secure deletion of individual folders and/or files

3.2 Total Disk Wipe: All Platforms

To perform a total disk wipe for a specific platform, use one of the methods below:

  • Secure erasure: We use DBAN (Darik’s Boot And Nuke), an open-source boot disk utility that deletes the contents of any detected hard disks using DoD 5220.22-M or NIST 800-88 methodologies. Note that this utility can also be used to delete specific files and folders.
  • Physical destruction: We use the hard drive shredding services of Northern CA Paper Recyclers. Contact Operations or Sysadmin if you need drives or other physical storage to be destroyed.
  • Server Termination: We terminate all servers that are no longer in use by using the AWS KB; the scripts that facilitate the termination of the server also wipe and remove all virtual drives associated with that server. Backups of those drives will exist until pruned, as described in our Redundancy and Backup Infrastructure policy document.

3.3 Selective File Wipe

To delete individual files and folders, use one of the following methods:

  • Wipe File: Portable application that overwrites the specific disk space occupied by the file you’d like erased and leaves the rest of the disk untouched
  • Shred: Linux/Unix file over-write/delete command

4.0 Enforcement

The Sysadmin team will verify compliance to this policy through various methods, including but not limited to monitoring, business tool reports, and internal and external audits.

Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Internet Equipment Policy

1.0 Purpose

The purpose of this policy is to define standards to be met by all equipment owned and/or operated by Agiloft located outside Agiloft’s corporate internet firewalls. These standards are designed to minimize the potential exposure to Agiloft and Agiloft’s clients from the loss of sensitive or company confidential data, intellectual property, damage to public image etc., which may follow from unauthorized use of Agiloft resources.

Devices that are internet facing and outside an Agiloft firewall are subject to this policy. These devices (network and host) are particularly vulnerable to attack from the internet since they reside outside the corporate firewalls.

The policy defines the following standards:

  • Ownership responsibility
  • Secure configuration requirements
  • Operational requirements
  • Change control requirement

2.0 Scope

All Internet-facing equipment or devices owned and/or operated by Agiloft (including hosts, routers, switches, etc.) and/or registered in any Domain Name System (DNS) domain owned by Agiloft must follow this policy.

This policy also covers any host device outsourced or hosted at external/third-party service providers, if that equipment resides in the “” domain or appears to be owned by Agiloft.

All new equipment that falls under the scope of this policy must be configured according to the referenced configuration documents, unless a waiver is obtained from Information Security. All existing and future equipment deployed on Agiloft’s un-trusted networks must comply with this policy.

3.0 Policy

3.1 Ownership and Responsibilities

Equipment and applications within the scope of this policy must be administered by Information Security for system, application, and/or network management, and will be responsible for the following:

  • Equipment must be documented in the corporate wide enterprise management system. At a minimum, the following information is required:
    • Host contacts and location.
    • Hardware and operating system/version.
    • Main functions and applications.
    • Password groups for privileged passwords.
  • Network interfaces must have appropriate Domain Name Server records (minimum of A and PTR records).
  • Password groups must be maintained in accordance with the corporate wide password management system/process.
  • Immediate access to equipment and system logs must be granted to members of Information Security upon demand, per the Risk Assessment Policy.
  • Changes to existing equipment and deployment of new equipment must follow and corporate governess or change management processes/procedures.

To verify compliance with this policy, Information Security will periodically audit equipment per the Risk Assessment Policy.

3.2 General Configuration Policy

All equipment must comply with the following configuration policy:

  • Information Security as part of the pre-deployment review phase must approve hardware, operating systems, services and applications.
  • Operating system configuration must be done according to the secure host and router installation and configuration standards.
  • All patches/hot-fixes recommended by the equipment vendor and Information Security must be installed. This applies to all services installed, even though those services may be temporarily or permanently disabled. Administrative owner groups must have processes in place to stay current on appropriate patches/hotfixes and to be notified of security vulnerability advisories.
  • Services and applications not serving business requirements must be disabled.
  • Trust relationships between systems may only be introduced according to business requirements, must be documented, and must be approved by Information Security.
  • Access control lists must restrict services and applications not for general access.
  • Insecure services or protocols (as determined by Information Security) must be replaced with more secure equivalents whenever such exist.
  • Remote administration must be performed over secure channels (e.g., encrypted network connections using SSH, SSL, or IPSEC) or direct console access. SSH authentication must authenticate using public keys, not passwords. When possible, a highly secure cipher such as 256-bit AES shall be employed. Where a methodology for secure channel connections is not available, one-time passwords (DES/SofToken) must be used for all access levels.
  • All host content updates and backups must occur over secure channels. Host content updates shall be initiated by the receiving system, and backups shall be initiated by the sending system.
  • Security-related events must be logged and audit trails saved to Information Security-approved logs. Security-related events include (but are not limited to) the following:
    • User login failures.
    • Failure to obtain privileged access.
    • Access policy violations.
  • Information Security will address non-compliance waiver requests on a case-by-case basis and approve waivers if justified.
3.3.1 New Installations and Change Management Procedures, Infrastructure

All new installations and changes to the configuration of existing equipment and applications must follow these policies and procedures:

  • New installations must be done via procedures approved for the equipment and/or software.
  • Configuration changes must follow the Corporate Change Management (CM) Procedures.
  • Information Security must be invited to perform system/application audits prior to the deployment of new services.
  • Information Security must be engaged, either directly or via CM, to approve all new deployments and configuration changes.
3.3.2 New Installations and Change Management Procedures, Application

All updates and new application code deployments must follow these policies and procedures:

  • All development must be performed exclusively by employees authorized as part of the Engineering team, and conducted in an approved and secured development environment according to the Agiloft Software Development Life Cycle.
  • Code changes must be reviewed by a developer team manager before merging those changes with the existing code version in production.
  • Once all code changes have been reviewed by managers and vetted for inclusion in a scheduled upgrade, the complete provisional system must be assessed for vulnerabilities and errors according to the QA SOP, as well as according to the following code delivery sequence:
    1. The responsible developer manually tests the code change and, if no bugs are found, runs multifarm. If the full test suite succeeds on the changed code, the developer commits the code to the trunk. If any tests have failed, the developer investigates the failure(s), fixes the code, and repeats Step 1 until all multifarm tests succeed with no errors.
    2. The responsible developer provides a checklist comprised of all required checks according to the “Generic checklist template” document. The resultant checklist is attached to the Ticket or Enhancement record in the Support KB and made available for review by the team lead and QA Team members.
    3. The trunk code is tested by QA engineers according to the checklist. In addition, QA engineers run extended tests that include regression tests, in-depth tests of new functionality, security tests, integration tests that include permissions, and performance tests. Additional tests may be performed according to particular cases based on QA determination of technologies and features that warrant additional inspection. GUI changes are tested in all browsers listed in the section “Browsers to test on,” in the Power User Interface, End User Interface, and Mobile Interface. Changes are tested in the admin console as applicable.
    4. Any failures of regression tests are submitted as Tickets and assigned to the responsible developer. The Ticket priority is set as Regressive Critical Dependency, with the Regressive flag set to Yes.
    5. Merging any code changes is permitted with Release Candidate or Release code after a successful WE build, which includes unit tests and Watir tests, as well as passing extended manual testing. All related regressive bugs must be fixed and tested before merging.
    6. The QA Team is responsible for the additional round of manual testing on Release Candidate and Release code after the code changes have been merged.
    7. The code may be signed off for customer deployment if all automated tests are passed; all regressive bugs are fixed, tested and closed; and manual testing proves that there are no regressive and major bugs.
3.4 Monitoring and Backups
  • Regular backups of data to separate physical locations shall occur every 24 hours. These will include backups to at least two onsite servers and a third-party offsite facility.
  • All security-related events on critical or sensitive systems must be logged and audit trails saved with backups. Security-related logs shall be kept online for a minimum of 1 week.
  • Detection software is employed and monitored to increase awareness of threats.
  • File integrity management tools, such as tripwire on Linux, is employed to maintain system file integrity. Database integrity is checked regularly using the appropriate tools.
3.5 Compliance
  • Audits will be performed on a regular basis by authorized organizations within Agiloft.
  • The internal audit group or Information Security, in accordance with the Audit Policy, will manage audits. Information Security will filter findings not related to a specific operational group and then present the findings to the appropriate support staff for remediation or justification.
  • Every effort will be made to prevent audits from causing operational failures or disruptions.
3.6 Incident Response

Security-related events will be reported to Information Security. Corrective measures will be prescribed as needed. Security-related events include, but are not limited to:

  • Port-scan attacks
  • Worm attacks
  • Evidence of unauthorized access to privileged accounts
  • Anomalous occurrences that are not related to specific applications on the host
  • Distributed Denial of Service (DDoS) attacks

Agiloft continually review and maintains security incident management policies and procedures. Agiloft will promptly notify any customer that may be affected in the event Agiloft becomes aware of an actual or reasonably suspected unauthorized disclosure of client data associated with any of the services we offer. Customers will be notified of security-related events as soon as they are detected, normally within two hours. Such notification will be given no later than 48 hours of the detection or suspicion of such an incident. Customers will be kept apprised of the cause, extent, impact, resolution of any such incident.

Incidents are managed via an Agiloft workflow with voice and email communication points to customers for responses and notifications. An Agiloft table contains standard fields to log incidents and allow attachment of relevant low-level log files, etc.

3.7 Equipment Outsourced to External Service Providers

The responsibility for the security of the equipment deployed by external service providers must be clarified in the contract with the service provider and security contacts, and escalation procedures documented.

4.0 Enforcement

Any employee found to have violated this policy is subject to disciplinary action, up to and including termination of employment.

External service providers found to have violated this policy is subject to financial penalties, up to and including termination of contract.

Password Policy

1.0 Overview

Passwords are an important aspect of computer security. They are the front line of protection for user accounts. A poorly chosen password may result in the compromise of Agiloft’s entire corporate network. As such, all Agiloft employees (including contractors and vendors with access to Agiloft systems) are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.

2.0 Purpose

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

3.0 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 Agiloft facility, has access to the Agiloft network, or stores any non-public Agiloft information.

4.0 Policy

4.1 General
  • All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a quarterly basis.
  • All user-level passwords (e.g., email, web, desktop computer, etc.) must be changed at least every six months. The recommended change interval is every four months.
  • User accounts that have system-level privileges granted through group memberships or programs such as “sudo” must have a unique password from all other accounts held by that user.
  • Passwords must not be inserted into email messages or other forms of electronic communication.
  • Where SNMP is used, the community strings must be defined as something other than the standard defaults of “public,” “private” and “system” and must be different from the passwords used to log in interactively. A keyed hash must be used where available (e.g., SNMPv2).
  • All user-level and system-level passwords must conform to the guidelines described below.
4.2 Expiration/Termination

Passwords and other access methods shall be removed or disabled when no longer necessary, and immediately when an individual no longer has authorized access, such as termination of employment.

4.3 Guidelines
A. General Password Construction Guidelines

Passwords are used for various purposes at Agiloft. Some of the more common uses include: user level accounts, web accounts, email accounts, screen saver protection, voicemail password, and local router logins. Since very few systems have support for one-time tokens (i.e., dynamic passwords which are only used once), everyone should be aware of how to select strong passwords.

Poor, weak passwords have the following characteristics:

  • The password contains less than ten characters
  • The password is a word found in a dictionary (English or foreign)
  • The password is a common usage word such as:
    • Names of family, pets, friends, coworkers, fantasy characters, etc.
    • Computer terms and names, commands, sites, companies, hardware, software.
    • Company names, city names, or any derivation.
    • Birthdays and other personal information such as addresses and phone numbers.
    • Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321, etc.
    • Any of the above spelled backwards.
    • Any of the above preceded or followed by a digit (e.g., secret1, 1secret).

Strong passwords have the following characteristics:

  • Contain both upper and lower-case characters (e.g., a–z, A–Z).
  • Have digits and punctuation characters as well as letters e.g., 0–9, !@#$%^&*()_+|~-=\{}[]:”;'<>?,./).
  • Are at least ten alphanumeric characters long.
  • Are not a word in any language, slang, dialect, jargon, etc.
  • Are not based on personal information, names of family, etc.
  • Passwords should never be written down or stored online except in an approved system dedicated to managing passwords. One way to create secure passwords that can be easily remembered is to create it from the first letters of a phrase. For example, the phrase might be: “I like to watch the Cubs on Monday Night Football” and the password would be: “Il2wtCoMNF”.

Of course, you should not use any of the above examples as passwords!

B. Password Protection Standards

Do not use the same password for Agiloft accounts as for other non-Agiloft access (e.g., personal ISP account, option trading, benefits, etc.). Where possible, don’t use the same password for various Agiloft access needs. For example, select one password for the Engineering systems and a separate password for IT systems. Also, select a separate password to be used for an NT account and a UNIX account.

Do not share Agiloft passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive, Confidential Agiloft information.

Here is a list of “don’ts”:

  • Don’t reveal a password over the phone to ANYONE
  • Don’t reveal a password in an email message
  • Don’t reveal a password to the boss
  • Don’t talk about a password in front of others
  • Don’t hint at the format of a password (e.g., “my family name”)
  • Don’t reveal a password on questionnaires or security forms
  • Don’t share a password with family members
  • Don’t reveal a password to coworkers while on vacation

If someone demands a password, refer them to this document or have them call someone in the Information Security Department.

Do not use the “Remember Password” feature of applications (e.g., Eudora, Outlook, Netscape Messenger).

Again, do not write passwords down and store them anywhere in your office. Do not store passwords in a file on ANY computer system, including mobile devices without encryption.

Change passwords at least once every six months (except system-level passwords which must be changed quarterly). The recommended change interval is every four months.

If you suspect that an account or password has been compromised, report the incident to Information Security and change all passwords.

Password cracking or guessing may be performed on a periodic or random basis by Information Security or its delegates. If a password is guessed or cracked during one of these scans, the user will be required to change it.

C. Application Development Standards

Application developers must ensure their programs contain the following security precautions. Applications:

  • Should support authentication of individual users, not groups.
  • Should not store passwords in clear text or in any easily reversible form.
  • Should provide for some sort of role management, such that one user can take over the functions of another without having to know the other’s password.
  • Should support TACACS+ , RADIUS and/or X.509 with LDAP security retrieval, wherever possible.
D. Use of Passwords and Passphrases for Remote Access Users

Access to the Agiloft Networks via remote access is to be controlled using either a one-time password authentication or a public/private key system with a strong passphrase.

E. Passphrases

Passphrases are generally used for public/private key authentication. A public/private key system defines a mathematical relationship between the public key that is known by all, and the private key, that is known only to the user. Without the passphrase to “unlock” the private key, the user cannot gain access.

Passphrases are not the same as passwords. A passphrase is a longer version of a password and is, therefore, more secure. A passphrase is typically composed of multiple words. Because of this, a passphrase is more secure against “dictionary attacks.”

A good passphrase is relatively long and contains a combination of upper and lowercase letters and numeric and punctuation characters. An example of a good passphrase:


All of the rules above that apply to passwords apply to passphrases.

5.0 Enforcement

Any employee found to have violated this policy is subject to disciplinary action, up to and including termination of employment.

Acceptable Use Policy

1.0 Overview

Information Security’s intentions for publishing an Acceptable Use Policy are not to impose restrictions that are contrary to Agiloft’s established culture of openness, trust and integrity. Information Security is committed to protecting Agiloft’s employees, partners and the company from illegal or damaging actions by individuals, either knowingly or unknowingly.

Internet/Intranet/Extranet-related systems, including but not limited to computer equipment, software, operating systems, storage media, network accounts providing electronic mail, WWW browsing, and FTP, are the property of Agiloft. These systems are to be used for business purposes in serving the interests of the company, and of our clients and customers in the course of normal operations. Please review Human Resources policies for further details.

Effective security is a team effort involving the participation and support of every Agiloft employee and affiliate who deals with information and/or information systems. It is the responsibility of every computer user to know these guidelines, and to conduct their activities accordingly.

2.0 Purpose

The purpose of this policy is to outline the acceptable use of computer equipment at Agiloft. These rules are in place to protect the employee and Agiloft. Inappropriate use exposes Agiloft to risks including virus attacks, compromise of network systems and services, and legal issues.

3.0 Scope

This policy applies to employees, contractors, consultants, temporaries, and other workers at Agiloft, including all personnel affiliated with third parties. This policy applies to all equipment that is owned or leased by Agiloft.

4.0 Policy

4.1 General Use and Ownership
  • While Agiloft’s network administration desires to provide a reasonable level of privacy, users should be aware that the data they create on the corporate systems remains the property of Agiloft. Because of the need to protect Agiloft’s network, management cannot guarantee the confidentiality of information stored on any network device belonging to Agiloft.
  • Employees are responsible for exercising good judgment regarding the reasonableness of personal use. Individual departments are responsible for creating guidelines concerning personal use of Internet/Intranet/Extranet systems. In the absence of such policies, employees should be guided by departmental policies on personal use, and if there is any uncertainty, employees should consult their supervisor or manager.
  • Information Security recommends encryption of any information considered to be sensitive or vulnerable be encrypted. For guidelines on information classification, see Information Security’s Information Sensitivity Policy. For guidelines on encrypting email and documents, please see Information Security’s Awareness Initiative.
  • For security and network maintenance purposes, authorized individuals within Agiloft may monitor equipment, systems and network traffic at any time, per Information Security’s Audit Policy.
  • Agiloft reserves the right to audit networks and systems on a periodic basis to ensure compliance with this policy.
4.2 Security and Proprietary Information
  • The user interface for information contained on Internet/Intranet/Extranet-related systems should be classified as either confidential or not confidential, as defined by corporate confidentiality guidelines, details of which can be found in Human Resources policies. Examples of confidential information include but are not limited to: company private, corporate strategies, competitor sensitive, trade secrets, specifications, customer lists, research data, and clients’ data. Employees should take all necessary steps to prevent unauthorized access to this information, including the removal of such information from plain view in work areas when not present.
  • Keep passwords secure and do not share accounts. Authorized users are responsible for the security of their passwords and accounts. System level passwords are required to be changed quarterly; user level passwords are required to be changed every six months.
  • If possible, passwords should be memorized and not stored in any machine-readable form. If written down, passwords should be maintained within the physical control of individuals and never in plain view around work areas.
  • Use encryption of information in compliance with Information Security’s Acceptable Encryption Use policy.
  • Because information contained on portable computers is especially vulnerable, special care must be exercised. Protect laptops in accordance with the “Laptop Security Tips”.
  • Postings by employees from a Agiloft email address to newsgroups should contain a disclaimer stating that the opinions expressed are strictly their own and not necessarily those of Agiloft, unless posting is in the course of business duties.
  • All hosts used by the employee that are connected to the Agiloft Internet/Intranet/Extranet, whether owned by the employee or Agiloft, shall be continually executing approved virus-scanning software with a current virus database. Unless overridden by departmental or group policy.
  • Employees must use extreme caution when opening email attachments received from unknown senders, which may contain viruses, email bombs, or Trojan horse code.
4.3. Unacceptable Use

The following activities are, in general, prohibited. Employees may be exempted from these restrictions during the course of their legitimate job responsibilities (e.g., systems administration staff may have a need to disable the network access of a host if that host is disrupting production services).

Under no circumstances is an employee of Agiloft authorized to engage in any activity that is illegal under local, state, federal or international law while utilizing Agiloft-owned resources.

The lists below are by no means exhaustive, but attempt to provide a framework for activities that fall into the category of unacceptable use.

System and Network Activities

The following activities are strictly prohibited, with no exceptions:

  • Violations of the rights of any person or company protected by copyright, trade secret, patent or other intellectual property, or similar laws or regulations, including, but not limited to, the installation or distribution of “pirated” or other software products that are not appropriately licensed for use by Agiloft.
  • Unauthorized copying of copyrighted material including, but not limited to, digitization and distribution of photographs from magazines, books or other copyrighted sources, copyrighted music, and the installation of any copyrighted software for which Agiloft or the end user does not have an active license is strictly prohibited.
  • Exporting software, technical information, encryption software or technology, in violation of international or regional export control laws, is illegal. The appropriate management should be consulted prior to export of any material that is in question.
  • Introduction of malicious programs into the network or server (e.g., viruses, worms, Trojan horses, email bombs, etc.).
  • Revealing your account password to others or allowing use of your account by others. This includes family and other household members when work is being done at home.
  • Using an Agiloft computing asset to actively engage in procuring or transmitting material that is in violation of sexual harassment or hostile workplace laws in the user’s local jurisdiction.
  • Making fraudulent offers of products, items, or services originating from any Agiloft account.
  • Making statements about warranty, expressly or implied, unless it is a part of normal job duties.
  • Effecting security breaches or disruptions of network communication. Security breaches include, but are not limited to, accessing data of which the employee is not an intended recipient or logging into a server or account that the employee is not expressly authorized to access, unless these duties are within the scope of regular duties. For purposes of this section, “disruption” includes, but is not limited to, network sniffing, pinged floods, packet spoofing, denial of service, and forged routing information for malicious purposes.
  • Port scanning or security scanning is expressly prohibited unless prior notification to Information Security is made.
  • Executing any form of network monitoring which will intercept data not intended for the employee’s host, unless this activity is a part of the employee’s normal job/duty.
  • Circumventing user authentication or security of any host, network or account.
  • Interfering with or denying service to any user other than the employee’s host (for example, denial of service attack).
  • Using any program/script/command, or sending messages of any kind, with the intent to interfere with, or disable, a user’s terminal session, via any means, locally or via the Internet/Intranet/Extranet.
  • Providing information about, or lists of, Agiloft employees to parties outside Agiloft.

Email and Communications Activities

  • Sending unsolicited email messages, including the sending of “junk mail” or other advertising material to individuals who did not specifically request such material (email spam).
  • Any form of harassment via email, telephone or paging, whether through language, frequency, or size of messages.
  • Unauthorized use, or forging, of email header information.
  • Solicitation of email for any other email address, other than that of the poster’s account, with the intent to harass or to collect replies.
  • Creating or forwarding “chain letters”, “Ponzi” or other “pyramid” schemes of any type.
  • Use of unsolicited email originating from within Agiloft’s networks of other Internet/Intranet/Extranet service providers on behalf of, or to advertise, any service hosted by Agiloft or connected via Agiloft’s network.
  • Posting the same or similar non-business-related messages to large numbers of Usenet newsgroups (newsgroup spam).

5.0 Enforcement

Any employee found to have violated this policy is subject to disciplinary action, up to and including termination of employment.

Case Studies

Learn how customers have achieved business agility with Agiloft.

Read Case Studies

See Agiloft in Action

See how the Agiloft can fit your complex contracting needs.

Watch Demo