AWS has announced Security Hub: https://aws.amazon.com/security-hub/
aws_securityhub_account
aws_securityhub_member
aws_securityhub_product_subscription
aws_securityhub_standards_subscription
aws_securityhub_invite_accepter
aws_securityhub_insight
# Used to enable AWS Security Hub
resource "aws_securityhub_account" "example" {}
# Subscribe to the CIS AWS Foundations Benchmark
resource "aws_securityhub_standards_subscription" "example" {
depends_on = ["aws_securityhub_account.example"]
standards_arn = "arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/1.2.0"
}
# Subscribe to a third party provider
data "aws_region" "current" {}
resource "aws_securityhub_product_subscription" "example" {
depends_on = ["aws_securityhub_account.example"]
product_arn = "arn:aws:securityhub:${data.aws_region.current.name}:679703615338:product/armordefense/armoranywhere"
}
# Add a member AWS account
resource "aws_securityhub_member" "example" {
depends_on = ["aws_securityhub_account.example"]
account_id = "123456789012"
email = "[email protected]"
invite = true
}
resource "aws_securityhub_account" "invitee" {
provider = "aws.invitee"
}
resource "aws_securityhub_invite_accepter" "invitee" {
provider = "aws.invitee"
depends_on = ["aws_securityhub_account.invitee"]
master_id = "${aws_securityhub_invitation.example.master_id}"
}
# Create an insight (group of findings)
resource "aws_securityhub_insight" "example" {
depends_on = ["aws_securityhub_account.example"]
name = "Example"
group_by_attribute = "AwsAccountId"
filters {
generator_id {
comparison = "EQUALS"
value = "123456"
}
}
}
Remember to replace ${var.region}
as appropriate (or define that variable)
arn:aws:securityhub:${var.region}::product/aws/guardduty
arn:aws:securityhub:${var.region}::product/aws/inspector
arn:aws:securityhub:${var.region}::product/aws/macie
arn:aws:securityhub:${var.region}:733251395267:product/alertlogic/althreatmanagement
arn:aws:securityhub:${var.region}:679703615338:product/armordefense/armoranywhere
arn:aws:securityhub:${var.region}:151784055945:product/barracuda/cloudsecurityguardian
arn:aws:securityhub:${var.region}:758245563457:product/checkpoint/cloudguard-iaas
arn:aws:securityhub:${var.region}:634729597623:product/checkpoint/dome9-arc
arn:aws:securityhub:${var.region}:517716713836:product/crowdstrike/crowdstrike-falcon
arn:aws:securityhub:${var.region}:749430749651:product/cyberark/cyberark-pta
arn:aws:securityhub:${var.region}:250871914685:product/f5networks/f5-advanced-waf
arn:aws:securityhub:${var.region}:123073262904:product/fortinet/fortigate
arn:aws:securityhub:${var.region}:324264561773:product/guardicore/aws-infection-monkey
arn:aws:securityhub:${var.region}:324264561773:product/guardicore/guardicore
arn:aws:securityhub:${var.region}:949680696695:product/ibm/qradar-siem
arn:aws:securityhub:${var.region}:955745153808:product/imperva/imperva-attack-analytics
arn:aws:securityhub:${var.region}:297986523463:product/mcafee-skyhigh/mcafee-mvision-cloud-aws
arn:aws:securityhub:${var.region}:188619942792:product/paloaltonetworks/redlock
arn:aws:securityhub:${var.region}:122442690527:product/paloaltonetworks/vm-series
arn:aws:securityhub:${var.region}:805950163170:product/qualys/qualys-pc
arn:aws:securityhub:${var.region}:805950163170:product/qualys/qualys-vm
arn:aws:securityhub:${var.region}:336818582268:product/rapid7/insightvm
arn:aws:securityhub:${var.region}:062897671886:product/sophos/sophos-server-protection
arn:aws:securityhub:${var.region}:112543817624:product/splunk/splunk-enterprise
arn:aws:securityhub:${var.region}:112543817624:product/splunk/splunk-phantom
arn:aws:securityhub:${var.region}:956882708938:product/sumologicinc/sumologic-mda
arn:aws:securityhub:${var.region}:754237914691:product/symantec-corp/symantec-cwp
arn:aws:securityhub:${var.region}:422820575223:product/tenable/tenable-io
arn:aws:securityhub:${var.region}:679593333241:product/trend-micro/deep-security
arn:aws:securityhub:${var.region}:453761072151:product/turbot/turbot
arn:aws:securityhub:${var.region}:496947949261:product/twistlock/twistlock-enterprise
aws_securityhub_account
aws_securityhub_member
aws_securityhub_invite_accepter
aws_securityhub_insight
aws_securityhub_standards_subscription
aws_securityhub_product_subscription
I'm planning to work on this.
Reference:
https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_EnableSecurityHub.html
To enable SecurityHub in the master account
https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_EnableImportFindingsForProduct.html
To enable findings for an integrated product
https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_BatchEnableStandards.html
To turn on standards (eg. CIS benchmark)
@jsamuel1 @philsynek @tdmalone @brandonstevens: Any feedback on the design/examples above? I'm considering a few things:
I think we need an aws_securityhub_account
as a way of enabling/disabling Security Hub, but it doesn't export any attributes used by any of the other resources so they need to use an explicit dependency on it. Does this feel OK to you? The alternative would be for other resources to just enable Security Hub when needed, but then there's no good way to turn it off.
I might get rid of the aws_securityhub_invitation
resource and have sending an invite as parameter that can be disabled on aws_securityhub_member
instead. There doesn't seem to be any good use case for adding a member account but not inviting them, and once an invite is sent the only way to revoke it is to delete the member and recreate it again which doesn't fit well with Terraform.
I might rename aws_securityhub_standard
to aws_securityhub_standard_subscription
- this matches the way the API returns a StandardsSubscriptionARN when enabling a standard. Is this a better naming? It matches aws_securityhub_product_subscription
. It also means if we have a data source in the future for getting a standard by name it can be called aws_securityhub_standard
.
Following in the same style as aws_guardduty_member
I'll look at having a combined resource that creates a member and sends an invite. I'm also going to rename aws_securityhub_standard
to aws_securityhub_standard_subscription
re: aws_securityhub_standard_subscription - @gazoakley, might be best to keep the plural from the aws API - ie. aws_securityhub_standards_subscription.
I think the separate aws_securityhub_account is needed, so that we can turn securityhub on/off - otherwise there is no reliable way to roll back to a previous state. Would the other API's return an error if securityhub isn't on?
For organization/multi-account usage, using the _member API, does this scenario negate the need to explicity enable in the child accounts?
re: aws_securityhub_standard_subscription - @gazoakley, might be best to keep the plural from the aws API - ie. aws_securityhub_standards_subscription.
It really bugs me that they named standards with a plural (when you're enabling an individual standard) but not product (which seems more natural). I guess I should rename to be consistent with the API though.
I think the separate aws_securityhub_account is needed, so that we can turn securityhub on/off - otherwise there is no reliable way to roll back to a previous state. Would the other API's return an error if securityhub isn't on?
They do return an error - I'm relying on that behaviour right now to detect if the aws_securityhub_account
is present to manage state correctly. I think keeping that resource is probably the best course.
For organization/multi-account usage, using the _member API, does this scenario negate the need to explicity enable in the child accounts?
Doesn't look like it from testing through the console - you still need to send an invite and accept it in the other account even if both accounts are part of the same organization.
The aws_securityhub_account
and aws_securityhub_standards_subscription
resources have been released in version 1.52.0 and version 1.53.0 of the AWS provider respectively. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.
any plans for aws_securityhub_insight
and maybe aws_securityhub_action
?
Any current plans for aws_securityhub_member
and aws_securityhub_invite_accepter
resources to support multi account setups? I think they would operate in a similar way to the existing aws_guardduty_member
and guardduty_invite_accepter
resources
Thanks!
Is there any chance of a aws_securityhub_action_target
resource? This would enable things like this: https://aws.amazon.com/blogs/apn/how-to-integrate-aws-security-hub-custom-actions-with-pagerduty/
Edit D'oh. This is already in progress as #10493
The new aws_securityhub_member
resource has been merged and will release with version 2.54.0 of the Terraform AWS Provider, later this week. 馃憤
I'm pretty new to Terraform development and I'm interested in taking a look at the aws_securityhub_insight
resource. One question that I have is when defining the resource schema, is it necesssary to define all of the AwsSecurityFindingFilters listed here?
https://docs.aws.amazon.com/sdk-for-go/api/service/securityhub/#AwsSecurityFindingFilters
Any current plans for
aws_securityhub_member
andaws_securityhub_invite_accepter
resources to support multi account setups? I think they would operate in a similar way to the existingaws_guardduty_member
andguardduty_invite_accepter
resourcesThanks!
Looking forward to the release of aws_securityhub_invite_accepter
There is also aws_securityhub_custom_action
tracking an open PR ready for code review. https://github.com/terraform-providers/terraform-provider-aws/pull/10493
Support for the aws_securityhub_action_target
(custom action) resource has been merged and will release with version 3.4.0 of the Terraform AWS Provider, later this week. Thanks to @hhamalai for the implementation there. 馃憤
Most helpful comment
Any current plans for
aws_securityhub_member
andaws_securityhub_invite_accepter
resources to support multi account setups? I think they would operate in a similar way to the existingaws_guardduty_member
andguardduty_invite_accepter
resourcesThanks!