Double Your Threat Blocking in 90 Days
İlker Küçücük & Picus Labs | November 03, 2023
Understand the 4 trade-offs that limit modern security teams to properly manage their organization’s threat exposure.
Atlassian is a software company that offers popular collaboration and project management tools. The products such as Jira, Confluence, Bitbucket, and Trello help your various business processes. These products generate a lot of log data as they manage different facets of your business.
Atlassian products play an important role in managing various business processes and facilitating collaboration for your organization. These products help you plan projects, create and store documentation, develop software, and collaborate effectively. Additionally, Atlassian's products may store sensitive company and customer data. As a result, security is becoming an important issue covering data confidentiality and integrity, and the security of Atlassian, which we use in our organization's business processes, can be extremely critical.
Maintaining uninterrupted business processes is a top priority for organizations. Ensuring the security of Atlassian platforms is essential, not only to uphold customer trust but also to safeguard business continuity. Security breaches or malicious attacks can be extremely detrimental to Atlassian's functionality. This shows us how important strong security measures are.
In this blog post, we will explore how to transfer the logs of Atlassian platforms to Splunk and how utilizing this data can enhance the security and performance of your business.
Splunk is a platform that provides big data analysis and log management. Splunk collects the logs, indexes them, and provides a search engine and syntax so you can review them. The organizations can visualize their data and handle security and operational issues with Splunk. You can also create your own detection rules to identify anomalies. Leveraging the power of Splunk, we will collect logs from Atlassian products and create anomaly detection rules.
Atlassian, like many other cloud products, can integrate with log management applications. Through this integration, we can easily manage Atlassian's logging capabilities within Splunk.
Figure 1: Atlassian Audit Logs
To pull our logs into Splunk, we will use an API Token from Atlassian and the Jira Add-On in Splunk. Let's begin by creating an API Token for Splunk in Atlassian. You can do this by visiting https://id.atlassian.com/manage-profile/security/api-tokens.
Figure 2: Create new API Token on Atlassian
In Splunk, we will receive logs from Atlassian using the "Splunk Add-on for Jira Cloud" extension. To do this, we first need to enter the API Token we created on Atlassian in the Configuration tab of our app.
(Note: Ensure you have the necessary permissions and access rights to configure the app and add the API Token.)
Figure 3: Splunk Add on for Jira Cloud
After determining our domain information and logging level, we can proceed to the "Inputs" tab. In the "Inputs" tab, to set up the flow and storage of our data, we need to utilize the "index" structure in Splunk. To do this, follow these steps within Splunk:
Navigate to "Settings > Indexes."
Click on the "New Index" button.
In this section, provide information such as the data type your index will hold, the maximum raw size of stored data, and the retention period. (In our example, our index is named "atlassian," and the data type selected is "Events.")
Figure 4: Create an Index
Now that we've determined where the incoming data will be stored, it's time to introduce this "index" to our Jira App.
Then, you'll be ready to start reviewing logs!
Figure 5: Create an Input
When we want to examine the structure of the logs, we can see that all event types on Atlassian are neatly gathered in the "summary" field. Knowing that the individuals triggering these events are found in the "authorkey", and the entities or objects affected by the triggered events are within the "associatedItems" field will simplify our rule-writing process. Additionally, we can access a wealth of information, including the projects where events occur, pages, the IP addresses of users performing events, user roles, and authorization levels, among many others.
Figure 6: an Example Log
The structure of logs can vary depending on the event types. For example, in some event types, the "associatedItems" field may indicate a user, while in others, it may represent a page name or a project name. To effectively utilize the logs, it's beneficial to review all fields when creating the scenarios you want to detect.
After reviewing our logs, you can now create various scenarios that you identify as potential risks and areas of interest in your Atlassian environment. Based on our frequency of Atlassian usage and our past findings, we want to investigate and monitor the following situations:
The creation of an external user in Atlassian.
The deletion of a project in Atlassian.
Adding any user to an Admin-level user group.
Removing a user from a project.
Changing a user's password (As we authenticate through our Google accounts, this could be noteworthy for us).
While creating rules for the scenarios we want to investigate, we will follow the following process:
Create the rules in Splunk.
Enrich the alerts in Jira's automation before adding them as tasks.
Transfer the alerts to the board in Jira.
If you wish to review the alerts on Jira, you can establish integration between Splunk and Jira using Splunk's 'JIRA Service Desk Simple AddOn.
As shown in the image below, you can add your Jira account to Splunk by providing the Jira URL, Username, and API Token information to the add-on. You will be able to select your desired Jira project where you want to view the alarm outputs when creating Splunk rules.
Figure 7: Add JIRA Account
After completing the integration, you can start creating your rules in Splunk by navigating to the Settings > Searches, Reports, and Alerts tab, where you manage your rules.
Scope: This rule is triggered when a user is created on Atlassian with an email address from outside our domain. The creation of external users on Atlassian is a critical matter that warrants investigation. Given that Atlassian houses our company's business processes, sensitive customer data, plans, and projects, it is extremely perilous for an external user to potentially access this information through any vulnerability or misconfiguration. The Atlassian groups to which these users belong and the permissions they possess should be carefully considered.
Figure 8: Splunk Search Query of Rule
Figure 9: Configure the Alert
Our next step is to link our rule to a Jira Board. To do this, under "Trigger Actions", select "Open an issue in JIRA Service Desk" and configure the necessary settings based on your environment's priorities. (Note: Prior to this step, integration between Splunk and Jira must be established.)
Figure 10: Create a Description
Now, we have created our first rule, but it should be in a disabled state for now. This is because we need to enrich our alerts. I will explain why enrichment is necessary in the next sections.
When creating our other rules, we will follow the same process, so I will only discuss their scope and configurations.
Scope: This rule is triggered when a project is deleted on Atlassian. Atlassian projects may contain various sensitive data belonging to the company, including R&D work, business processes, and even customer data. These pieces of information are stored on Atlassian for easy management. In the event of project deletion, it is crucial to obtain information about the reason for this action and who performed it.
Figure 11: Splunk Search Query of Rule
Scope: This rule is triggered when Administrator privileges are granted to users on a project or when a user's permissions are elevated. Administrator privileges allow users to perform nearly all actions within a project. The creation of a malicious Administrator user can lead to malicious activities in user operations, project operations, and even logging processes. It is of utmost importance to be instantly informed when a user obtains Administrator privileges.
Figure 12: Splunk Search Query of Rule
Scope: This rule is triggered when any user is added to specific admin-privileged groups. Atlassian role groups, in contrast to regular users, may possess permissions across multiple projects. Malicious users added to these role groups can potentially gain access to sensitive company data across different projects. Therefore, close monitoring of these groups is essential.
Figure 13: Splunk Search Query of Rule
Scope: This rule is triggered when a user is removed from a project on Atlassian. Detecting the removal of a user from a project is just as important as detecting when users are added to a project. Since Atlassian logs do not provide records of user additions to a project, we can investigate traces of suspicious activity through such actions when it is suspected that a user has engaged in suspicious activities.
Figure 14: Splunk Search Query of Rule
Scope: This rule is triggered when the password of an internal Atlassian user is changed. In our environment, we use the Google OAuth system for logging into Atlassian. Therefore, a password change in Atlassian accounts is a situation that requires investigation for us. This is because such an event may indicate that an account has been compromised and the user is attempting to block unauthorized access.
Figure 15: Splunk Search Query of Rule
When we activate the alarms, the triggered rules' alerts will appear as tasks in Jira.
For example, the view of the "Atlassian - External User Created" alarm in Jira looks like this:
Figure 16: Output of the Rule
As I mentioned earlier, when writing rules based on Atlassian logs, there is an important consideration to keep in mind. Atlassian logs can sometimes be insufficient for rule creation in certain aspects. For example, it may not always be possible to see the usernames or email addresses of users in the logs. In such cases, it can become challenging to review or interpret the alarms.
Figure 17: An Alarm with Inaccessible User Information
This is why, as mentioned earlier, we need to undertake an enrichment effort for alarms. During our enrichment process, we will use automation in Jira to communicate with the Atlassian REST API and retrieve the necessary information for us. This will enable us to enrich the alarm and print it to our Jira Board in an enhanced format for our review.
Automation in Jira Service Management is a "no-code" capability that only takes a few clicks. By automating your processes and workflows, you can remove the manual, repetitive tasks, and you can focus on the prioritized work.
To create our automation, we start by clicking on the "Automations" tab in our project. We enter the details of our automation.
Figure 18: Configuring the Automation
With these Smart Values, you can manipulate all the data of an issue.)
Figure 19: Creating a Variable for Automation
Now, with the obtained "User" data (User ID), we can query for different information through the Atlassian REST API.
Figure 20: Communication With API
Finally, we are ready to add the data we obtained through API communication to our alarms.
Figure 21: Edit the Alert Output
If you wish, you can also examine these values and the API structure using Postman.
Figure 22: API Usage on Postman
We have completed our automation! Now, whenever an external user is added to any Atlassian environment:
The before and after states of the alarm, in terms of automation processes, will look as follows:
Figure 23: Before automation processes
Figure 24: After automation processes
For more information about Jira automation syntax, you can refer to the following resources: Jira Cloud automation | Cloud automation Cloud | Atlassi an Support
Atlassian platforms offer strong tools for organizing work and collaborating, but when using these tools, safety and data integrity are crucial. Transferring Atlassian logs to a tool like Splunk, setting up alerts, and handling them in a user-friendly system can boost security and performance. This is a vital step in spotting possible security breaches, reacting quickly, and enhancing business processes. Yet, sometimes, like in our situation, there might be log shortages that reduce what we can see and how fast we can respond, and enriching logs may not always be doable. In such situations, an alternative option is to enrich the content of our alarms through automation. This allows us to:
It's important to remember that this work is in the initial stages. Refining detection rules is a continuous process that requires security teams to develop detection content with threat-centric focus.