Prerequisites

• Access to manage Projects inside of your company’s Google Workspace. (Presumably the user wouldn’t see this step without access to begin with)

• Your company should have the Project Creator permission at the organization level, no additional permissions should be required.

Steps

1. In the Google Cloud Console, users will go to the IAM page.
2. Select a Project, Folder, or Organization.
3. Select a Principal to grant a role to:
   1. To grant a role to a Principal who already has other roles on the resource, find a row containing the Principal, click Edit Principal in that row, and click Add Another Role.
   2. To grant a role to a Principal who doesn't have any existing roles on the resource, click the Grant Access button, then enter the Principal's email address or other identifier.
4. The Select a Role dropdown menu will appear. Select a role to grant from the drop-down list. For best security practices, choose a role that includes only the permissions that your principal needs. with the following options:
   1. Browser
   2. Editor
   3. Owner
   4. Viewer
5. To grant a role to a Service Agent, select the Include Google-provided Role Grants checkbox to see its email address.
6. Optional: Add a condition to the Role.
7. Click Save. The Principal is granted the role on the resource.
8. To grant a role to a Principal for more than one project, folder, or organization, users will select Manage Resources in the IAM & Admin menu on the left side of the page.
9. Select all the Resources for the selections the user wants to grant permissions to.
10. If the info panel is not visible, click Show Info Panel. Then, click Permissions.
11. Select a Principal to grant a role to:
    1. To grant a role to a principal who already has other roles, find a row containing the principal, click Edit Principal button in that row, and click Add Another Role.
    2. To grant a role to a Principal who does not already have other roles, click Add Principal button, then enter the principal's email address or other identifier.
12. Select a role to grant from the drop-down list.
13. Click Save. The Principal is granted the selected role on each of the selected resources.

Relevant Documentation Links

• [All Steps] https://cloud.google.com/iam/docs/granting-changing-revoking-access

Prerequisites

• Google Cloud project set up for Google SecOps
• Billing enabled for Google Cloud Project

Steps

1. Users will select a Project from the dropdown at the top of the Google Cloud Console.
2. Navigate to the Side Bar and select View All Products. Users will then look for the Tools section and select the Identity Platform page (Users can pin the selection also). 
3. Click Enable Identity Platform.
4. Navigate to the Identity Providers Page and click Add a Provider.
5. Click the Enabled toggle to on and click Save
6. Navigate to the Users page.
7. Click Add user.
8. In the Email field, enter an Email and Password. Make a note of both of these values because you will need them in a later step.
9. To add the user, click Add. The new user is listed on the Users Page.

Relevant Documentation Links

• [All Steps] https://cloud.google.com/chronicle/docs/onboard/configure-cloud-authentication

Prerequisites

• Administrative access to the Google Cloud Project in which you intend to enable 3rd party IdP
• Understanding of Google Cloud Workforce Identify Federation
• Familiarity with Google Cloud Shell

Steps

1. Users will navigate to Google SecOps.
2. Google SecOps looks up IdP information in the Google Cloud workforce identity pool.
3. A request is sent to the IdP.
4. The SAML assertion is sent to the Google Cloud workforce identity pool.
5. If authentication is successful, Google SecOps receives only the SAML attributes defined when you configured the workforce provider in the workforce identity pool.
6. User will define workforce identity pool and provider details.
7. Then define User Attributes and Groups in the IdP
8. Create a SAML Application in the IdP and configure it.
9. Configure workforce identity federation in Google Cloud.
10. Create and configure a Workforce Identity Pool.
11. Create a Workforce Identity Pool.
12. Grant a role to enable sign into Google SecOps.
13. Verify or configure Google SecOps feature access control.
14. [Opt] Modify Workforce Identity Federation configuration.

Relevant Documentation Links

• [All Steps] https://cloud.google.com/chronicle/docs/onboard/configure-authentication

Prerequisites

• Access to manage Projects inside of your company’s Google Workspace.
• Google SecOps must be bound to a Google Cloud project and configured with either Cloud Identity, Google Workspace, or Google Cloud workforce identity federation as an intermediary in the authentication flow to a third-party identity provider.

Steps

1. After logging on to Google SecOps, a user accesses a Google SecOps application page. Alternatively, the user may send an API Request to Google SecOps.
2. Google SecOps verifies the permissions granted in the IAM policies defined for that user.
3. IAM returns the authorization information. If the user accessed an application page, Google SecOps enables access to only those features that the user has been granted access to.
4. If the user sent an API Request, and does not have permission to perform the requested action, the API Response includes an error. Otherwise, a standard response is returned.
5. Google SecOps Permissions correspond one-to-one with Google SecOps API methods. Each Google SecOps Permission enables a specific action on a specific Google SecOps feature when using the Web Application or the API.
6. To assign a Role to a user follow the steps in Grant Access section.

Relevant Documentation Links

• [All Steps] https://cloud.google.com/chronicle/docs/onboard/configure-feature-access

Steps

1. Users need to set up the SAML Attributes and the SAML groups in the external Identity Provider (IdP).
2. Navigate to the SAML Attributes mapping section in the Google Workspace.
3. Users will add the following four mandatory attributes:
   1. first_name
   2. last_name
   3. user_email
   4. Groups
4. In the Google Groups section, users will write the names of the IdP Groups. As an example:
   1. Chronicle Admins
   2. Gcp-security-admins
5. Users will need to take note of the group names, as they will need them later for mapping in the Google SecOps platform.
6. To Control User Access, users will go into the SOAR Settings of the unified Google SecOps platform. There are several different ways to determine which users have access to which aspects of the platform.
   1. Permissions groups
   2. SOC roles
   3. Environments
7. The combination of Permission Groups, SOC Roles, and Environments defines the Google SecOps user journey for each IdP Group in the Google SecOps platform.
8. Users will need to map each IdP Group that you defined in the SAML settings procedure in the IdP Group Mapping page. (By default, the Google SecOps platform includes an IdP Group of default admins.)
9. To map IdP groups, users will need to go into the Google SecOps platform, navigate to Settings > SOAR Settings > Advanced > IdP Group Mapping.
10. Make sure the user has the names of the IdP Groups they will select to map.
11. Click the Add button and start mapping the parameters for each IdP Group.
12. When finished, users will click Save. When each user logs in to the platform, they are automatically added to the User Management page (which is located in Settings > Organization .
13. Note: Sometimes users will try to log into the Google SecOps platform but their IdP Group has not been mapped in the platform. In order for these users not to be rejected, Google recommends enabling and setting the Default Access Settings on this page. IdP users must be part of a single mapped IdP Group.

Relevant Documentation Links

• [All Steps] https://cloud.google.com/chronicle/docs/soar/admin-tasks/user-secops/map-users-in-the-secops-platform

Steps

1. To begin, users will select Settings in the left-side Navigation Bar and then select SOAR Settings, which will display the Settings page. 
2. In the Settings page, users will select Advanced, which will display a drop-down list. Users will select Support Access. 
3. On the Support Access page, that will provide access to Google Support. 
4. Users will be able to select to Allow Access to Google Support, after selecting the mandatory fields below. 
5. Additional mandatory fields consist of:
   1. Select SOC Role
   2. Select Permission Group
   3. Select Environments
   4. Select Time Period
6. Select Save.
7. As soon as Google Support registers a new user, they will appear below.

Relevant Documentation Links

• [All Steps] https://cloud.google.com/chronicle/docs/soar/admin-tasks/permissions/allow-google-support-access

Steps

1. To add a new blocklist item, users will navigate to SOAR Settings > Environments > Blocklist.
2. Click Add on the top right of the screen.
3. Enter Entity Identifier and select Entity Type, Action, and the Environment.
4. Click Add. 

Relevant Documentation Links

• [All Steps] https://cloud.google.com/chronicle/docs/soar/admin-tasks/configuration/create-block-list-to-exclude-entities-from-alerts

Steps

1. To begin users will select Settings in the left-side Navigation Bar and then select SOAR Settings, that will display the Settings page. 
2. In the Settings page, users will select Advanced, which will display a drop-down list. Users will select Email Settings. 
3. On the Email Settings page, users by default will see Google SecOps SMTP selected. 
4. If users prefer to use a separate option, they will select Customer Configuration to manually setup their email address, from which all system emails will be sent. Those selection options consist of:
   1. Sender Display Name
   2. Sender Email Address
   3. Username
   4. Password
   5. SMTP - Server Address
   6. SMTP - Port
   7. SMTP - Use SSL
   8. Require Authentication
   9. Trust Certificate
   10. Use Exchange OAuth
5. When those sections are filled in, users can test the configuration.
6. When complete, users will select Save.

Relevant Documentation Links

• [All Steps] https://cloud.google.com/chronicle/docs/soar/admin-tasks/advanced/setting-up-your-email

Prerequisites

• Access to manage Projects inside of your company’s Google Workspace.
• To view audit logs, you must have the appropriate Identity and Access Management (IAM) permissions and roles.

Steps

1. By default, Google retains Twelve Months of user data in the user’s Google SecOps account. This retention period can be extended as part of the Purchase Order. The retention period applies to all of the data in the user’s Google SecOps instance. 
2. Google uses an automated system to remove historical data based on event and detection timestamps.
3. Enabling audit logs helps users with security, auditing, and compliance entities that monitor Google Cloud data and systems for possible Vulnerabilities or external data misuse.
4. Cloud Audit Logs provides the following audit logs for each Google Cloud project, folder, and organization:
   1. Admin Activity Audit Logs
   2. Data Access Audit Logs
   3. System Event Audit Logs
   4. Policy Denied Audit Logs
5. Audit log entries include the following objects:
   • Log entry itself, which is an object of type LogEntry. Useful fields include the following:
     • logName contains the Resource ID and Audit Log Type.
     • resource contains the target of the audited operation.
     • timeStamp contains the time of the audited operation.
     • protoPayload contains the audited information.
6. To enable audit logging for the chronicle.googleapis.com service, see Enable Data Access audit logs.
7. To enable audit logging for other services, contact Google SecOps Support.
8. To populate UDM Search and Raw Log Search Queries in the Google SecOps Audit Logs, update the Data Access Audit Logs configuration with the necessary permissions.
9. In the navigation panel of the Google Cloud Console, select IAM & Admin > Audit Logs.
10. Select an existing Google Cloud Project, Folder, or Organization.
11. In Data Access Audit Logs Configuration, select Chronicle API.
12. In the Permission Types tab, select all the listed permissions:
    1. Admin Read
    2. Data Read
    3. Data Write
13. Click Save.
14. Repeat steps 11 - 13 for Chronicle Service Manager API.
15. To find and view audit logs, use the Google Cloud project ID.
16. In the Google Cloud Console, use the Logs Explorer to retrieve your audit log entries for the Google Cloud project.
17. In the Google Cloud Console, go to the Logging > Logs Explorer page. 
18. Note: If users are using the Legacy Logs Viewer page, switch to the Logs Explorer page.
19. On the Logs Explorer page, select an existing Google Cloud Project, Folder, or Organization.
20. In the Query Builder pane, do the following:
    1. In Resource Type, select the Google Cloud resource whose audit logs you want to see.
    2. In Log Name, select the audit log type that you want to see:
       • For Admin Activity audit logs, select Activity.
       • For Data Access audit logs, select Data_access.
21. If you don't see these options, no audit logs of that type are available in the Google Cloud Project, Folder, or Organization.

Relevant Documentation Links

• [All Steps] https://cloud.google.com/chronicle/docs/administration/audit-logging
• [Additional Steps] https://cloud.google.com/logging/docs/audit