BillMax Installation
Data security is greatly influenced by the end
      customer's business practices. An installation of BillMax assumes adherence to standard
      industry security practices. They include but are not limited to the following:
        - The BillMax server(s) hosting both the Staff Portal and the BillMax database are behind
          a suitably configured firewall.
- The Staff Portal is accessible only to the users that need access.
- All network traffic from the web browser of a Staff Portal user to the BillMax server is
          transmitted using HTTPS.
- All network traffic from the web browser of a Customer Portal user to the Customer
          Portal server is transmitted using HTTPS.
- All network traffic from the Customer Portal Server to the BillMax edge service is
          transmitted using HTTPS.
- The Customer Portal server is behind a firewall such that the only public access is to
          the web server through HTTPS.
- Physical access to the servers is limited to those who need physical access to the
          server.
- Login accounts on the servers are limited to those who need access to the server.
Encrypted Data
      
      Encrypted data is divided into three categories:
          - Passwords for access to BillMax portals.
- Passwords for provisioning purposes.
- Credit Card numbers and Bank Account numbers.
        The encryption scheme used to encrypt passwords used to access the Staff Portal or the
          Customer Portal is configurable trough settings in
            /usr/local/billmax/local/billmax.conf. The default encryption
          algorithm is MD5.
        When a end customer uses the Customer Portal to register, the user name and password are
          encrypted using BLOWFISH and temporarily written to the disk on the Customer Portal
          server.
        The encryption scheme used to encrypt passwords used for provisioning purposes is also
          configurable trough settings in
          
/usr/local/billmax/local/billmax.conf. The default encryption
          algorithm is DES. 
CAUTION:
BillMax provides means for storing provisioning
            passwords in clear text. It is strongly recommended this not be done if there is no
            technical reason to do this. 
 
    Credit Card number and Bank Account numbers
      
      Note: For the purposes of this discussion, Number will refer to both Credit Card numbers
          and Bank Account numbers.
Note: For the purposes of this discussion, "third party
          processors" are those supported by BillMax out of the box and do not include any custom
          third party processors. 
Business practices surrounding Numbers are extremely
        important due to the sensitive nature of the data.  Some, but not all, aspects to consider
          are:
          - If a paper application has the Number, is the application destroyed or the Number
            redacted?
- Are CSRs trained to not write down Numbers on pieces of paper?
- If calls are recorded, what is done to secure the recordings or to disable the
            recording if a Number is being provided by the end customer? 
Storage of Numbers in BillMax depends on the third party processor that will use the
        Numbers.  If supported by both the processor and BillMax, a Token may be stored in place of
        the Number.  Currently this option is available if IPPay® is the
        processor.  Both Numbers and Tokens are stored using AES encryption.  
      If PCI compliance is enabled in BillMax, the BillMax customer is prompted to change the AES
        encryption key every 90 days. The AES encryption key may be composed of phrases entered
        through the Staff Portal by two different users with Administrative privileges for
        additional security.  See Change the AES Encryption Key.
      Numbers entered through the Staff Portal and Customer Portal are never written to disk in
        plain text when using a third party processor such as IPPay.  The number travels from the
        browser to the server and is encrypted before being written to the database.  If the Number
        is tokenized, the encrypted Token is written to the database.  When used, the Number or
        Token is decrypted in memory and sent directly to the third party processor using
          HTTPS.
DANGER
If using the NACHA file format, Bank Account numbers are stored
          in the NACHA file in plain text.  This is unavoidable.
For identification purposes, the last four digits of a Number are stored in plain text and
        may be displayed in either the Staff Portal or the Customer Portal. These last four digits
        may also be displayed on a Billing Statement or Statement to help the end customer identify
        the means of payment.