GuardDuty is predominantly used to find anomalies, particularly security anomalies when trying to probe a hosted public cloud service. For example, we work with Zuora, and have many public services running at AWS, and our concern is external parties. So, if a hacker or an attacker tries to probe our systems, Amazon GuardDuty tries to find anomalies or any vulnerabilities within our systems.
GuardDuty takes multiple sources of logs. In AWS, we have several logging services like AWS CloudTrail and VPC Flow Logs. VPC Flow Logs involve incoming and outgoing traffic from the internet, so if someone tries to get into a system or access one of our publicly hosted AWS, we are able to get that traffic via VPC Flow Logs. AWS CloudTrail is within the public cloud infrastructure, and AWS-specific API calls are involved. So, if someone tries to do some API activity specific to AWS within the infrastructure, this will be a source. These are multiple sources of logs that Amazon GuardDuty consumes as input to analyze the traffic for any security anomalies. So, based on these sources, the solution helps us report findings if security anomalies occur in our systems from the internet or within the cloud infra, cloud account, or AWS account.
AWS is account-specific, and last year, I believe AWS included something related to Kubernetes monitoring or Kubernetes Logs. So if we use EKS within the Kubernetes service and an anomaly occurs, some anomaly traffic is seen in the Kubernetes cluster, and it will be able to identify. That is a good feature they recently added in testable APIs.
Amazon GuardDuty could be better enriched in threat intelligence data. An internal AWS threat intelligence team works 24 hours to enrich customers. That service could be leveraged if there is any new attack, new security vulnerability, or exploitation. Day-to-day hackers find new vulnerabilities, so Amazon GuardDuty should be up to date and help customers find issues.
Kubernetes Logs was missing but is now included. The solution covers most incoming sources in an S3 bucket, storage level, public internet traffic, the cloud infrastructure, the AWS account, and multiple accounts in Kubernetes. So there aren't any missing pieces with Amazon GuardDuty, especially from a monitoring perspective.
Another valuable feature is the delegation service. Even if there are hundreds of accounts, some part of the account is for security, some for DevOps, and some for developers. Certain accounts are assigned within AWS. For example, for Amazon GuardDuty, a master account of the administrator assigns Amazon GuardDuty's administration and full access to our secure account. Once the delegation is done, we work with the tool, the findings, and what it reports to then validate the findings. So, in this situation case, AWS has efficient features.
We have been using this solution for three years.
It is a stable solution, especially if you compare it to Azure or GCP, so we don't have any complaints about the stability. Other solutions have similar features, but we don't know how enriched those features are.
We have around five people on the security team, and it is very small. However, for large companies like Google or Microsoft that invest a large number of resources, they may have about 50 to 75 people on their team.
Another useful feature is the ability for Amazon GuardDuty to manage hundreds of accounts. There is usually a master account, and the remaining 99 accounts are member accounts. So if you push an order via the master account everything takes place in those 99 member accounts. Most companies don't want to give people access to the master account even to their operations, DevOps, infrastructure or development teams.
With Amazon GuardDuty, most of the tools have a delegation feature. So, from the master account, the administrator can delegate administrator access to a security account. So on our security team, we have our account in AWS, which is part of the master account. Under the master account, the administrator will give us access as a delegated administrator. Once the administrator delegates the security account, our five people team takes care of all the tasks around the solution.
We have full access to configuring, monitoring and automation. The administrator can delegate the DevOps tool or service and the AWS office to the DevOps team account. So the DevOps team can take care of building automation, managing, and administering that particular service around the DevOps service. So, in this case, Amazon GuardDuty is delegated to our security account, and we manage it completely.
Scalability is good. Companies will usually run across multiple accounts in AWS, and their resources run about a hundred accounts. However, one of the past companies I absolved ran close to a thousand accounts, and in that situation, the Amazon GuardDuty scalability factor was important.
Also, suppose a company is not leveraging AWS Organization which is very rare, AWS still provides risk APIs or their SD case, where a developer can write a script or automation to deploy seamlessly within a short time. Our security team predominantly uses Amazon GuardDuty. The cybersecurity team monitors the anomalies that occur using Amazon GuardDuty.
The technical support is great. I've contacted AWS support multiple times, and they've resolved the query. They have three technical support features, namely chat support, phone support, and web support, where we can raise a query, and they reply to us. Most of the time, we leverage the phone call feature, and once we input our concerns for the queries, they'll reach out to us over the phone and share a chime link screen sharing service. They try to understand our problems and the areas of concern and provide a solution.
The only concern is that it takes some time to assign someone when we reach out for technical support via phone service. It takes at least 45 minutes to get connected, and time is spent on hold waiting for someone to join from AWS.
Deployment does not take long if it is an account-specific or AWS organization level. My company has around a hundred AWS accounts, so deploying across a hundred AWS accounts was pretty easy. AWS also provides AWS Organization, where one account acts as a master, and the rest of the 19 accounts are member accounts under this master. So once you give an order to the master, you can invoke Amazon GuardDuty across all the accounts. So deployment is great, and we didn't face any big challenges.
I rate this solution an eight out of ten. Amazon GuardDuty is a very good service, and we are not planning to change it any time soon.
Regarding advice, it would be good to have data events for Amazon GuardDuty and Kubernetes for monitoring. Data events mean you have an S3 bucket for storing objects or files, and if someone tries to access or monitor those files, API calls will occur, and those transactions will be monitored. So until you enable the data event feature within the Amazon GuardDuty, if someone makes a call at the object or file level, it is something we might miss. Also, there are certain features that are not enabled by default on Amazon GuardDuty.
