When an analyst investigates an alert, whether it’s a risk that might lead to a problem or a potential threat that might indicate a problem has already occurred, the alert is usually the start of the job rather than the end.  

For example, if an analyst was responding to this fairly mundane alert indicating that a production Jenkins server was running an out-of-support version of Ubuntu, the analyst might need to answer a number of questions before formulating a response to ensure that they’ve taking into account the possibility that this might be the indicator of much larger problems.  Some questions our analyst might want to ask:

  • What is the asset’s exposure and what else might it have access to?
  • What is this asset and what does it do?
  • What other problems does it have?
  • Knowing that the asset has been neglected, are there indications that it has been compromised?
  • Is there sensitive information on or available from the asset?

Without Orca’s extensive visibility and context, our analyst might have to go through multiple different systems to gather data, spending quite a bit of time extracting intelligence from a bunch of places. Fortunately, Orca Security puts all of this intelligence and more at the analyst’s fingertips. By clicking on the Go to Asset link, we can see everything about this virtual machine (VM).

Assessing Exposure

From the alert, we can already see that this VM is public facing; however, we probably want to know more. From the asset page, we can quickly see that an AWS security group allows access on tcp/22 and tcp/52552. We could also look at what an attacker might be able to do if they compromised the asset in the blast radius and lateral movement graphs as well as understanding what identities would be able to access it via the access map graph.

Digging Deeper

Now that we know that our problem VM is accessible to the outside world, we might want to understand more about it. The name of the VM suggests that this is a production Jenkins server and software inventory confirms this. We can even dig into the installed versions of particular packages – Jenkins 2.73 is quite old. 

Risks and Threats

This information would lead an analyst to our next two questions – if we’re running an out of date operating system and an old version of the primary application on the VM, what else is wrong? Are there any indications that the problems here have been exploited?

The Risk tab gives us a wealth of intelligence here. First, we can view all alerts on this asset (unsurprisingly, there are a lot) and we can group and filter them immediately. By grouping by the alert type, we are able to see that there are alerts for malware and suspicious activity.

We can also jump directly to details of the found malware to better understand, dig into the suspicious commands that were executed, and download logs & files such as the .bash_history files where we found the commands for further investigation.

With indications of a compromise, we’ll now have to begin looking at where an attacker might have gotten from here. The graphs we looked at earlier, particularly blast radius and lateral movement, will help to guide our investigation from here; for example, WEB-NGINX and DEV-RND would be high profile targets for our diligent threat actor.

Conclusion

The faster our analysts can understand the context of an alert, the more efficient their response is. Orca’s Unified Data Model, which incorporates a wide range of information about cloud resources, workloads, identities, data, and more, and the asset view that surfaces all of these attributes into a single, consumable view, gives analysts (and everybody else) a toolkit to supercharge their work.

To see how Orca will enable your people, why not get in touch for a demo or see it for yourself in a free risk assessment.