If not, then you should be…and here’s why.

Most organizations leverage clouds providers (like AWS, Azure, etc.) extensively these days. Typically public cloud is an integral part of the overall roadmap, with most organizations having some form of a hybrid model. The hybrid model involves a private cloud (internal managed data center) along with a securely connected public cloud. The public cloud allows for required elasticity to meet unexpected demands of a growing organization, while the pay-as-you-go model works quite well alongside.

One of the vital things in maintaining a good overall security posture is vulnerability management (VM) of all the infra i.e. infra in the data center and public cloud as well. In the current pay-as-you-go era, organizations tend to employ SaaS services for their needs and vulnerability management is no different story. However, using a SaaS VM service implies that the organization needs to share their cloud credentials with their SaaS VM service provider. Any organization would be (and should be) weary of sharing credentials of their public cloud with a different SaaS provider. Why? In the event that the SaaS provider gets breached, the cloud credentials of the organization could be compromised.

In some cases, your VM SaaS may provide an agent (binary executable) that needs to be deployed. This binary may require special permissions during execution to collect inventory by itself or it will likely leverage the native inventory mechanism provided by your cloud provider. The latter is better. But it is not recommended to deploy a binary agent as you cannot possible inspect the code of the binary to trust it.

ThreatWatch provides ‘twigs’ – ThreatWatch Information Gathering Script, a means to perform asset discovery from cloud providers amongst other things. twigs provides out of the box support for cloud providers like AWS and Azure. twigs can be run locally in the data center of the organization and it will push details about the assets discovered to ThreatWatch instance (securely over HTTPS). twigs will prompt for cloud credentials to perform discovery of assets in the cloud. However, twigs does not record or save these cloud credentials and as twigs runs locally on-premise, there is no reason to share the cloud credentials with ThreatWatch instance. What’s more is that twigs is open source (source code on GitHub) and available as a python package. twigs being open source, its code is available for everyone to inspect.

With ThreatWatch, organizations can now say “No” to sharing their public cloud credentials with SaaS VM providers and ensuring a good security posture.

Reach out to us at info@threatwatch.io for more details on how you could leverage twigs for your organization.

Leave a Reply

Your email address will not be published. Required fields are marked *