File-GENERAL™
An encrypted file repository designed to enable compliance

File-GENERAL™ is a secure file repository specifically designed to help organizations to achieve compliance with the payment card industry's data security standard (PCI DSS) mandates and HIPAA/HITECH act. File-GENERAL™ transparently encrypts all file types before storing them. Access to highly sensitive files is granted by a duly authorized File-GENERAL™ administrator. Each file access is logged, time stamped and cryptographically signed. The logs are cryptographically signed and stored in an encrypted vault to provide non-repudiation. File-GENERAL™ has a proven track record of enabling organizations to become compliant.

  • Transparent encryption of data stored in flat files
  • FIPS 140-2 compliant key management
  • Transitive trust model based appliance
  • Role-based platform management
  • Cryptographically signed file access logs
  • Protection against a privileged insider
  • Role-based platform management
  • Support for multiple file access protocols

Compliance made easy
File-GENERAL™ provides transparent encryption - something that many regulations and mandates require. Furthermore, access to the sensitive data is strictly controlled. Each and every access to the sensitive data is diligently logged. The log files are cryptographically signed and stored in an encrypted vault. All of this makes the process of going through an audit much easier. In fact File-GENERAL™ has gone through PCI compliance scrutiny several times that is only reserved only for level-1 merchants.

Encrypt confidential data transparently 
File-GENERAL™ encrypts all types of file data transparently using AES algorithm. FIPS 140 Level-2/3 compliant smart cards are used to manage the encryption key. No client software is needed. 

Protect your data against the prying eyes of a privileged user (“root”)
File-GENERAL™ employs role-based platform management. Traditional IT administrators who are responsible for managing file or Active Directory servers within a corporate network, have no control over File-GENERAL™ and can’t access the protected data stored on it.

Available models:

Model #

FG-100

FG-200

FG-300

FG-V-NT

FG-V

Operating System

Secure
PG-OS

Secure
PG-OS

Secure
PG-OS

Secure
PG-OS

Secure
PG-OS

CPU - Quad-code Intel Xeon 2.4GHz 4 x 12M Cache, Turbo, HT, L2 Cache 8MB L3 Cache, 1066MHz Max Mem

1

1

1

SMP Virtual Appliance

SMP Virtual Appliance

Memory - Registered w/ ECC 1333MHz Dual Ranked RDIMMs

4GB

8GB

8GB

Minimum 2GB

Minimum 2GB

Storage - SATA 10000-RPM 16MB Cache 3.0Gb/s

500GB RAID-5

1TB RAID-5
w/ Hot Spare

2TB RAID-5
w/ Hot Spare

n/a

n/a

Disks

3

4

4

n/a

n/a

NIC/LOM

2x GbE LOM

2x GbE LOM

2x GbE LOM

n/a

n/a

Availability

Hot-swap HDD; 500W Redundant PSU; Memory RAS

Hot-swap HDD; 500W Redundant PSU; Memory RAS

Hot-swap HDD; 500W Redundant PSU; Memory RAS

n/a

n/a

Enclosure

1U

1U

1U

n/a

n/a

Power Supplies

Redundant 500W (80+GOLD)

Auto Ranging 100V ~240V)

Redundant 500W (80+GOLD)

Auto Ranging 100V ~240V)

Redundant 500W (80+GOLD)

Auto Ranging 100V ~240V)

n/a

n/a

Dimensions

1.69 x 17.09

x 24.69 (in)

1.69 x 17.09

x 24.69 (in)

1.69 x 17.09

x 24.69 (in)

n/a

n/a

Weight

35.02lbs (15.9Kg)

35.02lbs (15.9Kg)

35.02lbs (15.9Kg)

n/a

n/a

Operating Environment

50 to 95 °F

10 to 35 °C

50 to 95 °F

10 to 35 °C

50 to 95 °F

10 to 35 °C

n/a

n/a

 






Security Specifications

Description

FG-
100

FG-
200

FG-
300

FG-
V-NT

FG-
V

Encryption algorithm used

Advanced Encryption Standard (AES) - symmetric-key encryption standard (U.S. FIPS PUB 197 (FIPS 197).

Y

Y

Y

Y

Y

Key size

256 bits

Y

Y

Y

Y

Y

Key storage

Federal Information Processing Standard (FIPS) Publication 140-2/3 based smart cards running EAL4/EAL5 operating system.

Y

Y

Y

N

Y*

Key distribution

Secure distribution is conducted during the installation process.

Y

Y

Y

n/a

Y

Key revocation

Authenticated revocation - a single step process.

Y

Y

Y

n/a

Y

Key rotation

Built-in key rotation.

Y

Y

Y

n/a

Y

Non-repudiation

Cryptographically signed reports stored in an encrypted data vault.

Y

Y

Y

Y

Y

Protection against a malicious privileged user

Privileged insiders are not allowed to view/alter file data stored in "Crypto-Shares".

Y

Y

Y

Y

Y

Flat file data encryption

Transparent encryption of all file types.

“On-demand” per "Crypto-Share" encryption.

No client side agent is required.

Y

Y

Y

Y

Y

File access tracking (logs)

All file accesses are logged. 

Logs are stored in a tamper-resistant encrypted vault.

Y

Y

Y

Y

Y

Supported file access protocols

 SMB, SFTP/SSHFS, NFS**

Y

Y

Y

Y

Y

Protection against physical loss

No file data can be accessed unless "Crypto-Share" service is running. Only an authorized File-GENERAL™ administrator with a smart card can start this service.  

Y

Y

Y

Y

Y

Firewall

Built-in customized firewall.

Y

Y

Y

Y

Y

Reduced attack surface

Minimal set of services that are needed for a secure and controlled operation.

Y

Y

Y

Y

Y

Separation of duties (SOD)

Role-based platform management.

Y

Y

Y

Y

Y

Security updates

Automated and tested updates.

Y

Y

Y

Y

Y

System logs

Privileged operation logs are cryptographically signed & stored in encrypted format.

Y

Y

Y

Y

Y

Hardened appliance

Total footprint < 700MB.

Y

Y

Y

Y

Y

* Certain limitations apply

** Coming shortly

Organizations are required to protect the credit card data stored in flat files in order to comply with the Payment Card Industry (PCI) mandates. The fallout from a data-security breach can be very disruptive and possibly even devastating. The loss of data irreparably damages consumer’s trust in the brand and adversely impacts stakeholders. At the same time, the Payment Card Industry Data Security Standard (PCI DSS) is continuously evolving, making compliance a challenge. Most small businesses don't have the expertise to implement the necessary security measures in order to achieve compliance. However, the consequences of non-compliance are becoming increasingly costly. The fallout from a data breach can far outweigh the immediate costs of fixing the problems that allowed the breach to happen in the first place. If cardholder data were to be disclosed, the organization must notify the people affected, resulting in additional financial losses and even legal exposure.

File-GENERAL™, a secure flat file repository, has been designed to enable easy compliance with the following PCI DSS mandates:

Section

PCI DSS Requirement

File-GENERAL

2.2.1

Implement only one primary function per server.

2.2.2

Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the device’s specified function).

2.2.3

Configure system security parameters to prevent misuse.

2.2.4

Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

2.3

Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.

3.4

Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:

§ One-way hashes based on strong cryptography

  • Truncation

  • § Index tokens and pads (pads must be securely stored)

  • § Strong cryptography with associated key-management processes and procedures

  • §The MINIMUM account information that must be rendered unreadable is the PAN.

3.4.1

If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local user account databases). Decryption keys must not be tied to user accounts.

[1]

3.4.1.b

Verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls).

[5]

3.4.1.c

Verify that cardholder data on removable media is encrypted wherever stored.

[5]

3.5

Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse:

3.5.1

Restrict access to cryptographic keys to the fewest number of custodians necessary.

3.5.2

Store cryptographic keys securely in the fewest possible locations and forms.

3.6.1

Generation of strong cryptographic keys

3.6.2

Secure cryptographic key distribution

3.6.3

Secure cryptographic key storage

3.6.4

Periodic cryptographic key changes - As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically - At least annually

3.6.5

Retirement or replacement of old or suspected compromised cryptographic keys

3.6.6

Split knowledge and establishment of dual control of cryptographic keys.

3.6.7

Prevention of unauthorized substitution of cryptographic keys

4.1

Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.

6.1

Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release.

√ [2]

6.2

Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet). Update configuration standards as required by PCI DSS Requirement 2.2 to address new vulnerability issues.

√ [2]

6.2.b

Verify that processes to identify new security vulnerabilities include using outside sources for security vulnerability information and updating the system configuration standards reviewed in Requirement 2.2 as new vulnerability issues are found.

[2][5]

7.1

Limit access to system components and cardholder data to only those individuals whose job requires such access. Access limitations must include the following:

 

7.1.1

Restriction of access rights to privileged user IDs to least privileges necessary to perform job responsibilities[3]

√ [3]

7.1.2

Assignment of privileges is based on individual personnel’s job classification and function

√ [3]

8.5

Ensure proper user authentication and password management for non-consumer users and administrators on all system components as follows:

 

8.5.1

Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.

8.5.4

Immediately revoke access for any terminated users.

8.5.6

Enable accounts used by vendors for remote maintenance only during the time period needed.

8.5.9

Change user passwords at least every 90 days.

8.5.10

Require a minimum password length of at least seven characters.

8.5.11

Use passwords containing both numeric and alphabetic characters.

8.5.12

Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used.

10.1

Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.

10.2

Implement automated audit trails for all system components to reconstruct the following events:

 

10.2.2

All actions taken by any individual with root or administrative privileges

10.2.4

Invalid logical access attempts

10.2.7

Creation and deletion of system-level objects

10.3

Record at least the following audit trail entries for all system components for each event:

 

10.3.1

User identification

10.3.2

Type of event

10.3.3

Date and time

10.3.4

Success or failure indication

10.3.5

Origination of event

10.3.6

Identity or name of affected data, system component, or resource

10.4

Synchronize all critical system clocks and times.

10.5

Secure audit trails so they cannot be altered.

10.5.1

Limit viewing of audit trails to those with a job-related need.

10.5.2

Protect audit trail files from unauthorized modifications.

10.5.5

Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).

10.7

Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up).

[1]Logical access control is used even though disk encryption is not used.

[2]Packet General provides a security update service (comes bundled with the solution).

[3]Packet General solutions use RBAC

[4]Smart-cards are used for two factor authentication as well as for key management.

[5]In order to clarify the mandate, the language of this mandate has been substituted by the corresponding "test procedure" recommended by the PCI council.

Note#1: The red characters indicate a strong match between a built-in product feature and a PCI mandate.

Note#2: The broad headings "7.1", "8.5", "10.2", "10.3" are listed without check marks, because the sub-mandates of each heading are intended to address the directives accordingly.