Fortune Security Standards
A. General
Company shall maintain procedures to ensure the accuracy, validity and completeness of the Fortune Data it collects, maintains and stores.
B. Data Collection, Transmission, Storage, Destruction
1. Company shall secure Fortune Data using multiple layers of access controls and such access to be based on the principle of least privilege and need-to-know.
2. Fortune Data must not be transferred to a third party unless so provided in the Agreement.
3. Fortune Data that identifies an individual, including but not limited to email addresses, must be encrypted with strong, industry-standard encryption practices (algorithms, key management) when transmitted over public networks or the Internet or protected by other controls.
4. Any consumer preferences, including consumer opt-outs and privacy preferences must be honored and adhered to.
5. Data may not be collected from users under the age of 13 unless the application is in compliance with the Children’s Advertising Review Unit and with all applicable laws, rules and regulations, including but not limited to the Children’s Online Privacy Protection Act, and has been approved by the Fortune Law Department.
6. Age or year of birth data may not be collected unless approved by the Fortune Law Department, and if so approved, Company is responsible for complying with all applicable laws, rules and regulations.
C. Company Application Development
Secure Coding Requirements
1. Company must follow development best practices no less stringent than those that would address the Open Web Application Security Project (“OWASP”) Top 10 vulnerabilities.
2. Forms requesting information generally considered confidential (including but not limited to payment card numbers, account numbers, Social Security Numbers, or password requests) must mask the data when entered in the fields on the screen or limit the display of data to the minimum necessary such as the last 4 digits of an identification number or similar.
3. The transmission of information generally considered confidential (including but not limited to payment card numbers, account numbers, Social Security Numbers, or passwords) must use strong encryption (i.e. Secure Socket Layer “SSL”) with digital certificates signed by a trusted certificate authority. The use of self-signed certificates is not permitted.
4. Company agrees to encrypt while in transit and at rest data provided by Fortune to Company. For the avoidance of doubt, “encryption” shall be deployed using PGP or other acceptable key based encryption.
5. If applicable, Company agrees that it has in place appropriate technology to receive store, and transmit Fortune Data in an encrypted format in order to provide the Services, and Company will work with Fortune to test Company’s ability to deliver the data in an encrypted format.
6. For web applications, all information that might identify a user, including email address, username, and snail mail address, must be sent using HTTP POST requests. The GET method must not be used to send information generally considered confidential or identifying via URL parameters.
7. All points of input, including both web application and web service calls, must be validated to ensure they are appropriate. Input must be checked for SQL injection, command injection, cross-site-scripting, buffer overflows, parameter manipulation and other attacks.
8. In production environments, error messages must not contain unnecessary information such as line numbers, code snippets, SQL statements or stack traces.
9. Applications must be resistant to Denial of Service (“DoS”) conditions that can cause an application to become unavailable.
10. Applications must be subject to penetration testing using a risk based frequency in accordance with applicable regulations covering such data but for the avoidance of doubt, at least once per year.
D. Application Authentication/Authorization Requirements
1. End User/Customer account IDs must neither request nor contain Social Security Numbers, Account Numbers, or other information generally considered confidential. Email address is an acceptable account ID. All passwords must, at a minimum:
- contain a minimum of eight characters;
- be masked during user entry;
- be encrypted or hashed when stored in the password database; and
- not be e-mailed to the user, except in the case of expiring one-time-passwords.
2. In addition, non-consumer (employees and administrators) passwords must:
- contain alphabetic and numeric characters;
- change every 90 days;
- enforce a password history of 8 previously used passwords;
- enforce account lockouts after 5 failed attempts within a 24-hour period;
- enforce a session timeout of 30 minutes; and
- be changed from default or vendor supplied values.
3. SSL must be used when username and password credentials are transmitted. SSL is recommended for subsequent page views in order to protect the session cookie.
4. User self-registration mechanisms must require email confirmation in order to validate legitimate users. This usually requires an e-mail verification link to be sent and followed by the user in order to activate an account.
5. Authentication mechanisms must not provide specific feedback to the user if any portion of the login information is entered incorrectly. The system must only indicate login failure after both the identifier and authentication information has been entered.
6. Access control mechanisms must prevent a user from elevating privileges or accessing functions or data that they are not allowed to access.
7. Cookies must not be used to store any information that would identify a particular user or machine other than a session-id. Passwords must not be stored in cookies.
8. Users must be able to logout of applications requiring authentication. Any active Personally Identifiable Information must be expunged upon session completion.
9. Session-id values used for authentication and session management must be sufficiently randomized to prevent them from being guessed. The session-id value must not be based on authentication credentials and must not be persistent across different sessions.
10. Multi-factor authentication must be used for administrative consoles or access to Content Management Systems.
E. Company Hosting
Hosting
1. The Company hosting provider shall not sub-contract hosting to a third party unless expressly provided for in the Agreement. Fortune Information Security must be notified when there are changes in hosting providers since the execution of the Agreement and original security evaluation.
2. Appropriate physical access controls must exist to prevent unauthorized access, damage or interference to business premises and information (e.g. locked server cages, guarded access, video monitoring, visitor access controls, biometric authentication).
3. All electronic media (such as disks, backup tapes, etc.) and confidential hard copy documents must be appropriately protected from theft or loss. Data contained on such media must be securely destroyed prior to the media’s being discarded.
4. Backups must be performed on a regular basis. All tape backups will be securely maintained off-site and controlled by duly authorized personnel. Credit card and Social Security numbers contained on tape backups must be encrypted.
5. Representatives from Fortune must be allowed to visit the hosting provider’s facilities to observe the physical security controls in place upon request.
6. The hosting provider must review access rights to systems and data periodically.
Infrastructure
7. A firewall must protect the application environment and associated data from the Internet and other internal networks.
8. Inbound and outbound connections through the firewall must be denied unless specifically required and defined by a documented firewall rule.
9. Firewall events must be monitored in order to detect potential security events.
10. Remote administrative access to systems or applications must be performed using two-factor authentication.
11. Operating systems must be securely configured according to a security baseline. This baseline must include removing unnecessary services and changing default, vendor-supplied or otherwise weak user accounts and passwords.
12. All system components must maintain current security patch levels.
13. Anti-virus software must be installed, updated and monitoring activity on Windows-based systems.
14. Administration of systems must be performed using secure protocols such as SSH.
15. Web servers must be hardened according to a secure baseline.
16. Web servers must only allow the HTTP methods GET, HEAD, POST on a production web server. All other methods must be disabled, including TRACE and TRACK.
17. Web servers must be configured to accept requests for only authorized and published directories. Default sites, sample or test files, executable or directory listings must be disabled.
Authentication/Authorization Requirements for Infrastructure
18. User account IDs must not contain confidential information, such as a Social Security number or other Personally Identifiable Information.
19. At a minimum, non-consumer (employees and administrators) passwords must:
- contain eight characters
- contain alphabetic and numeric characters
- change every 90 days
- enforce a password history of 8 previously used passwords
- enforce account lockouts after 5 failed attempts within a 24-hour period
- enforce a session timeout of 30 minutes
- be masked during user entry
- be encrypted or hashed when stored in the password database
- be changed from default or vendor supplied values
- not be e-mailed to the user, except in the case of expiring one-time-passwords
20. Authentication mechanisms must not provide specific feedback to the user if any portion of the login information is entered incorrectly. The system must only indicate login failure after both the identifier and authentication information has been entered.
21. Access control mechanisms must prevent a user from elevating privileges or access functions or data that they are not allowed to access.
Service Level Agreement
If Company provides maintenance Services pursuant to a Work Order under this Agreement, this Section E, paragraphs 22 through 27, includes the terms applicable to such maintenance Services.