[PFR] ElectricEye Auditor Expansion about electriceye

[jonrau1]

@bleemb merged #60 ! Thanks again those policy checks are really damn good!

@routeronion ah yeah that should be updated - the insights moved into the controller.py it's an option in the CLI to apply them now!

[bleemb]

I'll pick up the SQS checks as a start

[bleemb]

PR for SQS Encryption and public access raised

[bleemb]

Updated PR to include Amplify checks

[bleemb]

Finished off EFS tonight, will pick up the CodeArtifact checks tomorrow.

[routeronion]

@jonrau1, I did notice in the README that step 5 references an insights directory to create SecurityHub insights, and contains a electriceye-insights.py script. I didn't see this anywhere in the repo, but looks like there is an insights.py that seems to be performing that task. Should that be updated?
Thanks,
David

[jonrau1]

@jonrau1, for some proposed checks, like OriginShield, not sure what sort of standard that would align with, so wanted to get your thoughts.
BTW, I ended up forking this like some other folks and will push to that until ready for a PR.

Origin Shield is a caching/availability check so you can yoink one of the Caching checks from API Gateway for that. I can make edits or propose them in the future PRs.

[bleemb]

Shield Attacks in the last week is done, pending PR 👍 Check number 300 :)

[routeronion]

Only remaining to-do is CloudFront (@routeronion I think you still have those, right?), FSx (plus Backup for it) and CloudHSM

Need to finish Detect-Secrets for Lambda, finish off Lambda Layers, and add some MSK checks. @bleemb anything else you can think of? I am reaching into the nethers of AWS services for anything that could've been missed lol

Yeah, been a little swamped this week but will try to carve out time for the CloudFront items. I'll time box if it seems I'm slowing things down :)

[bleemb]

@jonrau1 exactly right - so perhaps we park that one for the time being. I'm inclined to go at it a different way and base the logic on the inline/customer managed policy, rather than the User, Group or Role that it's attached to. Doing it that way should reduce duplication, where policies are re-used across those IAM objects. Will also mean that we are flagging the exact object that's misconfigured, as opposed to an object with a relationship to a misconfiguration - which should make triage easier. That said, it's still important for context (Alarm bells sounding when a ViewOnly policy has ec2:* on it...) so I think ideally the alert would contain the relationships. I'm not wedded to that outlook, can go down the User/Group/Role route if you'd prefer.

[bleemb]

Good call on the inline policies- the morning coffee hasn't kicked in just yet! Yep - I'll be looking to cache as much as I can, there'll be quite a few API calls involved in these so where I can consolidate I absolutely will. I think there'd be a pretty large degree of opinions on what we'd want to alert on. I know there are a lot of companies that are blanket no service:/resource: policy in Production workloads - whereas for others that'd be perfectly acceptable. Trying to hit that happy medium, I'm thinking along the lines of breaking it down to 3 groups rather than just 2:

• action: * , resource: * == Failing, high
• action:* , resource: [list of resources] == Failing, medium/low?
• action:* , resource: single resource or resource arn pattern == Passing
  For all above, presence of a condition will lead to a passing check. I started down that track of evaluating conditions with some of the SQS publicity checks initially, but from testing it's really hard to get right 100% of the time - so I think it's better to leave it out altogether. I'd rather we miss stuff than have FP's/incorrect alerts.

[routeronion]

@jonrau1 just an FYI that I have a few checks done in my fork for CloudFront and plan to have all wrapped up in the next day or 2 and will do some testing. After that, I can try to take on CloudHSM.

[bleemb]

@jonrau1 just an FYI that I have a few checks done in my fork for CloudFront and plan to have all wrapped up in the next day or 2 and will do some testing. After that, I can try to take on CloudHSM.

Hey @routeronion just a heads up that I've already completed the CloudHSM checks that had been listed as part of my fork :)

[jonrau1]

@routeronion I think the only outstanding checks after CloudFront are FSX (and its associated Backup check). As @bleemb noted he took care of CloudHSM.

There are a few more weird ones we can look at adding just for fun

• SageMaker Root/Privilege Access Flag on Notebooks
• Amazon Comprehend Classifiers running in VPC check (I assume it returns an empty list, or none at all) (https://docs.aws.amazon.com/comprehend/latest/dg/usingVPC.html)
• FinSpace AuthN Check for SAML
• DNSFW Attached to VPC, Rt53 Resolver Logging for VPC, Fail Open Check for DNSFW

[routeronion]

@jonrau1 just wanted to give you a heads up that the remaining CloudFront checks have been completed, but realized that the initial test for the first check (trusted signers), is not running properly, so looking into this. Hopefully once that is fixed I can get all other tests to work properly since I based them off of the first test and is leveraging the same calls.

[jonrau1]

X-Ray complete

[jonrau1]

ECS Privileged Container (Task Def) Check complete

ECS complete

[jonrau1]

ELBv2 ALB HTTP Desync check added. EKS Envelope encryption check added. Updated latest K8s version check.

[jonrau1]

Lambda X-Ray complete

Lambda is pretty much complete

[jonrau1]

Added Secure Enclave check for EC2

[jonrau1]

Cloud9 Complete

[jonrau1]

Added 2 more basic EC2 checks

[jonrau1]

DataSync Complete

[jonrau1]

Cloudsearch complete

[jonrau1]

Shodan for CloudFront complete.

[jonrau1]

@bleemb #59 merged, thanks for the contributions!

[bleemb]

@bleemb #59 merged, thanks for the contributions!

No worries, happy to help :)

[routeronion]

@jonrau1 any preference on the branch to push proposed changes to? I have an additional CloudFront check but want to align with your process.

[jonrau1]

@jonrau1 any preference on the branch to push proposed changes to? I have an additional CloudFront check but want to align with your process.

You can submit PRs against the current "pfr" branch

[routeronion]

@jonrau1, for some proposed checks, like OriginShield, not sure what sort of standard that would align with, so wanted to get your thoughts.
BTW, I ended up forking this like some other folks and will push to that until ready for a PR.

[jonrau1]

Security Services WAFv2 and WAFv2 Auditor complete.
Added additional LM checks
Airflow Complete
SGs, EC2, EFS, CodeArtifact complete

[jonrau1]

Only remaining to-do is CloudFront (@routeronion I think you still have those, right?), FSx (plus Backup for it) and CloudHSM

Need to finish Detect-Secrets for Lambda, finish off Lambda Layers, and add some MSK checks. @bleemb anything else you can think of? I am reaching into the nethers of AWS services for anything that could've been missed lol

[bleemb]

Only remaining to-do is CloudFront (@routeronion I think you still have those, right?), FSx (plus Backup for it) and CloudHSM

Need to finish Detect-Secrets for Lambda, finish off Lambda Layers, and add some MSK checks. @bleemb anything else you can think of? I am reaching into the nethers of AWS services for anything that could've been missed lol

I can pick up the HSM checks. I'm also going to add Cluster degradation to it ,as distinct from the underlying HSMs. As far as other checks are concerned, a few that come to mind are:
ACM: Validation Status Failure, Renewal Status at Failed or Pending Validation
IAM: Service:* permissions in policy docs
ec2: Using an AMI created in the last 6 months

Happy to defer these to a seperate PFR push if we want to just get it over the line. I'll leave it up to you @jonrau1

[jonrau1]

Only remaining to-do is CloudFront (@routeronion I think you still have those, right?), FSx (plus Backup for it) and CloudHSM

Need to finish Detect-Secrets for Lambda, finish off Lambda Layers, and add some MSK checks. @bleemb anything else you can think of? I am reaching into the nethers of AWS services for anything that could've been missed lol

I can pick up the HSM checks. I'm also going to add Cluster degradation to it ,as distinct from the underlying HSMs. As far as other checks are concerned, a few that come to mind are:
ACM: Validation Status Failure, Renewal Status at Failed or Pending Validation
IAM: Service:* permissions in policy docs
ec2: Using an AMI created in the last 6 months

Happy to defer these to a seperate PFR push if we want to just get it over the line. I'll leave it up to you @jonrau1

Oh those are nice! The IAM checks especially, was thinking of using the IAA validation but it could get messy.

If you want to take that up that would be great. I am also thinking of IAM Roles/Users inactive for 45+ days as well - at least I asked that on my 3rd party DDQs lol

[bleemb]

Only remaining to-do is CloudFront (@routeronion I think you still have those, right?), FSx (plus Backup for it) and CloudHSM
Need to finish Detect-Secrets for Lambda, finish off Lambda Layers, and add some MSK checks. @bleemb anything else you can think of? I am reaching into the nethers of AWS services for anything that could've been missed lol

I can pick up the HSM checks. I'm also going to add Cluster degradation to it ,as distinct from the underlying HSMs. As far as other checks are concerned, a few that come to mind are:
ACM: Validation Status Failure, Renewal Status at Failed or Pending Validation
IAM: Service:* permissions in policy docs
ec2: Using an AMI created in the last 6 months
Happy to defer these to a seperate PFR push if we want to just get it over the line. I'll leave it up to you @jonrau1

Oh those are nice! The IAM checks especially, was thinking of using the IAA validation but it could get messy.

If you want to take that up that would be great. I am also thinking of IAM Roles/Users inactive for 45+ days as well - at least I asked that on my 3rd party DDQs lol

Agreed, IAA could be good but I can see it being difficult to implement without additional parameters for where the trust boundary should be drawn on resources. IAA policy validation could be an option? Yeah I can pick those up

[jonrau1]

@bleemb good point on trust boundaries, I dont want to be naive and think the principal caller's account is it, lots of Orgs use EE and wouldnt like it lol.

I think a "static" way like we've been doing is good. And perhaps mirroring in Sec Hub's kms:Decrypt-Resource:* check is another easy win. Will at least make the IAM Auditor have more than only user checks.

That said, are you going to try to one chunky check or 6 across? Will need an inline and attached policy check for Users, Groups and Roles.

[jonrau1]

@bleemb your approach is perfect, I am thinking like I am building a graph and not a CSPM tool, hard to to change tracks sometimes. I agree with that method 100% for Managed Policies as they can be attached to many things, there is an API to List X principals using a Policy but still separated by the User/Role/Group so likely not worth the hassle just for some metadata. If we're treating the risk, we treat it at the source (Policy)

For In-line they are tightly coupled with their upstream Principal, and I do not even think they have ARNs, so likely stuck with going per User/Role/Group. So that amounts to 4 checks for the Static analysis for service:* - but for those In-line checks that will be 3 API calls per I think - likely makes sense to create extra cache Functions for Groups, Users and Roles (Users are used quite a bit) then you'll need to list in-lines and evaluate their policies.

And another thought, not worth mirroring the KMS check specifically since we'll be checking all Policies for all Admin actions.

One thing I am up in the air about is scoping of that check. Part of me wants to focus on service:* with resource:* - while it's still bad to give yourself service-level Admin rights, I'd feel safer with it scoped down to a specific resource, since I guess even having limited admin for one Instance or one Bucket is considered "minimum necessary". Not sure your thoughts on that, but could keep the volume of findings down. I am thinking of some weird AWS services like spin up Roles on your behalf which likely can have service* but scoped to a Permission.

And in that vein, I'd think service:* permissions with resource:* where a Condition exists can be a bit sticky. I wouldn't want to arbitrarily decide what Condition was "good enough" or not, in my opinion probably best to not count anything with a Condition check either. Of course, since I am not the one writing it I won't be too strong on some minor points like Conditions, though I am sure some users of the tool wouldn't like it.

[jonrau1]

@bleemb sorry for the delay, I like that approach!

[bleemb]

@bleemb sorry for the delay, I like that approach!

No stress :) Had plenty to get on with already!

[routeronion]

@jonrau1 just an FYI that I have a few checks done in my fork for CloudFront and plan to have all wrapped up in the next day or 2 and will do some testing. After that, I can try to take on CloudHSM.

Hey @routeronion just a heads up that I've already completed the CloudHSM checks that had been listed as part of my fork :)

Sorry did not read. Nice!

[jonrau1]

@routeronion no problem at all, getting ready to merge in #61 right now - so you'll probably also have to fix merge conflicts with the permissions and README doc - no rush at all!

[jonrau1]

Complete with #64