First-hand dealing with security incident

For context

Recently, there is a vulnerability that is found in an on-prem server that is being exploited like a wildfire. If you have not heard about it, feel free to read more about it here. It is also known as CVE-2021-26084 RCE on Confluence Servers.

RCE stands for Remote Code Execution with a CVE rating of 9+ is one of those very serious exploits where it gives the hacker full access to the server to install and execute almost anything. Furthermore, the exploit is as simple as a one-liner on a REST endpoint. Even a beginner can give a short at this exploit.

Since we are a huge advocate of Atlassian, we are not spared either as we have many servers out there created for demo purposes.

Experiencing it live

As we already have our app subscribed to the bug bounty program. This is where I know about this threat. Since I wasn’t the service owner of the reported service, I proceed by reporting this as a security incident through our internal ticketing system. The fallback for all this would be IT to help to identify and remediate the issue.

I guess since this was reported internally. We took this a little too lightly until we received another round of alerts. This time, directly from AWS about us abusing the network through massive scanning. On the hind side, the hacker could have got away a little longer if they didn’t set their script to abuse the network.

Back to the story, with this abnormal message, we immediately trigger our CSIRT (Cybersecurity Incident Response Team) to investigate the issue. That is where we found out that, our system has been compromised by this BotNet.

First thing first, stay calm and damage control. In this kind of scenario, CSIRT should have full authority to contain the threat at all costs. Next, forensic to scan through the logs to identify, block/kill that malware.

Finally, once everything has settled down. Proceed with continuous improvement through PIR (Post Incident Response) and be sure to follow up with all the actionable items to make the environment secure and foolproof in case of a similar event in the future.

The caused

For one, I think is negligent. Like any other software company, we usually need to communicate with our partners before we announce this sort of vulnerability to the public.

In our case, an email was received but it was overlooked. Honestly, in this modern-day working environment, I sort of understand why. Our inboxes are usually so full that we don’t have time to read everything. We often depend on filters to get by our emails. Besides that, I also believe that the lack of education such as understanding such email such as CVE rating is to understand by any other people, besides those that are working in the cybersecurity space.

Moreover, it also requires extra effort for the service owner to do the upgrade, and risk the working demo when presenting to the customer.

Improvement

Always begin with education. Especially for a large company, this would mean spending extra on training. Eg. for every level of promotion also holds extra responsibility that should come with appropriate training to equip them with the responsibility they have. And of course, this should include understanding security-related stuff such as CVE rating.

Besides that, build a good process around managing and reporting incidents. Reduce the barrier for people to report, as this is vital when it concerning the security of the company. Also, use available or existing security frameworks such as CAIQ or NIST, to start building a good process for the company. Believe me, it will go a long way beyond just security.