Utility to violate intentions and ACLs for pen testing
- Dominant language
- Go
- Stars
- 30.1k
- Forks
- 4.6k
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 39
Description
### Background
Most enterprises today have a SOC (Security Operations Center) to constantly monitor for anomalous events such as intrusion attempts. Activity that hackers may attempt and errors that can occur due to malicious activity should trigger a security alert to the SOC so they can handle the new incident.
### Feature request
For Consul, a utility to create requests deliberately violating Intentions and ACLs defined (doing the opposite of intended requests) to ensure such malicious activities actually trigger alerts to the SOC. For example, a program that reads an intentions.yaml file and create an API that performs the opposite (make a connection to what is denied). Or, because tokens are so dynamic, a request in the core program to issue the offending requests as if the program was compromised.
This would be invoked by customers or their 3rd-party pen testers during pre-production penetration testing on customer's systems. But this feature is likely implemented not within Consul core code but in a utility library created by customer/partner services. So where should this issue reside? In some Jira project?
NOTE: This was discussed with Jared Kirschner on Nov 9, 2022.
Contributor guide
Research direction
No source file, test, or entry point is named. Start by determining whether this belongs in Consul core or an external utility, then review the Intentions and ACL request surfaces mentioned in the proposal. Done requires an agreed scope and a defined way to generate denied requests and verify SOC alerts.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- authorization, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100