Agreed Data Security Standards

Why AGREED

To boost engagement, facilitate career development, and increase organizational performance, the client organization is utilizing AGREED as an innovation and agreements platform.

Disposition

AGREED holds the protection of sensitive data at the utmost level of seriousness. AGREED’s employees and contractors are trained to be hyper-aware and cognizant of our commitment to decrease exposure, limit access, and (at the appropriate time) destroy our copy of sensitive data.

Relevant Parties

1.) Organizations working with AGREED and 2.) Specific AGREED employees working with a client (only seasoned, experienced, highly trustworthy employees handle sensitive data)

Scope

Data associated with Sectioclient organization and its employees, including some financial data and Personally Identifiable Information (PII) that AGREED needs to receive and maintain.

The AGREED platform is hosted on Amazon Web Services (AWS) servers. These servers are locked down with the highest standards of cyber security, trusted by a large portion of firms in the Fortune 500 and many banking and securities firms.

AGREED utilizes Auth0 multi-factor authentication, which is compliant with the top standards.

AGREED uses JavaScript cross-origin blocking to prevent SQL injections.

In addition, AGREED utilizes the highest standards of internal built-in security and controls in order to maintain appropriate levels of access and security for different types of data.

1. First Name

2. Last Name

3. Personnel

4. Business Unit

5. Manager

6. Work phone number

7. Work email

8. Profile image

The following types of data will be hosted on the Agreed.io platform for access by specified individuals within client organizations. Strict measures are taken to limit access.

1. Baseline (snapshot) Revenues

2. Baseline (snapshot) Expenses

3. Baseline (snapshot) Broad Compensation Ranges for job families (known as Functional Titles)

One or more AGREED employees or contractors will receive and analyze (then destroy) compensation data for the sole purpose of creating anonymized, equally distributed baseline pay ranges for each group of personnel (called Functional Titles). This information is held securely during Set-Up and is destroyed at the end of the period. Typically, only one or two AGREED associates handle this data. Each is trained and held accountable to the highest standards of data security. This data resides on encrypted servers (AWS).

AGREED software facilitates several exciting innovations and organizational agreement functionalities. Employees of the client organization will have the opportunity to enter ideas and associated details directly into the AGREED platform. These ideas are then reviewed, revised, and validated by other employees within the same client organization. Finally, the platform enables employees to implement these ideas and track success. 

The Agreed.io enterprise software platform is protected by Auth0 dual authentication login and hosted on Amazon Web Services. The following describes the protocols and compliance certifications of Auth0 and AWS.

Auth0 Dual Authentication – Compliance

ISO27001

Auth0 is ISO27001 certified by a third party, managing information security risk in such a way as to comply with a robust design, implementation and continuous monitoring framework.

SOC 2 Type II

Auth0 has completed a full third-party SOC 2 Type II audit - an independent auditor has evaluated the product, infrastructure, and policies, and certifies that Auth0 complies with their stringent requirements.

ISO27018

Auth0 is ISO27018 certified by a third party, complying with security and privacy guidelines for managing PII as a cloud service provider.

EU-US Privacy Shield Framework

Auth0 conforms with the brand-new EU-US Privacy Shield Framework for regulating privacy in data flows between the European Union and the United States. This Framework replaces the EU-US Safe Harbor Framework repudiated in 2015.

Gold CSA STAR

Auth0 has achieved a Level 2 audit Gold CSA Star certification for its cloud service security capabilities.

Amazon Web Services (AWS) Data Security Protocols

The Amazon Web Services (AWS) data center and network architecture are built to meet the requirements of the most security-sensitive organizations. Security in the cloud is much like security in on-premises data centers—only without the costs of maintaining facilities and hardware. Because it's in the cloud, AGREED doesn't have to manage physical servers or storage devices. Instead, we use AWS's software-based security tools to monitor and protect the flow of information into and out of our cloud resources.

AWS Compliance

AWS Cloud Compliance enables you to understand the robust controls in place at AWS to maintain security and data protection in the cloud. As systems are built on top of AWS Cloud infrastructure, compliance responsibilities will be shared. By tying together governance-focused, audit-friendly service features with applicable compliance or audit standards, AWS Compliance enablers build on traditional programs. This helps customers to establish and operate in an AWS security control environment.

The IT infrastructure that AWS provides to its customers is designed and managed in alignment with best security practices and a variety of IT security standards. The following is a partial list of assurance programs with which AWS complies:

• SOC 1/ISAE 3402, SOC 2, SOC 3

• FISMA, DIACAP, and FedRAMP

• ISO 9001, ISO 27001, ISO 27017, ISO 27018

AWS provides customers a wide range of information on its IT control environment in whitepapers, reports, certifications, accreditations, and other third-party attestations. More information is available in this Risk and Compliance whitepaper and the AWS Security Center. 

Data (such as spreadsheets to be uploaded into the Agreed.io platform) which is handled internally by .....Agreed.io is hosted on Azure. The following describes the protocols and compliance certifications of AWS.

All files in SharePoint Online are protected by unique, per-file keys that are always exclusive to a single tenant. The keys are either created and managed by the SharePoint Online service, or when the Customer Key is used, created and managed by customers. When a file is uploaded, encryption is performed by SharePoint Online within the context of the upload request, before being sent to Azure storage. When a file is downloaded, SharePoint Online retrieves the encrypted customer data from Azure storage based on the unique document identifier and decrypts the customer data before sending it to the user. Azure storage has no ability to decrypt, or even identify or understand the customer data. All encryption and decryption happen in the same systems that enforce tenant isolation, which are Azure Active Directory and SharePoint Online.

Several workloads in Office 365 store data in SharePoint Online, including Microsoft Teams, which stores all files in SharePoint Online, and OneDrive for Business, which uses SharePoint Online for its storage. All customer data stored in SharePoint Online is encrypted (with one or more AES 256-bit keys) and distributed across the data center as follows. (Every step of this encryption process is FIPS 140-2 Level 2 validated. For additional information about FIPS 140-2 compliance, see FIPS 140-2 Compliance.)

• Each file is split into one or more chunks, depending on file size. Each chunk is encrypted using its own unique AES 256-bit key.

• When a file is updated, the update is handled in the same way: the change is split into one or more chunks, and each chunk is encrypted with a separate unique key.

• These chunks – files, pieces of files, and update deltas – are stored as blobs in Azure storage that are randomly distributed across multiple Azure storage accounts.

• The set of encryption keys for these chunks of customer data is itself encrypted.

• The keys used to encrypt the blobs are stored in the SharePoint Online Content Database.

• The Content Database is protected by database access controls and encryption at rest. Encryption is performed using Transparent Data Encryption (TDE) in Azure SQL Database. (Azure SQL Database is a general-purpose relational database service in Microsoft Azure that supports structures such as relational data, JSON, spatial, and XML.) These secrets are at the service level for SharePoint Online, not at the tenant level. These secrets (sometimes referred to as the master keys) are stored in a separate secure repository called the Key Store. TDE provides security at rest for both the active database and the database backups and transaction logs.

• When customers provide the optional key, the customer key is stored in Azure Key Vault, and the service uses the key to encrypt a tenant key, which is used to encrypt a site key, which is then used to encrypt the file level keys. Essentially, a new key hierarchy is introduced when the customer provides a key.

• The map used to re-assemble the file is stored in the Content Database along with the encrypted keys, separately from the master key needed to decrypt them.

• Each Azure storage account has its own unique credentials per access type (read, write, enumerate, and delete). Each set of credentials is held in the secure Key Store and is regularly refreshed. As described above, there are three different types of stores, each with a distinct function:

• Customer data is stored as encrypted blobs in Azure storage. The key to each chunk of customer data is encrypted and stored separately in the Content Database. The customer data itself holds no clue as to how it can be decrypted.

• The Content Database is a SQL Server database. It holds the map required to locate and reassemble the customer data blobs held in Azure storage as well as the keys needed to encrypt those blobs. However, the set of keys is itself encrypted (as explained above) and held in a separate Key Store.

• The Key Store is physically separate from the Content Database and Azure storage. It holds the credentials for each Azure storage container and the master key to the set of encrypted keys held in the Content Database.

Each of these three storage components – the Azure blob store, the Content Database, and the Key Store – is physically separate. The information held in any one of the components is unusable on its own. Without access to all three, it is impossible to retrieve the keys to the chunks, decrypt the keys to make them usable, associate the keys with their corresponding chunks, decrypt each chunk, or reconstruct a document from its constituent chunks.

BitLocker certificates, which protect the physical disk volumes on machines in the datacenter, are stored in a secure repository (the SharePoint Online secret store) that is protected by the Farm key.

The TDE keys that protect the per-blob keys are stored in two locations:

• The secure repository, which houses the BitLocker certificates and is protected by the Farm Key

• In a secure repository managed by Azure SQL Database.

The credentials used to access the Azure storage containers are also held in the SharePoint Online secret store and delegated to each SharePoint Online farm as needed. These credentials are Azure storage SAS signatures, with separate credentials used to read or write data, and with the policy applied so that they auto-expire every 60 days. Different credentials are used to read or write data (not both) and SharePoint Online farms are not given permissions to enumerate.