- Protection of RandomCoffee proprietary software and other managed systems shall be addressed to ensure the continued availability of data and programs to all authorized parties, and to ensure the integrity and confidentiality of impacted data and configuration controls.
- Failure to follow the policy requirement may result in disciplinary action, up to and including termination.
- This policy provides some of Random Team policies for some key security aspects of Random Team systems. This policy reasonably adheres to industry standards and best practice and reasonably provides safeguards against accidental or unlawful destruction, loss, alteration or unauthorized disclosure or access to covered data.
TermDefinitionData Breachmeans a Security Incident that directly impacts Personal Data.Data Controllermeans the person or organization that determines the purpose and means of the Processing of Personal Data.Firewallmeans a device and/or software that prevents unauthorized and improper transit of access and information from one network to another.Incident Managementmeans the process for detecting, reporting, assessing, responding to, dealing with, and learning from Security Incidents.PasswordA protected, private character string used to authenticate an identity.Personal Datameans any information relating to an identified or identifiable natural personPersonnelmeans Random Team employees (part-time and full-time)Security Eventmeans an identified occurrence of a system, service or network state indicating a possible breach of information security policy, a possible exploitation of a Security Vulnerability or Security Weakness or a previously unknown situation that can be security relevant.Security Incidentmeans a single or series of unwanted or unexpected Security Events that compromise business operations with an impact on Information Security.Security Vulnerabilitymeans a weakness of an existing asset or control that can be exploited by one or more threats.Security Weaknessmeans a weakness that results from the lack of an existing, necessary control.Restricted InformationRefer to Data Classification PolicyConfidential InformationRefer to Data Classification PolicyUsernameA unique symbol or character string that is used by a system to identify a specific user.VirusComputer software that replicates itself and often corrupts computer programs and data.
4. Data Encryption
- To provide data confidentiality in the event of accidental or malicious data loss, all Restricted, Confidential or Internal Information & data should be encrypted at rest.
- Encryption of data at rest should use at least AES 256-bit encryption.
- Strong cryptography and security protocols, such as TLS 1.2 or IPSEC, are required to safeguard Restricted, Confidential or Internal Information & data during transmission.
- Key exchange must use RSA or DSA cryptographic algorithms with a minimum key length of 2048 bits and minimum digest length of 256.
- Digital signatures must use RSA, DSS with a minimum key length of 2048 bits and minimum digest length of 256.
- Hashed data must be salted and must use bcrypt with SHA-256 or higher.
- Restricted, Confidential or Internal Information & data may not be stored on equipment not owned or managed by Random Team.
- Documented policies and process should be implemented to ensure appropriate key management.
5. Password Policy
- Unless otherwise specified within this Security Policy, the following security requirements should be adhered to when creating passwords:
- Minimum of eight (8) characters in length, containing characters from the following four categories:
- English uppercase characters (A through Z)
- English lowercase characters (a through z)
- Base 10 digits (0 through 9)
- Non-alphabetic characters (e.g., !, $, #, %)
- Passwords history should be kept for the previous six (6) passwords and passwords should be unique across the password history.
- Maximum password age is ninety (90) days.
- Must not be the same as or include the user id or be visible when entered.
- Must not be easily guessable.
- User accounts should be locked after five (5) incorrect attempts.
- Lockout duration should be set to a minimum of twenty-four (24) hours or until an administrator resets the user’s ID.
- If a session has been idle for more than twenty (20) minutes, the user should be required to re-enter the password to re-activate access.
- The following should be adhered to when managing user passwords:
- Verify user identity before performing password resets.
- Resetting passwords should involve re-entering old password.
- Role based access to all systems should be implemented, including individually assigned username and passwords.
- Usernames and passwords should not be shared, written down or stored in easily accessible areas.
- Assigning multiple user names to users should be limited. However, when multiple usernames are assigned to Personnel, different passwords should be used with each username.
- Group, shared, or generic accounts and passwords should not be used unless approved by Security Management (e.g., service accounts) and should follow associated information security standards.
- Special administrative accounts, such as root, should implement additional controls, such as alerting, to detect and/or prevent unauthorized usage.
- Change any default passwords on systems after installation.
- Render all passwords unreadable during transmission and storage using strong cryptography as defined in Data Encryption policy.
- Passwords should be protected in storage by hashing following data encryption policy.
- Regular backups of data, applications, and the configuration of servers and supporting devices should occur to enable data recovery in the event of a disaster or business continuity event.
- There should be a backup system in place for Random Team core database able to recover data in the event of a disaster to the minute within a day.
- Backup snapshots should be encrypted following data encryption policy and there should be a minimum of 7 daily backups, 4 weekly backups and 3 monthly backups.
- Backups should be stored in a physically and logically secure location.
7. Virus and Malware Protection
- Up to date anti-virus software for the detecting, removing and protecting of suspected viruses should be installed on all servers and laptops.
- Anti-virus software should be updated regularly for all laptops with the latest anti-virus patches and/or signatures.
- All systems should be built from original, clean master copies to ensure that viruses are not propagated.
- Personnel should inform the IT Department immediately in the event of a possible virus infection.
- Upon notification of a virus infection systems should be isolated from the network, scanned, and cleaned appropriately. Any removable media or other systems to which the virus may have spread should be treated accordingly.
- If a system has been identified as potentially infected and removal/quarantine of the virus/malware cannot be definitively proven, the system should be completely wiped and re-imaged.
- Users impacted by virus related security incidents should be notified as soon as reasonably possible in alignment with incident response procedures.
- Potential virus and malware infections should be immediately reported to Security Management.
8. Incident Management Policy
- Management responsibilities and procedures should be established to ensure a quick, effective, and orderly response to Security Incidents.
- The objectives for Security Incident management should be agreed upon with management, and it should be ensured that those responsible for Security Incident management understand the organization’s priorities for handling Security Incidents.
- Security Events should be reported through appropriate management channels as quickly as possible
- Personnel and contractors using the organization’s information systems and services are required to note and report any observed or suspected Security Weakness in systems or services
- Security Events should be assessed and it should be decided if they are to be classified as Security Incidents.
- Security Incidents should be responded to in accordance with documented procedures.
- Knowledge gained from analyzing and resolving Security Incidents should be used to reduce the likelihood or impact of future incidents.
- Procedures should be defined and applied for the identification, collection, acquisition, and preservation of information, which can serve as evidence.
- Awareness should be provided on topics such as:
- The benefits of a formal, consistent approach to Incident Management (personal and organizational);
- How the program works, expectations;
- How to report Security Incidents, who to contact;
- Constraints imposed by non-disclosure agreements.
- Communication channels should be established well in advance of a Security Incident.
- In the event of a Security Incident, Data Controllers, government bodies and other necessary parties should be notified in a reasonable timeframe, and in compliance with regulatory and other applicable requirements and guidance.
9. Security Weakness, Events, and Incidents
- Identified Security weaknesses should be immediately reported to the Security Management. At no time should an attempt be made to take advantage of an identified Security weakness.
- Security Weaknesses that have been compromised could trigger a Security Event. Security Events shall be analyzed by Security Management to determine whether they are considered Security Incidents, which are required to be addressed in accordance with the documented procedures.
- Security awareness training should be conducted at least once per calendar year. Training should cover information security policies, as well as best practices. In addition, the following should occur:
- Security awareness training should be given at the first onboarding session attended by new employees (usually within two weeks of employment)
- Training should be given to key stakeholders (i.e., incident management, security policy and process, assessment response best practice, etc.)
10. Auditing and Assessments
- Data center providers should have SOC 2 audits performed at least once per calendar year.
- Customers can perform reasonable security assessments once per calendar year, following industry best practices.
11. Patch Management
- Random Team-owned and maintained servers, computers, computer systems & computer networks and electronic communications devices must be updated with the latest but stable patches released by the respective vendors.
- Those responsible for each system, device and application must monitor relevant sources of information which may alert them to a need to act in relation to new security vulnerabilities.
- Patches must be obtained from a known, trusted source.
- The integrity of patches must be verified through such means as comparisons of cryptographic hashes to ensure the patch obtained is the correct, unaltered patch.
- Patches must be tested and assessed before implementation in a preproduction environment mirroring the production environmernt to ensure that there is no negative impact as a result.
- A backup of the production systems must be taken before applying any patch.
- An audit trail of all changes must be created and documented.
(typical CVSS score)
A vulnerability whose exploitation could allow code execution or complete system compromise without user interaction. These scenarios include self-propagating malware or unavoidable common use scenarios where code execution occurs without warnings or prompts. This could include browsing to a web page or opening an email or no action at all.24 hours
(7.0 – 9.9)
A vulnerability whose exploitation could result in compromise of the confidentiality, integrity, or availability of user data, or of the integrity or availability of processing resources. This includes common use scenarios where a system is compromised with warnings or prompts, regardless their provenance, quality, or usability. Sequences of user actions that do not generate prompts or warnings are also covered.7 days
(4.0 – 6.9)
Impact of the vulnerability is mitigated to a significant degree by factors such as authentication requirements or applicability only to non-default configurations. The vulnerability is normally difficult to exploit.30 days
This classification applies to all other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences.90 days or dismiss as not a risk
12. Endpoint Security
- Users should shutdown, logout or lock laptops when leaving for any length of time.
- Laptops should be restarted periodically.
- Laptops should adhere to virus and malware protection policy.
- Define and implement endpoint build standards that include, at a minimum, the following:
- Defined configurations based on industry best practice;
- Authorized software
- Laptop access to the Internet should be controlled
13. Mobile Computing
- Ensure appropriate controls are in place to mitigate risks to protected information from mobile computing and remote working environments.
- Data loss prevention processes and tools should be implemented to identify and/or prevent data loss.
- Use of personally owned devices should comply to information security policy if used to access Restricted, Confidential or Internal Information & data.
- Devices owned by personal should never be used to access customer data, unless appropriate controls approved and monitored by Security Management have been implemented.
- Devices owned by Personal or authorized parties are not allowed to connect to the corporate or production networks.
14. Network Security
- Access to internal and external network services that contain Users’ data should be controlled through:
- Network access control lists (NACLs), or equivalent.
- Firewall policies, or equivalent
- Security groups, or equivalent.
- IP whitelists, or equivalent
- A multi-tier architecture that prevents direct access to data stores from the internet.
- Usage of role-based access controls (RBAC) should be implemented to ensure appropriate access to networks
- Two-factor authentication for remote access should be implemented as defined in the access control policy.
- Firewalls, routers, and access control lists, or equivalent access controls, should be used to regulate network traffic for connections to/from the Internet or other external networks, as follows:
- Configuration standards should be established and implemented.
- Access control policy should limit inbound and outbound traffic to only necessary protocols, ports, and/or destinations.
- Internal IP address ranges should be restricted from passing from the Internet into the DMZ or internal networks.
- All inbound internet traffic should terminate in the DMZ.
- Only properly established connections should be allowed into Random Team networks.
- The use of all services, protocols, and ports allowed to access Random Team networks should be reviewed on a periodic basis, at a minimum every six (6) months, for appropriate usage and control implementation.
- All rule set modifications should be reviewed and approved by Security Management prior to implementation.
- Network equipment should be configured to close inactive sessions.
- Remote access servers should be placed in the firewall DMZs.
- Network intrusion detection systems (IDS) should be implemented and monitored by Security Management.
- Routers, Hubs and Switches
- LAN equipment, hubs, bridges, repeaters, routers and switches should be kept in physically secured facilities.
- Network equipment access should be restricted to appropriate Personnel only. Other staff and contractors requiring access are required to be supervised.
- Network equipment access should occur over encrypted channels as defined in the data encryption policy. Access via unencrypted protocols (http, ftp, tftp) should not occur. Unused channels should be disabled.
- Wireless access points and controllers should not be allowed to connect to the production network.
- Unnecessary protocols should be removed from routers and switches.
- Secure, encrypted VPN connections to other networks controlled by iCIMS or outside entities, when required, must be approved by Information Security.
- Configuration of routers and switches should be documented and align with industry best practice. This should include changing any vendor-supplied defaults (passwords, configurations, etc.) before installing in production.
15. Wireless Network Security
- Wireless networks should be encrypted as defined by Random Team encryption policy.
- Personnel and authorized third parties are not allowed to install unauthorized wireless equipment.
- All Wi-Fi bridges, routers and gateways should be physically secured.
- SSIDs and default usernames and passwords must be modified prior to implementation in a production environment.
16. Test, Development and Production Environments
- Test software upgrades, security patches and system and software configuration changes before deployment, including but not limited to the following:
- Validate proper error handling.
- Validate secure communications.
- Validate proper role-based access control (RBAC).
- Performance impact
- Development, test, and production environments must be segregated.
- Separation of duties must exist between development, test, and production environments.
- Use only scrubbed/anonymized data for testing and/or development.
- Remove test data and accounts before production systems become active.
- Follow change control procedures for all changes to system components. The procedures should include testing of operational functionality.
- Manage all code through a Version Control System to allow viewing of change history and content.
- Ensure that a Quality Assurance (QA) methodology is followed using a multi-phase quality assurance release cycle that includes security testing.
- Deliver security fixes and improvements aligning to a pre-determined schedule based on identified severity levels.
- Ensure that software is released only via production managed change control processes, with no access or involvement by the development and test teams.
- Develop all web applications (internal and external, including web administrative access to application(s)) based on secure coding best practice. Cover, at a minimum, prevention of common OWASP Top 10 coding vulnerabilities in software development processes, including the following:
- Cross-site scripting (XSS).
- Injection flaws, including SQL, LDAP and Xpath.
- Malicious file execution.
- Insecure direct-object references.
- Cross-site request forgery (CSRF).
- Information leakage and improper error handling.
- Broken authentication and session management.
- Insecure communications.
- Failure to restrict URL access.
- Awareness training regarding secure coding must be conducted at least once per calendar year. The curriculum must be approved by Security Management.
18. Transfer of Information
- To protect the confidentiality of Information in transit:
- Ensure that all data in transit is either encrypted and/or the transmission channel itself is encrypted following data encryption policy.
- Monitor all data exchange channels to detect unauthorized information releases.
19. Messaging Security
- All incoming email should be scanned for viruses, phishing attempts, and spam.
- Outgoing email should have data loss prevention (DLP) monitoring in place.
20. Removable Media
- Use of removable media should be excluded when possible.
- All removable media brought in from outside Random Team should be scanned for viruses/malware prior to use. Any identified malware/viruses should be removed prior to use.
- Restricted Information & data is prohibited on any kind of removable device, unless the device is encrypted following data encryption policy. Notwithstanding the foregoing, if stored or cached information resides on a removable device, Personnel will follow company policies and procedures to mitigate the risk of a Data Breach.
- Individuals in sensitive positions, with access to Restricted or Confidential Information & data, should not store such data on removable media, unless required by their role and approved by Security Management.
21. Vendor/Partner Risk Management
- Vendor and partner risk management policies and processes should be defined to verify that vendors comply with security policies.
- Vendor and partner contracts should include language requiring adherence to security policy requirements or their equivalent.
- Critical vendors should be reviewed at least once per calendar year, to ensure continued alignment with security policies.