Security and data protection

[Msant77s]

Dear, I wanted to ask if anyone knows where I can find answers to these technical queries?
I have tried to consult Google about this through different means and I am not getting answers. These are questions requested by the IT and Security area of ​​the organizations where I want to incorporate Appsheet, however no one gives me answers.
I need answers and support on this information, in the Appsheet documentation there is nothing or everything very vague in the answers.

4.1 How do you test the security of your network and applications? Internal, third parties or both? If so, what is the cadence? Explain your methodology
4.2 Please summarise or attach your network vulnerability management processes and procedures (specifying who executes the procedures and the tools used)?
4.3 Please summarise or attach your application vulnerability management processes and procedures (specifying who executes the procedures and the tools used)?
4.4 How do you regularly evaluate patches and updates for your infrastructure?
4.5 How does the criticality of the patch (critical, high, medium, low) affect deployment guidelines?
4.6 Are all endpoint laptops that connect directly to production networks centrally managed?
4.7 Describe both standard employee issued device security configuration/features and required BYOD configurations. (Login Password, antimalware, Full Disk Encryption, Administrative Privileges, Firewall, Auto-lock, etc.)
4.8 What systems do you have in place that mitigate classes of web application vulnerabilities? (e.g.: WAF, proxies, etc)
4.9 Do you have operational breach detection sytems, deception solutions and/or anomaly detection with alerting?
4.10 Describe your secrets management strategy:(auth tokens, passwords, API credentials, certificates)
4.11 Are all security events (authentication events, SSH session commands, privilege elevations) in production logged?
4.12 Is the production network segmented in to different zones based on security levels?
4.13 What is the process for making changes to the network configuration?
4.14 What cryptographic frameworks are used to secure a) data in transit over public networks, b) passwords, c) data at rest?
4.15 How are crytographic keys(key management system, etc) managed within your system?
4.16 Describe your security awareness program for personnel
5.1 How do you log and alert on relevant security events? (this includes the network and application layer)?
5.2 Describe or attach your Security Incident Response Program?
5.3 Do you have formally defined criteria for notifying a client during an incident that might impact the security of their data or systems? What are your SLAs for notification?
6.1 How do you ensure code is being developed securely?
6.2 How do you train developers in SSDLC / Secure Coding Practices?
7.1 Please describe how you authenticate users: If passwords are used, describe complexity requirements, and how passwords are protected. If SSO is supported, please describe the available options. If different service tiers are available, please describe.
7.2 Does your application enable custom granular permissions and roles to be created? Please describe the roles available
7.3 Which audit trails and logs are kept for systems and applications with access to customer data?
7.4 How does your application store API keys?
8.1 How do you conduct internal audits (audits lead by your personnel) of the service? please describe the scope, remediation process and frequency of audits.
8.2 How do you conduct external (third-party) audits of the service? please describe the scope and frequency of audits.
8.3 Please provide a copy of the most recent report (as per Service Introduction tab, section 5).

[baba_sawane]

Honestly I don't think anyone would answer them (they have no reason to). I would rather answer most of them based on my own app management strategy and information collected through documentation, as it's not clear wether they want to inspect the app management in itself or the tool provider.

Which means that you might need to create the lacking documentation and make sure it's applied to match their criterias. 

Ex : 4.4 How do you regularly evaluate patches and updates for your infrastructure?

>  I would create a document stating how I evaluate updates, when and on what conditions.

[Msant77s]

I understand, but according to the shared responsibility model established between Google Cloud and its clients, in SAAS services such as Appsheet. The client is responsible for the Management of the Content that will be uploaded to the cloud, for the access policies to the system and the use that is given to the system. But Appsheet, that is, Google Cloud, where the entire Appsheet infrastructure and Appshset databases are hosted,  is responsible for the security of the underlying infrastructure, therefore that information must be provided by Appsheet or Google Cloud in that case, all of these The vast majority of questions are about the infrastructure and not about the management that I do of the applications, since as an application creator I will never be able to attest to this without the information.

I am a client who wants to know how their applications work securely so that I can transmit security to the companies that work with me and that want to adopt Appsheet, but without support and transparency from Appsheet it is difficult.

[Msant77s]

What I have investigated from what is shown in the google cloud documentation (of which I am not sure if the interpretation is correct), is the following:
There are also questions to which I could not get answers.
4.Proactive Security
4.1 How do you check network and application security? Internal, third party or both? If so, what is the cadence? Explain your methodology

Google Cloud uses a combination of internal and third-party security tests to evaluate the security of its network and applications. Additionally, it collaborates with the security research community to quickly address vulnerabilities and prevent them to the extent possible.

In terms of methodology, Google Cloud uses a variety of security testing techniques, including penetration testing, vulnerability scanning, load testing, and stress testing. These tests are performed on an ongoing basis and are integrated into the Google Cloud software development process.

Additionally, Google Cloud uses security monitoring tools to collect information about internal network traffic, employee actions on systems, and external knowledge of vulnerabilities. The information collected is stored in a single place for unified security analysis.

Privacy and internal security events:

https://cloud.google.com/docs/security/overview/whitepaper?hl=es-419#internal_security_and_privacy_e...

Internal audit and compliance specialists:

https://cloud.google.com/docs/security/overview/whitepaper?hl=es-419#internal_audit_and_compliance_s...

Assistance with compliance requirements:

https://cloud.google.com/docs/security/overview/whitepaper?hl=es-419#compliance-requirements

4.2 Please summarize or attach your network vulnerability management processes and procedures (specifying who executes the procedures and the tools used).

The Google Cloud network uses multiple layers of defense (defense in depth) to help protect the network against external attacks. Only authorized services and protocols that meet our security requirements are allowed to pass through, any other attempts are automatically eliminated. To enforce network separation, we use firewalls and access control lists. All traffic is routed through GFE servers to help detect and stop malicious requests and distributed denial of service (DSD) attacks. Logs are routinely evaluated for any exploitation of programming errors. Access to network devices is restricted to authorized employees only.

Google Cloud has an internal vulnerability management process that uses a combination of commercial, open source, and internally developed tools to identify and address security vulnerabilities.

The internal vulnerability management process actively searches for security threats across all technology stacks. A combination of internal, commercial, open source, and purpose-built tools are used in this process, including the following:

*Quality control processes

*Software security reviews

*Intensive manual and automated penetration testing, including extensive Red Team exercises

*External audits

The Google Cloud vulnerability management team is responsible for tracking and addressing identified vulnerabilities. Additionally, Google Cloud collaborates with the security research community to quickly address vulnerabilities and prevent them to the extent possible.

To improve threat detection, the vulnerability management team focuses on high-quality indicators that separate noise from signals that indicate real threats. Patch bounty programs are also run to encourage collaboration with the open source community and improve vulnerability detection.

Vulnerability Management:

 https://cloud.google.com/docs/security/overview/whitepaper?hl=es-419#vulnerability_management

Prevention against malicious software:

https://cloud.google.com/docs/security/overview/whitepaper?hl=es-419#malware_prevention

Security monitoring:

https://cloud.google.com/docs/security/overview/whitepaper?hl=es-419#security_monitoring

Security benefits of our global network:

https://cloud.google.com/docs/security/overview/whitepaper?hl=es-419#security_benefits_of_our_global...

Google Vulnerability Bounty Program Rules:

https://bughunters.google.com/about/rules/6625378258649088/google-and-alphabet-vulnerability-reward-...

How Google protects physical-logical space in a data center:

https://cloud.google.com/docs/security/physical-to-logical-space?hl=es-419

Google Infrastructure Security Design Overview:

https://cloud.google.com/docs/security/infrastructure/design?hl=es-419#introduction

4.3 Please summarize or attach your application's vulnerability management processes and procedures (specifying who executes the procedures and the tools used).

Google Cloud Application Vulnerability Management.

*Secure software development practices are used such as source code protection, two-party reviews before integrating changes, and the use of libraries designed to prevent common vulnerabilities such as XSS in web applications.

*Automated testing tools such as fuzzing, static code analysis and web security scans are available to detect vulnerabilities in applications.

*The security team performs manual security reviews on high-risk applications. These reviews are carried out by experts in web security, cryptography and operating system security.

*There is a vulnerability bounty program that offers incentives to external researchers to responsibly report bugs found in Google applications.

*For third-party and open source code that is integrated into applications, version tracking and periodic review are carried out considering security requirements.

*The information security team is responsible for training development engineers in secure coding practices and the use of vulnerability testing tools.

Software development practices:

https://cloud.google.com/docs/security/overview/whitepaper?hl=es-419#software_development_practices

Technology with a central focus on security:

https://cloud.google.com/docs/security/overview/whitepaper?hl=es-419#technology_with_security_at_its...

Google Infrastructure Security Design Overview:

https://cloud.google.com/docs/security/infrastructure/design?hl=es-419#introduction

4.4 How do you regularly evaluate patches and updates to your infrastructure?

To regularly evaluate patches and updates to its infrastructure, Google uses a pipeline automation approach. This involves creating automation pipelines that continually assess vulnerability status, verify patches, and flag incorrect or partial resolution. Additionally, the vulnerability management organization focuses on high-quality indicators that separate the noise from indicators that indicate real threats. The organization also encourages interaction with the industry and the open source community, and runs a Patch Reward Program for Tunami Network Security Analysis, which rewards developers who create open source detectors for vulnerabilities.

https://cloud.google.com/docs/security/overview/whitepaper?hl=es-419#vulnerability_management

Manage changes and updates to the infrastructure

1- Steps of code change:

Developer makes a change to a microservice protected by the BAB.

The change is pushed to the central code repository with mandatory review.

Code review is performed and after approval it is submitted to the central build system.

In the build system, a package is created with a signed and verifiable build manifest certificate.

2- Validation by the Binary Authorization for Borg (BAB):

At deployment time, the BAB validates the build pipeline's signed certificate to ensure that the process was followed.

3- Update Control by Borg:

Borg controls all workload updates with a reliability model.

Minimal disruption to services is guaranteed, whether it's a routine release or an emergency security patch.

4- Traffic Migration by GFE:

GFE (Front End) moves traffic to the new deployment using load balancing to ensure continuity of operations.

All workloads require isolation. If the workload is less reliable because the source code originates outside of Google, it can be deployed in a gVisor-protected environment or use other isolation layers. This isolation helps contain an adversary who manages to compromise an application.

Links to Get More Information:

For more information about this process, see Development and Production Process:

https://cloud.google.com/docs/security/binary-authorization-for-borg?hl=es-419#our_development_and_p...

BeyondProd:

https://cloud.google.com/docs/security/beyondprod?hl=es-419

Code change:

https://cloud.google.com/docs/security/beyondprod?hl=es-419#making_a_code_change

Binary Authorization for Borg (BAB)

https://cloud.google.com/docs/security/binary-authorization-for-borg?hl=es-419

4.5 How does patch criticality (critical, high, medium, low) affect deployment guidelines?

4.6 Are all endpoint laptops that connect directly to production networks managed centrally?

4.7 Describe both standard employee-issued device security settings/features and required BYOD configurations. (Login password, anti-malware, full disk encryption, administrative privileges, firewall, auto-lock, etc.)

Standard Employee-Issued Device Configuration/Security Features

Two-Factor Authentication (2FA):

Mandatory two-factor authentication has been implemented using U2F (Universal 2nd Factor) compatible security keys instead of One-Time Passwords (OTP). This strengthens authentication and protects against phishing attempts.

Monitoring and Updating Devices:

Client devices used by employees to operate the infrastructure are monitored.

Operating system images are kept up to date with security patches.

The applications that employees can install on their devices are controlled.

Application Analysis:

There are systems that analyze user-installed applications, downloads, browser extensions and browser content to determine their suitability for corporate devices.

Zero Trust Security:

Connecting to the corporate LAN is not the primary mechanism for granting access privileges.

A zero-trust security approach is used that exposes internal applications only to devices managed and connected from expected geographic locations and networks.

Required BYOD Configurations:

Trust Certificate for Devices:

Client devices must be trusted and based on a certificate issued to the individual machine, with assertions about its configuration, such as having up-to-date software.

Limitation and Supervision of Administrative Access:

Administrative access to the infrastructure is limited and actively monitored.

We are working to eliminate the need for privileged access through secure and controlled automation of tasks.

Limited APIs and Two-Party Approvals:

Limited APIs are exposed for debugging without exposing sensitive data.

Two-party approvals are required for certain sensitive actions performed by human operators.

Registration and Supervision of Access to End User Data:

Access to end-user information by Google employees can be logged using low-level infrastructure hooks. Our security team monitors access patterns and also investigates unusual events. For more information, see Managing privileged access in Google Cloud.

https://services.google.com/fh/files/misc/privileged-access-management-gcp-wp.pdf?hl=es-419

We use binary authorization for Borg to protect the supply chain against the risk of insider users. Additionally, our investment in BeyondProd helps protect user data on Google infrastructure and establish trust in our services.

https://cloud.google.com/docs/security/beyondprod?hl=es-419#introduction

Threat Monitoring:

Threat Analysis Group:

Google has a dedicated threat analysis group that monitors threat actors and evolves tactics and techniques to improve the security of Google products.

Google Cloud Threat Intelligence and VirusTotal:

Google Cloud uses Google Cloud Threat Intelligence for Chronicle and VirusTotal to monitor and respond to various types of malware.

Threat Horizons Report:

Threat Horizons Report, for more information on threat monitoring activities.

Storage devices, including hard drives, solid-state drives, and non-volatile in-line memory modules (DIMMs), use technologies such as full disk encryption (FDE) and drive locking to protect data in storage. repose. When a storage device is removed, authorized individuals verify that the disk is erased by writing zeros to the drive. They also perform a multi-step verification process to ensure that the drive does not contain data. If a drive cannot be erased for any reason, it is physically destroyed. Physical destruction is done using a shredder that breaks the disk into small pieces, which are then recycled at a secure facility. Each data center adheres to strict deletion policies and any deviations are addressed immediately. For more information, see Deleting data on Google Cloud Platform.

Hardware Tracking and Removal:

https://cloud.google.com/docs/security/overview/whitepaper?hl=es-419#hardware_tracking_and_disposal

4.8 What systems do you have in place to mitigate types of web application vulnerabilities? (for example: WAF, proxies, etc.)

In addition to the source control protections and two-party review process described above, Google uses libraries that prevent developers from incorporating certain classes of security bugs. For example, libraries and frameworks that eliminate XSS vulnerabilities in web applications. We also use automated tools such as fuzzing tests, static analysis tools, and web security scanners to automatically detect security errors.

Secure software development:

https://cloud.google.com/docs/security/infrastructure/design?hl=es-419#safe_software_development

4.9 Do you have operating systems for detecting violations, deception solutions and/or anomaly detection with alerts?

Intrusion detection

We use sophisticated data processing pipelines to integrate host-based indicators on individual devices, network-based indicators from various monitoring points in the infrastructure, and indicators from infrastructure services. Rules and artificial intelligence created from these pipelines send warnings to operational security engineers about potential incidents. Our investigation and incident response teams assess, investigate and respond to these potential incidents 24 hours a day, 365 days a year. We conduct Red Team exercises to measure and improve the effectiveness of our detection and response mechanisms.

Intrusion detection:https://cloud.google.com/docs/security/infrastructure/design?hl=es-419#intrusion_detection

4.10 Describe your secrets management strategy: (authentication tokens, passwords, API credentials, certificates)

Google implements a secrets management strategy based on the principle of "secrets as a service", meaning that secrets are stored and managed centrally in a secure and scalable service. For secret management, Google Cloud offers several services, including Cloud KMS for managing encryption keys, Cloud IAM for managing access permissions and roles, and Secret Manager for managing sensitive secrets like passwords and authentication tokens. .

Additionally, Google Cloud recommends security practices such as regularly rotating passwords and limiting access permissions to secrets only to users and services that need them to perform their functions. In short, Google implements a comprehensive and secure secret management strategy to protect its customers' sensitive data.

Privileged Access Management in Google Cloud Plaorm:

 https://services.google.com/fh/files/misc/privileged-access-management-gcp-wp.pdf?hl=es-419

4.11 Are all security events (authentication events, SSH session commands, privilege elevations) logged in production?

yes, the "Detect and remediate unauthorized access" section of the attached document "privileged-access-management-gcp-wp.pdf" describes how Google Cloud logs all security events in production, including authentication events, session commands SSH and elevations of privileges. In addition, it is explained that Google has a detailed logging system to record all security events and access to platform resources. Logs are divided into three categories: customer logs, administrative access logs, and deployment integrity logs.

https://services.google.com/fh/files/misc/privileged-access-management-gcp-wp.pdf?hl=es-419

4.12 Is the production network segmented into different zones based on security levels?

Google uses a "least privilege" approach in which access to customer data, critical operations on production systems, and source code modifications are tightly controlled by manual and automated verification systems. Additionally, employees can only access resources necessary to perform their jobs and must provide a valid justification for accessing customer data. Google uses a layered security approach to protect customer data.

Privileged Access Management in Google Cloud Plaorm:

https://services.google.com/fh/files/misc/privileged-access-management-gcp-wp.pdf?hl=es-419.P. 3

4.13 What is the process for making changes to the network configuration?

4.14 What cryptographic frameworks are used to protect a) data in transit over public networks, b) passwords, c) data at rest?

a) To protect data in transit over public networks, Google makes HTTPS encryption available (also known as SSL or TLS connection). Google servers support the exchange of ephemeral elliptic curve Diffie-Hellman cryptographic keys signed with RSA and ECDSA. These perfect forward secrecy (PFS) methods help protect traffic and minimize the impact of a compromised key or cryptographic advance. (page 11- Doc:"3.0 Data Processing and Security Terms for AppSheet Services ")

b) When passwords are used for authentication (for example, login to workstations), password policies are implemented that follow at least industry standard practices. These standards include restrictions on password reuse and sufficient password strength. To access extremely sensitive information (for example, credit card data), Google uses hardware tokens. (page 12- Doc:"3.0 Data Processing and Security Terms for AppSheet Services ")

c) To protect data at rest, Google uses advanced encryption techniques. Data is encrypted at rest using 256-bit AES encryption. Additionally, Google uses data fragmentation and dispersion techniques to ensure that a single customer's data is not stored on a single physical disk. (page12- Doc:"3.0 Data Processing and Security Terms for AppSheet Services")

Default encryption at rest:

https://cloud.google.com/docs/security/encryption/default-encryption?hl=es-419

Encryption layers:

https://cloud.google.com/docs/security/encryption/default-encryption?hl=es-419#layers_of_encryption

Encryption at the infrastructure and hardware layer:

https://cloud.google.com/docs/security/encryption/default-encryption?hl=es-419#hardware

Encryption at the storage device layer:

https://cloud.google.com/docs/security/encryption/default-encryption?hl=es-419#encryption_at_the_sto...

Key Management:

https://cloud.google.com/docs/security/encryption/default-encryption?hl=es-419#key_management

Process to access encrypted data fragments:

https://cloud.google.com/docs/security/encryption/default-encryption?hl=es-419#process_for_accessing...

Encryption in transit:

https://cloud.google.com/docs/security/encryption-in-transit?hl=es-419#authentication_integrity_and_...

Google Network Infrastructure:

https://cloud.google.com/docs/security/encryption-in-transit?hl=es-419#googles_network_infrastructur...

Secure data storage:

https://cloud.google.com/docs/security/infrastructure/design?hl=es-419#secure-data

Secure communication on the Internet:

https://cloud.google.com/docs/security/infrastructure/design?hl=es-419#secure-internet

Google Frontend Service:

https://cloud.google.com/docs/security/infrastructure/design?hl=es-419#google-frontend-service

4.15 How are cryptographic keys managed (key management system, etc.) within your system?

Google uses a robust key management system, with multiple levels of security, global replication, automatic rotation, and strict access controls to protect cryptographic keys.

Definitions:

KEK - Key Encryption Key: These are cryptographic keys used to encrypt other keys. KEKs are stored centrally in Google's key management system (KMS).

KMS - Key Management Service: It is Google's centralized system for storing and managing KEKs. The KMS allows you to encrypt, decrypt, rotate and audit the use of KEKs.

DEK - Data Encryption Key: These are the cryptographic keys used to encrypt data or data fragments. Each piece of data is encrypted with its own DEK.

Google uses a hierarchical key management system to manage encryption keys. There is a master key at the top that protects the lower level keys.

Data is fragmented and encrypted with Data Encryption Keys (DEK). These keys are specific to each data fragment.

DEKs are encrypted with Key Encryption Keys (KEK) stored in Google's Key Management Service (KMS).

The KMS is highly replicated globally to provide high availability and low latency.

KMS KEKs are protected by a master key stored in the Root Keystore, which has even greater security.

The Root Keystore master key is distributed globally using a peer-to-peer infrastructure called the Root Key Master Distributor.

There is a well-defined hierarchy of keys to protect data at each level.

Keys are automatically rotated periodically to improve security.

Access to keys is strictly controlled through access control lists.

All key operations are auditable.

Key Management: https://cloud.google.com/docs/security/encryption/default-encryption?hl=es-419#key_management

Process to access encrypted data fragments:

https://cloud.google.com/docs/security/encryption/default-encryption?hl=es-419#process_for_accessing...

Root of trust and encryption key hierarchy:

https://cloud.google.com/docs/security/encryption/default-encryption?hl=es-419#encryption_key_hierar...

Detailed analysis of Cloud Key Management Service:

https://cloud.google.com/docs/security/key-management-deep-dive?hl=es-419

4.16 Describe your staff security awareness program.

5.Reactive Security

5.1 How are relevant security events logged and alerted? (this includes the network and application layer)?

Google's Incident Detection team employs advanced detection tools, signals, and alerting mechanisms that provide an early indication of potential incidents. Incident detection sources include automated analysis of network and system logs, active security testing, internal code reviews, product-specific tools and processes, usage anomaly detection, security alerts for data centers, and workplace services, Google employees, and Google's vulnerability bounty program.

Therefore, Google uses a variety of tools and processes to log and alert on relevant security events, including the network and application layer. These alert mechanisms allow Google to quickly detect and respond to potential security incidents.

https://cloud.google.com/docs/security/incident-response?hl=es-419

5.2 Describe or attach your Security Incident Response Program?

Google will notify Customer promptly and without undue delay after becoming aware of a Data Incident, and will take reasonable steps to minimize damage and secure Customer's data. Additionally, the notification of a Data Incident will describe, to the extent possible, the nature of the Data Incident, the measures taken to mitigate potential risks, and the actions that Google recommends that Customer take to address the Data Incident. Additionally, Section 7.3 "3.0.Data Processing and Security Terms for AppSheet Services" describes Google's security incident response process, which includes identification, containment, analysis, removal, and recovery of security incidents.

The world-class Google Cloud Incident Response Program offers these key features:

A process built on industry-leading incident resolution techniques and better defined to operate efficiently at Google scale.

Pioneering data statistics, machine learning services and monitoring systems to proactively detect and stop incidents.

Dedicated subject matter experts who can respond to any type or size of data incident.

A mature process to quickly inform affected customers, consistent with Google's commitments in our customer agreements and Terms of Service

Data incident response process:

https://cloud.google.com/docs/security/incident-response?hl=es-419

5.3 Have you formally defined the criteria for notifying a customer during an incident that may affect the security of their data or systems? What are your service level agreements for notification?

Yes, the criteria for notifying a customer during an incident that may affect the security of their data or systems have been formally defined. According to Section 7.2.1 of the document: "3.0.Data Processing and Security Terms for AppSheet Services", Google will notify the customer promptly and without undue delay after becoming aware of a Data Incident, and will take reasonable measures to minimize the damage and ensure Customer Data. Additionally, the notification of a Data Incident will describe, to the extent possible, the nature of the Data Incident, the measures taken to mitigate potential risks, and the measures that Google recommends that Customer take to address the Data Incident.

6.Software Supply Chain

6.1 How do you ensure that code is developed safely?

To ensure that code is developed safely, Google uses source control protections and a two-party review process to ensure that code changes are reviewed and approved by multiple parties before they are merged into the codebase. . Additionally, Google uses libraries and frameworks that help eliminate certain classes of security bugs, such as XSS vulnerabilities in web applications. Google also uses automated tools such as fuzzers, static analysis tools, and web security scanners to automatically detect security errors. These tools help identify potential security issues early in the development process, allowing developers to address them before they become more difficult and expensive to fix.

6.Google_infrastructure.pdf: Pages 13 and 14

Software development practices:

https://cloud.google.com/docs/security/overview/whitepaper?hl=es-419#software_development_practices

For more information, see Google Cloud Secure Software Development:

https://cloud.google.com/docs/security/infrastructure/design?hl=es-419#safe_software_development

6.2 How are developers trained in SSDLC/Secure Coding Practices?
7.Customer Facing Application Security
7.1 Describe how you authenticate users: If passwords are used, describe complexity requirements and how passwords are protected. If SSO is supported, describe the available options. If different levels of service are available, please describe them.

AppSheet implements user authentication in a variety of ways to ensure security and convenience. The system not only supports but also requires the use of SSO (single sign-on). This SSO is done through several recognized providers, such as Google, Microsoft, Apple, Dropbox, Smartsheet, Box, Salesforce, among others.

Additionally, AppSheet offers strong domain authentication support through providers such as Active Directory, AWS Cognito, Google Domain, Okta (in beta), and Open ID Connect.

When it comes to password management, AppSheet follows a secure approach by not storing authentication credentials. During the single sign-on (SSO) process, an OAuth token is issued to the user's device, whether it is a browser on a laptop or a token on a mobile device. This token allows the user to be identified as valid on our platform, without the need to store passwords in our infrastructure. This approach not only improves security, but also simplifies the login process for our users.

https://support.google.com/appsheet/answer/10105078?hl=en&sjid=3721091393427751557-EU#zippy=%2Cwho-c...

7.2 Does your application allow you to create custom granular roles and permissions? Describe the positions available

AppSheet offers a robust system of permissions and custom roles, allowing great flexibility in defining access and responsibilities. Here are some examples of how you can set these permissions:

Row Filtering: It is possible to secure rows using data-driven concepts. For example, it can be configured so that a computer sees only its own computer's data.

Column Filtering: Columns can be filtered based on specific roles or data. For example, a column can be displayed only if the current user is a member of a role called 'administrator'.

View Control: It is possible to show or hide entire views of the application based on specific roles or conditions.

Security in Actions, Workflows and Reports: AppSheet actions, workflows and reports can be secured to ensure that only certain roles have access.

“Show If” Logic: In general, “show if” logic can be applied to almost any element within an AppSheet application, allowing for extensive customization.

In the context of limiting users to their own data, security filters are used. These filters, associated with each table in the application, are Yes/No expressions that use the user's email address and other data values ​​to control the data displayed to that user. Some examples of security filters include:

Limit user email access: [EmailColumn] = USEREMAIL()

Limit access by user's email domain: CONTAINS(USEREMAIL(), [EmailDomainColumn])

Allow access to any manager: OR(IN(USEREMAIL(), Managers[Email]), USEREMAIL() = [EmailColumn])

Filter based on the department contained in the employees table: IN(LOOKUP(USEREMAIL(), Employees, Email, Department), LIST("Payroll","Personnel"))

Filter the customer table so that each sales rep sees only their own customers: IN([CustomerId], SELECT(CustomersToReps[CustomerId], [SalesRepEmail] = USEREMAIL()))

These examples illustrate how AppSheet allows detailed customization of permissions and roles to fit the specific needs of each application and organization.

https://support.google.com/appsheet/answer/10104977

https://static.googleusercontent.com/media/about.appsheet.com/en//static/pdf/appsheet-security-and-c...

7.3 What logs and audit trails are kept for systems and applications with access to customer data?

AppSheet records and audits application activity using its Audit History. This record includes various interactions, such as synchronizations between users and the AppSheet backend, additions, edits, or deletions between users, invoking actions or calls using the AppSheet API, invoking a bot, and the creation of reports or documents.

To monitor this activity, users can access the Audit History through the Manage > Monitor tab in the application editor. Here, you can filter and analyze log entries by operation, date, failures, table name, user ID, or rule name.

It's important to note that during the single sign-on (SSO) process, AppSheet issues an OAuth token to the user's device, eliminating the need to store passwords. AppSheet never stores authentication credentials. Additionally, as a security measure, the Audit History does not display sensitive information related to passwords.

Audit History allows administrators to export logs to BigQuery for further analysis, and also offers the ability to set up email alerts for log errors. These alerts provide detailed information about the error, operation, application URL, and Audit History log.

Monitor application activity using Audit History:

https://support.google.com/appsheet/answer/10104794

7.4 How does the application store API keys?

8.Compliance

8.1 How do you carry out internal audits (audits led by your staff) of the service? Please describe the scope, remediation process and frequency of the audits.

Specialists in Internal Audit and Compliance:

Google maintains a specialized internal audit team dedicated to evaluating compliance with security laws and regulations in its products globally. As new auditing standards emerge and existing ones are updated, this team identifies the controls, processes and systems necessary to ensure compliance. Additionally, the team supports independent third-party audits and evaluations. For more information, see Help with compliance requirements:https://cloud.google.com/docs/security/overview/whitepaper?hl=es-419#compliance-requirements

Regarding the frequency and scope of audits, Google rigorously follows the standards established in Section 7.4 (SOC Report) of the document "3.0.Data Processing and Security Terms for AppSheet Services.pdf". According to this report, Google is committed to maintaining a SOC 2 report, prepared by a third-party auditor and updated annually, with an audit performed at least once every 12 months. Additionally, in compliance with European data protection legislation, Google allows the customer or an independent auditor designated by the customer to conduct audits to verify compliance with Google's obligations, as set out in Section 7.5.3 (Commercial Terms additional for reviews and audits).

The scope, remediation process, and frequency of audits are defined collaboratively between the customer and Google, and any planned audits are notified to Google with reasonable advance notice. If a security breach is identified during an audit, the customer will notify Google immediately and will work closely to effectively remedy the situation.

Data Processing and Security Terms for AppSheet  Services: https://www.appsheet.com/Home/Dpst

8.2 How are external (third party) audits of the service carried out? Please describe the scope and frequency of the audits.

Assistance with compliance requirements

Google Cloud undergoes regular independent verification of security, privacy, and compliance controls, and receives audit reports and certifications to demonstrate compliance. Information security includes specific controls related to the privacy of customer data that help keep it secure.

Some of the key international standards that are audited are:

ISO/IEC 27001 (Information security management)

ISO/IEC 27017 (Cloud Security)

ISO/IEC 27018 (Cloud Privacy)

ISO/IEC 27701 (Privacy)

SOC 2 and SOC 3 reports are available for our clients. Some resources may require access with your Google Cloud or Google Workspace account

Compliance Report Manager:https://cloud.google.com/security/compliance/compliance-reports-manager?hl=es-419

We also participate in sector- and country-specific frameworks such as FedRAMP (US government), BSI C5 (Germany), and MTCS (Singapore). We provide documents and resource assignments for certain frameworks where formal certifications may not be required or applicable.

8.3 Please provide a copy of the most recent report (as per section 5 of the Service Introduction tab).

Some resources may require access with your Google Cloud or Google Workspace account

Compliance Report Manager:

https://cloud.google.com/security/compliance/compliance-reports-manager?hl=es-419

8.4 What standards, certifications and/or regulations related to IT privacy and security do you comply with?

ISO/IEC 27001 (Information security management)

ISO/IEC 27017 (Cloud Security)

ISO/IEC 27018 (Cloud Privacy)

ISO/IEC 27701 (Privacy)

SOC 2 and SOC 3 reports are available for our clients.

8.5 Provide a copy of the most recent report (as per section 5 of the Service Introduction tab).

Some resources may require access with your Google Cloud or Google Workspace account

Compliance Report Manager:

https://cloud.google.com/security/compliance/compliance-reports-manager?hl=es-419

8.6 Are you seeking the right to use or possess customer-derived data for your own purposes? Please describe

Google Cloude processes the customer's personal data for the purpose of providing the Services and TSS (Technical Support Services). to the customer in accordance with Appsheet Terms, Conditions and Data Processing https://www.appsheet.com/Home/Dpst

8.7 Is your Privacy Notice/Privacy Policy available externally? Provide the URL.

Google Cloud Security and Privacy Policy: https://policies.google.com/privacy

Google Code of Conduct: https://google-code-of-conduct/