Preparing for the Google Partner Program Security Test

FThe following Self-Assessment Questionnaire (SAQ) is meant to prepare you for the Google Partner Program security assessment. The Google Partner Security Program is a collaborative effort to protect partner, customer, and Google data by increasing the security of Google partners’ applications and networks that integrate with the Google ecosystems. Google has engaged Bishop Fox to conduct appropriate security testing with the goal of validating the security of Google partners’ applications and ensuring Google user data is being handled securely.

This self-assessment addresses common threats, based on industry trend reports, CIS CSC Top 20, and our experience both as testers and as the firm who partnered with Google to create the testing methodology. Responses are reviewed as “met”, “partially met”, or “not met” based on standardized evaluation criteria. Our goal is to help you prepare for the security assessment and help you successfully complete and meet Google’s requirements so that you can continue to offer your application within the Google ecosystem. This guide will provide an overview of the topics covered on the Self-Assessment Questionnaire (SAQ) and highlight the most common security findings produced by the assessments. By sharing these findings, we hope to help you focus on areas where you’re most likely to run into issues so that you can quickly complete your assessment, while still ensuring privacy and security for users.

MOST COMMON FINDINGS

This list represents the most common findings identified across last year’s SAQ security assessments. These findings helped us create our SAQ and provided areas of improvement where our clients should focus their efforts. The five most common findings:

1. Missing Vulnerability Disclosure Program (see Vulnerability Disclosure Program)

2. Improper Incident Response Plan (see Incident Response Plan)

3. Missing Account Threat Detection Mechanism (see Logging Practice)

4. Insecure Token Storage (See Google API Access Token Storage)

5. Lack of Encryption at Rest for User Data Storage Volumes (See User Account and Personal Data Deletion)

Now, we’ll jump into the SAQ to help you and your team prepare:

SELF-ASSESSMENT QUESTIONNAIRE

Incident Response Plan

Logging Practice

Vulnerability Disclosure Program

User Account and Personal Data Deletion

IT and Workstation Security

Secure Software Development Lifecycle

Multi-factor Authentication

Google API Access Token Storage

Data Classification Policy

Data Backup

INCIDENT RESPONSE PLAN

Incident response plans require participation and contribution from different departments and team members. Ensure that your incident response plan provides clear guidance and responsibilities for each party participating in the process.

1. Do you have documentation describing your incident response plan?

2. Does your incident response plan include descriptions of how incidents are identified, how to triage an incident, and who is responsible?

3. Following an incident, do you share a post-mortem or any lessons learned with your employees?

4. Do you have defined protocols and procedures for reporting incidents to the appropriate regulatory bodies or law enforcement?

LOGGING PRACTICE

Logging and monitoring are critical for alerts, rapid response, and investigations. Consider the existing automation currently in place in regard to your infrastructure, and identify ways in which additional monitoring might be introduced to enhance their security posture. For example, AWS users might add a CloudTrail rule which alerts when users have administrative privileges added to their accounts.

Monitoring and alerting are not just for system administrators. Users can benefit from information such as unsuccessful login attempts, access from an unrecognized IP address, or pertinent information on recent account activity.

1. Are alerts generated when changes are made to users with administrative privileges over your cloud or on-premise infrastructure?

2. Do you log unsuccessful attempts to access administrative or deactivated accounts?

3. What steps do you take to prevent the exfiltration of data on your corporate network? What processes and tools are used?

4. Do you notify users of unsuccessful login attempts to their account?

VULNERABILITY DISCLOSURE PROGRAM

A vulnerability disclosure program allows your organization to provide clear instructions to securely transmit vulnerabilities identified by customers or security researchers.

Awarding bounties or using a triage service like HackerOne, Intigriti, or BugCrowd is optional, and may be a good fit for your organization. Some organizations have found success crowdsourcing their vulnerability identification through these programs as it provides security researchers with additional incentive to identify and disclose vulnerabilities that might be exploited by malicious users. However, simply providing a webpage with clear directions on reporting vulnerabilities, creating a [email protected] email list, and triaging and remediating findings in the industry standard 90-day window is also sufficient.

1. Do you have a vulnerability disclosure program?

2. Is there a publicly available web page describing how to report vulnerabilities?

3. Do you implement security.txt and/or have a [email protected] email alias?

4. Do you have established internal SLAs or deadlines for triaging reported or identified vulnerabilities?

USER ACCOUNT AND PERSONAL DATA DELETION

Focus on basic user data privileges such as access, modification, and deletion. Users should be able to control and remove their data from the application. Additionally, all storage volumes containing user data should be encrypted at rest.

1. Can a user delete their account, or request that their account be deleted?

2. Are users able to delete their data?

3. Are storage volumes containing user data encrypted at rest?

4. (Optional) Can users access/download their data?

IT AND WORKSTATION SECURITY

To ensure the integrity of the application, it’s important to consider the security policies of the organization as a whole, as a breach in one area can easily impact the security of the rest of the environment.

1. What does the average employee workstation look like?

2. Do all users have administrative privileges on their workstations, or is it limited to certain users and departments?

3. What steps do you take to reduce the usage of default passwords on your infrastructure? What about default accounts?

4. How are patches deployed to servers? Is the process automated or manual?

5. What steps do you take to secure employee email clients?

6. Do you conduct security awareness training? What is the frequency? How do you verify successful completion?

7. If security incidents are caused by employee error, do the lessons learned get incorporated into the security awareness program?

8. How is wireless access encrypted and what is the authentication mechanism?

9. How do you detect rogue access points?

10. Do you perform DNS filtering of known malicious domains?

11. Are workstations configured to prevent the use of removeable media? What about auto-running programs on removable media? If you don’t have mechanisms in place to automatically prevent the use of removable media, do you have a policy that forbids their usage?

12. How is system configuration enforced for your infrastructure?

13. What endpoint protection mechanisms are in place on employee workstations? What percentage of workstations have an anti-malware solution deployed? How often are signatures updated?

14. Are software and hardware purchases required to be performed by a specific person or department? What person or department approves these? What tooling is used to track software and hardware inventory?

SECURE SOFTWARE DEVELOPMENT LIFECYCLE

Secure development operations, designs, and deployments make up the backbone of application security. Consider the questions below to determine the maturity of your application.

1. How do you harden your server and/or container images?

2. Is there a clear, understood definition of what constitutes a secret and where it is and is not supposed to be stored? What steps do you take to ensure that is the case?

3. Are secrets encrypted at rest?

4. How are patches deployed to applications, frameworks, and systems? How are you alerted to new vulnerabilities in key third-party products?

5. Are development and test teams trained on the OWASP Top 10 and other secure coding guidelines?

6. Does the development team follow a defined security quality assurance test process?

7. Is there an approval process for code contributions to the production codebase? What about infrastructure or configuration modifications?

8. Is sensitive information physically and logically separated from the rest of the network?

9. How often are port scans performed?

MULTI-FACTOR AUTHENTICATION

With the upward trend in credential stuffing attacks, the need for defense-in-depth strategies, such as deploying MFA across internal and external services is a must for both an organization and for customers. Consider your organization’s usage of MFA for general employees, developers, monitoring tools, and services.

1. Does your organization use multi-factor authentication (MFA) for internal employee or developer access to critical infrastructure, such as your cloud environment?

GOOGLE API ACCESS TOKEN STORAGE

Since Google API tokens provide access to the end-user’s Google account, it is important that the associated tokens be protected with strong encryption to prevent unauthorized access to the user’s data. API access tokens should be encrypted via a service such as AWS KMS, Azure Key Vault, GCP Cloud KMS, Heroku ICE, or an equivalent solution. Encrypted records can then be safely stored in a database. Encryption at rest is not a substitute, but a separate security mechanism. For more information on secure storage of user tokens, please see: https://developers.google.com/identity/protocols/oauth2/policies#secure-credentials

1. How do you store users’ Google API tokens?

DATA CLASSIFICATION POLICY

Data classification policies ensure that sensitive data is properly secured and segmented from public data. Having clear definitions of classification and handling allow the organization to define when a violation or leak of sensitive data has occurred.

1. Do you have a documented data classification and handling policy?

2. Do you include authentication credentials and session tokens as sensitive data?

For additional resources on designing data classification and handling policies, please see:

• https://www.bu.edu/policies/data-classification-policy/

• https://www.cmu.edu/iso/governance/guidelines/data-classification.html

• https://it.ufl.edu/policies/information-security/data-classification-policy/

DATA BACKUP

Secure data backup processes are a crucial part of a secure application deployment. It is important to have tested processes in place for disaster recovery.

1. How often do you perform user data backups, where are they stored, and for how long? What about application data (e.g., source code, configuration, etc.)?

2. Are backup volumes encrypted at rest?

3. Are backups stored in a cloud account separate from the account hosting application? What steps do you take to protect backups in the event of cloud account compromise?

CONCLUSION

We hope that this SAQ not only helps prepare you to pass the Google security assessment, but also helps you make measurable improvements in your application’s security posture. You may also find our article, Google Partner Program Top 10 useful. Inspired by the OWASP Top 10, we’ve created a prioritized list of the top 10 most common and high-risk bugs that we find on these assessments.

As a Google-approved testing firm, we’re happy to help you prepare for and complete the Google Partner Program assessment. Get more information and talk to our testing experts.