Developer at a sports company with 501-1,000 employees
Real User
Top 5
2024-03-01T07:14:00Z
Mar 1, 2024
One improvement I would suggest for AWS GuardDuty is the ability to assign findings to specific users or groups, facilitating better communication and follow-up actions. It would be beneficial to have a knowledge bank where past findings and actions taken are stored, aiding in handling repeat incidents and providing historical precedence for new team members.
The solution's user interface could be improved because it will help users to understand multiple options. Currently, we have multiple options on AWS GuardDuty, which may confuse new users.
IT Controller at a outsourcing company with 11-50 employees
Real User
Top 20
2024-01-17T07:22:19Z
Jan 17, 2024
I work in a bank, and it would be good if AWS GuardDuty could be integrated with other monitoring and detection tools we use. The operation team can use a single desktop to monitor.
For AWS, there are other services online that I would go to and compare features with to determine the best option for my initial needs. The point is, once we need these kinds of services on a larger scale, we probably need a bigger partner or client-customer base to work with. From my perspective of educational purposes and cloud development approach, it's not there yet. I have some initial insights about helpful features in GuardDuty, but I don't yet have the clientele to apply them to large-scale infrastructure protection. That's where I would explore threat detection and endpoint protection further, especially since global threats. For vulnerability checking, I have other integrations that help my development pipelines build securely. My images and code are typically scanned every time to ensure I'm not harboring internal vulnerabilities. However, protecting the external perimeter requires something bigger, and that's where Palo Alto Cortex XDR and similar products come in. Here, for threat detection, my browser has an add-on, which is truly helpful. Every time you access a page, it scans it immediately, flagging potential threats, even false positives, to alert you before you dive deeper into an unfamiliar site. The problem of scale is very fundamental to me. Over the past five or ten years, since the emergence of cloud infrastructure and the proliferation of distributed software products, I've been focused on developing backends for various solutions. The rise of cyber threats prompted me to consider how to protect the endpoints exposed to clients. With numerous endpoints today, as we deploy every version of our software, often multiple times a day, ensuring that none of them becomes a target is crucial. For such large-scale infrastructure protection, my preference would be to explore another AWS offering. Specifically, if my deployment is in the Amazon cloud, I would turn to AWS Shield.
Amazon GuardDuty is limited to certain services. The solution has to be integrated with new services that AWS adds like QuickSight, Managed Airflow, AppFlow and MWAA. By being integrated with these services, it would be handy for users and save time.
While sending the alerts to the email, they are not being patched. we have to do the patching and mapping manually. If GuardDuty could include a feature to do this automatically, it will make our job easier. That is something I believe can be improved. For example, suppose you want to know when an alert is sent to your mailbox. The information is in JSON format. It would be helpful if that could be sent to the mailbox in a human-readable format. I believe it can be improved in a variety of ways. If we can build our own use cases instead of using Microsoft Sentinel alone, that would be ideal.
Improvement-wise, Amazon GuardDuty should have an overall dashboard analytics function so we could see what's in the current environment, and then in addition to that, provide best practices and recommendations, particularly to provide some type of observability, and then figure out the login side of it, based on our current environment, in terms of what we're not monitoring and what we should monitor. The solution should also give us a sample code configuration to implement that added feature or feature request. What I'd like to see in the next release of Amazon GuardDuty are more security analytics, reporting, and monitoring. They should provide recommendations and additional options that answer questions such as "Hey, what can we see in our environment?", "What should we implement within the environment?", What's recommended?" We know that cost will always be associated with that, but Amazon GuardDuty should show us the increased costs or decreased costs if we implement it or don't implement it, and that would be a good feature request, particularly with all products within AWS, just for cloud products in general because there are times features are implemented, but once they're deployed, they don't tell you about costs that would be generated along with those features. After features are deployed, there should a summary of the costs that would be generated, and projected based on current usage, so they would give us the option to figure out how long we're going to use those features and the option to keep those on or turn those off. If more services were like that, a lot more people would use those on the cloud.
Information Security Manager at Tata Consultancy Services
Real User
2022-04-27T08:20:29Z
Apr 27, 2022
An improvement would be to have a mobile version where remote workers can log in and monitor and fix issues. In the next release, I'd like Amazon to add a pane to visualize all seven layers of security.
Amazon Guard Duty is a continuous cloud security monitoring service that consistently monitors and administers several data sources. These include AWS CloudTrail data events for EKS (Elastic Kubernetes Service) audit logs, VPC (Virtual Private Cloud) flow logs, DNS (Domain Name System) logs, S3 (Simple Cloud Storage), and AWS CloudTrail event logs. Amazon GuardDuty intuitively uses threat intelligence data - such as lists of malicious domains and IP addresses - and ML (machine learning) to...
The product needs to improve its cost-efficiency since it is expensive.
One improvement I would suggest for AWS GuardDuty is the ability to assign findings to specific users or groups, facilitating better communication and follow-up actions. It would be beneficial to have a knowledge bank where past findings and actions taken are stored, aiding in handling repeat incidents and providing historical precedence for new team members.
The solution's user interface could be improved because it will help users to understand multiple options. Currently, we have multiple options on AWS GuardDuty, which may confuse new users.
I work in a bank, and it would be good if AWS GuardDuty could be integrated with other monitoring and detection tools we use. The operation team can use a single desktop to monitor.
For AWS, there are other services online that I would go to and compare features with to determine the best option for my initial needs. The point is, once we need these kinds of services on a larger scale, we probably need a bigger partner or client-customer base to work with. From my perspective of educational purposes and cloud development approach, it's not there yet. I have some initial insights about helpful features in GuardDuty, but I don't yet have the clientele to apply them to large-scale infrastructure protection. That's where I would explore threat detection and endpoint protection further, especially since global threats. For vulnerability checking, I have other integrations that help my development pipelines build securely. My images and code are typically scanned every time to ensure I'm not harboring internal vulnerabilities. However, protecting the external perimeter requires something bigger, and that's where Palo Alto Cortex XDR and similar products come in. Here, for threat detection, my browser has an add-on, which is truly helpful. Every time you access a page, it scans it immediately, flagging potential threats, even false positives, to alert you before you dive deeper into an unfamiliar site. The problem of scale is very fundamental to me. Over the past five or ten years, since the emergence of cloud infrastructure and the proliferation of distributed software products, I've been focused on developing backends for various solutions. The rise of cyber threats prompted me to consider how to protect the endpoints exposed to clients. With numerous endpoints today, as we deploy every version of our software, often multiple times a day, ensuring that none of them becomes a target is crucial. For such large-scale infrastructure protection, my preference would be to explore another AWS offering. Specifically, if my deployment is in the Amazon cloud, I would turn to AWS Shield.
For the next release, they could provide IPS features as well.
It would be great if the solution had some automation capabilities. It should provide auto-remediation and threat handling with automation.
We currently find Lacework to be much better at detecting vulnerabilities than AWS GuardDuty. The engines of AWS GuardDuty have to be improved.
Amazon GuardDuty is limited to certain services. The solution has to be integrated with new services that AWS adds like QuickSight, Managed Airflow, AppFlow and MWAA. By being integrated with these services, it would be handy for users and save time.
While sending the alerts to the email, they are not being patched. we have to do the patching and mapping manually. If GuardDuty could include a feature to do this automatically, it will make our job easier. That is something I believe can be improved. For example, suppose you want to know when an alert is sent to your mailbox. The information is in JSON format. It would be helpful if that could be sent to the mailbox in a human-readable format. I believe it can be improved in a variety of ways. If we can build our own use cases instead of using Microsoft Sentinel alone, that would be ideal.
Improvement-wise, Amazon GuardDuty should have an overall dashboard analytics function so we could see what's in the current environment, and then in addition to that, provide best practices and recommendations, particularly to provide some type of observability, and then figure out the login side of it, based on our current environment, in terms of what we're not monitoring and what we should monitor. The solution should also give us a sample code configuration to implement that added feature or feature request. What I'd like to see in the next release of Amazon GuardDuty are more security analytics, reporting, and monitoring. They should provide recommendations and additional options that answer questions such as "Hey, what can we see in our environment?", "What should we implement within the environment?", What's recommended?" We know that cost will always be associated with that, but Amazon GuardDuty should show us the increased costs or decreased costs if we implement it or don't implement it, and that would be a good feature request, particularly with all products within AWS, just for cloud products in general because there are times features are implemented, but once they're deployed, they don't tell you about costs that would be generated along with those features. After features are deployed, there should a summary of the costs that would be generated, and projected based on current usage, so they would give us the option to figure out how long we're going to use those features and the option to keep those on or turn those off. If more services were like that, a lot more people would use those on the cloud.
An improvement would be to have a mobile version where remote workers can log in and monitor and fix issues. In the next release, I'd like Amazon to add a pane to visualize all seven layers of security.