How to use serverless actions for custom security scans.
After the introduction to custom metrics in IBM Cloud Security Advisor and an overview of how to manage custom findings on the command line, I am going to discuss how you can perform your own security scans and add the results to the security advisor.
As mentioned above, I am using IBM Cloud Functions to perform my own security scans and then add the result as custom findings to IBM Cloud Security Advisor. If you already looked at the functions code on GitHub, you may have noticed that each action for a specific custom scan is actually a sequence of three small actions:
- The first action obtains an IAM access token (Identity and Access Management). It is needed to interface with the Security Advisor and for some scans.
- The second action is different in each sequence. It connects to an IBM Cloud management API or to LogDNA to assess activity tracker/audit data.
- The third action in the sequence creates individual occurrences for findings or KPI in the IBM Cloud Security Advisor.
The architecture diagram above shows the mentioned steps. Other security scans could be added as second step with a specific action to add the related records in Step 3.
Custom security scans
The repository on GitHub provides code for three different security scans.
- External users: This scan utilizes the IBM Cloud user management API to obtain a list of users in the cloud account. It then looks at the domain of each email address. If there is a mismatch to the configured domain, a security incident (finding) is created and the number of found issues is reported as KPI.
- Inactive users: Users can have different states, and the default is ACTIVE. If a user is found with a non-active state for the account, the issue is reported as finding.
- LogDNA issues: On IBM Cloud, you can use Activity Tracker with LogDNA for audit logs and Log Analysis with LogDNA for general application logs. In an older blog post, I showed how to use the LogDNA API to search for log records. This custom scan performs a set of configured searches against LogDNA instances. If any records are found, they are reported as KPI. Queries could flag errors in security-related components, authentication issues in deployed apps or more.
Access groups for privilege management
The above scans are implemented as Cloud Functions and deployed to a so-called IAM namespace. An IAM namespace maps to a service ID in IBM Cloud. This means that actions run with the privileges assigned to that service ID. In order to perform the security scans and to create findings, the service ID needs to have the right set of privileges. One option for assigning them is through IAM access groups.
Once you created an access group, you can add users and service IDs to it—in our case, just the service ID for the namespace. Thereafter, you create access policies for that group. An access policy determines which resource or service can be accessed and in what role. There can be resource wildcards like "all instances of a service" or selection of specific instances. For each policy you would need to set if, for example, read, write, or management access should be granted.
In order to access user information for the account, the Cloud Functions need account management access as readers. To create findings in Security Advisor, write access is needed. However, in order to update existing findings when a new scan is performed or to even remove findings if the issues is gone, manager access is required.
See the deployment instructions in the repository for details on access management and how to configure input parameters. Once everything is in place, you can either manually run the actions or set up Cloud Functions triggers to schedule daily or weekly execution in a cron-like fashion. Go to the Security Advisor dashboard or the findings page to see the scan results.
In this series of blog posts, I showed you how you can add your own metrics to IBM Cloud Security Advisor, I wrote a small command line tool to easily work with my custom objects, and to perform scans and create custom findings, I utilized Cloud Functions. The serverless implementation is the best match for the task and allows scheduled execution. Thus, you can add your own security scans and metrics to the Security Advisor and automatically perform those tests.
Here are the links to the previous blog posts in this series and the code on GitHub:
- My first post discussed IBM Cloud Security Advisor and how to extend it with custom findings.
- Next, I showed you how to manage Security Advisor objects for custom findings from the command line, utilizing the API and Python SDK.
- I will also show you how to get Security Advisor alerts via Slack or email.
- The code for this project, including step-by-step instructions, is available on GitHub in the repository security-advisor-findings.