Security-as-code has become crucial to the delivery of any SaaS business’ product. With more developers adopting GitHub as the central platform of collaboration, security teams’ usage of GitHub audit logs has become critical to monitoring the safe-keeping of infrastructure-critical code repositories from both internal and external threats.
By the end of this blog you’ll be able to:
- Understand the key attributes of GitHub Audit Logs and what it reports
- Leverage out-of-the-box Panther detections to monitor for internal and external adversaries attempting to upload malicious code
- Run fast investigations with threat hunting tools in Panther to empower incident response
GitHub Audit Logs
GitHub Audit Logs are provided as part of GitHub Enterprise edition and are used to track the GitHub actions of developers within an organization. Common examples of GitHub actions include a user role change in an organization, a user (actor) performing a pull request, and which repository it was performed in.
With organizations storing business-critical code repositories in GitHub, security teams must track these events to ensure the safety of the code base. As many teams will store Terraform templates, CloudFormation parameters, RailsData, SSH key information, and other business-critical templates crucial for infrastructure-as-code.
Each GitHub audit log entry is composed of the action object, followed by an operation type. For example, if an internal developer recently created a pull request, the action would be tracked under the pull_request category with the action create.
The delivery of these logs by GitHub may seem lightweight, but with about 50 categories, each consisting of at least 3 or more actions, security teams can get drowned in the volume of logs generated. This is where a modern Security Information Event Management (SIEM), such as Panther, can assist with analyzing event logs with out-of-the-box detections.
Protecting GitHub Repositories with a Modern SIEM
With built-in support for GitHub audit logs, security engineers can start monitoring GitHub logs in as little as 10 minutes.
Due to the speed of implementation, security teams can immediately monitor sensitive code repositories and respond to potential internal and external threats. In our examples that follow, we will look at how Panther detections can instantly mitigate the risk of adversaries attempting to cripple an organization’s infrastructure or intellectual property (IP) by uploading malicious code to a master branch.
Use Case #1 – Preventing external actors from uploading malicious code to a master branch
Branches are a critical part of development collaboration in GitHub. They enable developers by providing a copy of the source code for each team to work on to test new features and bug fixes without affecting the master branch. Once each development is done, the branches can be merged into the main branch via pull requests.
An adversary can take advantage of this system by creating malicious code in a private branch and then injecting it to affect the quality and security of the code in the main branch. The malicious code can potentially break infrastructure deployment templates crippling an organization from deploying internal or customer-facing instances. Creating downtime or stolen customer data.
To avoid such risks, security teams should utilize branch protection rules within GitHub itself. These rules are policies for each respective branch that can require specific actions to be taken before uploading or modifying code changes. One of the most common rules is a pull request review before merging. Further branch protection rule options are listed here.
Once branch protection rules are set up, Panther provides out-of-the-box detections that can ensure the continued usage of said policies.
Sample 1: Branch Protection Policy Override – Full Code Here
def rule(event): return event.get("action") == "protected_branch.policy_override"
Sample 2: Branch Protection Disabled – Full Code Here
def rule(event): return event.get("action") == "protected_branch.destroy"
Let’s take a look at how these detections can be applied to an external bad actor looking to get access to infrastructure code templates. For this example, an attacker has already gained a foothold into GitHub by stealing credentials from an admin user in your organization.
With the access they now have, they want to override or disable a branch policy in order to commit malicious code to the master branch. That’s where the two detections above come in. Both provide immediate oversight of an organization’s branch protection policies. Ensuring their continued usage and the overall security of the master branch.
Use Case #2 – Disgruntled Internal Employees committing code to master branch
Similar to the example above, let’s say a disgruntled employee wants to inject malicious code into a master branch of Terraform templates to remove the company’s ability to stand up new instances for customers. Once they write the code the employee would need to find a way to gain proper privileges to upload the code without a pull request review.
The same detections listed in use case #1 can apply to this scenario, but Panther also enables several other rules that can help identify internal adversaries in GitHub.
- GitHub User Role Updated – This could be a malicious external actor, but can point directly internal as well. The alert is a pre-set high alert to stop any self-modifying their role.
- Admin Role Assigned – Looking for GitHub users that have gained the admin role.
These two detections can be extremely useful when utilized together along with Panther’s investigation tools. Security practitioners can validate one of these alerts by running a quick indicator search within the Panther console.
For example, let’s say an analyst receives an alert that a GitHub User Role was updated. The analyst can immediately cross-reference the user to see if they had triggered an Admin Role Assigned alert as well. If both alerts have been fired for the same user in a small period of time, an analyst can deduce that the alert is more likely a valid threat.
This can be done with the indicator search tool to cross-reference the username or IP address with other rule matches in GitHub. An example of these results is seen below.
We see 5 rule matches with GitHub, meaning the same IP address was found in 5 GitHub alerts in the last 24 hours. By seeing these numbers in an 11-second search, an analyst was able to go from receiving the alert and searching historical data all in less than a minute.
With Panther, a security team is able to gain in-depth visibility into GitHub by utilizing pre-built Panther detections as well as threat hunting tools. These detections are provided out-of-the-box to give teams instant coverage by simply setting up a GitHub integration within Panther. This task usually takes less than 10 minutes, allowing an organization to gain protection almost instantly.
In addition to GitHub, Panther can analyze log data from hundreds of systems including AWS, 1Password, O365, GCP, Crowdstrike, OSquery, and more. You can check out a list of all our supported integrations here, follow our Quick Start Community guide to get started with Panther or contact us for a demo.