amzn

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
amzn [2020/02/12 12:55] – [Programmatic UI manipulation] mmuzeamzn [2020/02/13 13:01] (current) – [Programmatic UI manipulation] mmuze
Line 1: Line 1:
 ======Amzn====== ======Amzn======
-This page provides some additional details for the things I talked about.+This page provides some additional details for the things I talked about. This includes notes, diagrams, source code and videos.
  
-======sorcery====== +- Michael Gupton
-  * The //sorcery// solution is a CLI tool that provides supplemental functionality that is not built into a product to provide ways of automating what would otherwise be onerous manual tasks carried out by an administrator. +
-  * [[https://github.com/mgupton/sorcery]]+
  
-======Ingress controller/friendly fire issue====== +======sorcery, product configuration automation solution====== 
-  * This diagram illustrates a problematic scenario that resulted in many false positive security incidents being generated by the very product that is producing the incidents by its own vulnerability scans.+  * The //sorcery// solution is a CLI tool that provides supplemental functionality that is not built into a product to provide ways of automating what would otherwise be onerous manual and error prone tasks carried out by an administrator. 
 +  * automates assigning agents to sensors 
 +  * automates tagging agents to help with identifying and managing them 
 +  * automates purging defunct agent configuration from the backend when VMs or hosts are terminated 
 +  * **source code:** [[https://github.com/mgupton/sorcery]] 
 + 
 +======Ingress controller/friendly fire issue with vulnerability scans====== 
 +  * The diagram below illustrates a problematic scenario that resulted in many false positive security incidents being generated by the IDS/vuln. scanning solution itself. That is, the IDS was producing and detecting its own threat activity.
   * Because there was a ingress controller on the node with the application pod the vuln. scanner was scanning the application pod twice, once directly and once through the ingress controller.   * Because there was a ingress controller on the node with the application pod the vuln. scanner was scanning the application pod twice, once directly and once through the ingress controller.
-  * And the source IP of the scans going through the ingress controller were obscure, so when the IDS saw the traffic it did not recognized it as its own traffic. Therefore the IDS generated many false positive incidents from its own scans. +  * And the source IP of the scans going through the ingress controller was obscured, so when the IDS saw the traffic it did not recognize it as its own traffic. Therefore the IDS generated many false positive incidents from its own scans. 
-  * Normally the x-forwarded-for (XFF) would prevent this issue, but for some reason the XFF was not always added to request going through the ingress controller and the IDS solution has limitations that results in it not correctly handling the XFF. +  * Normally the x-forwarded-for (XFF) header in HTTP traffic would prevent this issue, but for some reason the XFF was not always added to requests going through the ingress controller and the IDS solution has limitations that results in it not correctly handling the XFF. 
-  * The solution I implemented is to use and undocumented API to whitelist the ingress controllers from vuln. scans. **source code:** {{ :temp:al-exclude.py |}}+  * The solution I implemented is to use an undocumented API to whitelist the ingress controllers from vuln. scans. **source code:** {{ :temp:al-exclude.py |}}
       * Since this is in a k8s environment that tends to be dynamic the script can be ran periodically to continually update the whitelist with the IPs of the ingress controllers that are found in the environment.       * Since this is in a k8s environment that tends to be dynamic the script can be ran periodically to continually update the whitelist with the IPs of the ingress controllers that are found in the environment.
       * The core functionality of the IDS/scan solution records metadata about the k8s environment, so I was able leverage this metadata to detect the ingress controllers and get their IP addresses.       * The core functionality of the IDS/scan solution records metadata about the k8s environment, so I was able leverage this metadata to detect the ingress controllers and get their IP addresses.
Line 20: Line 25:
   * This solution provides a way to programmatically manipulate a web UI to supplement the lack of an API for acquiring vulnerability data.   * This solution provides a way to programmatically manipulate a web UI to supplement the lack of an API for acquiring vulnerability data.
   * This solution was used to ingest vulnerability findings into an ITSM (e.g. ServiceNow) that was used for a partners workflow with their end customers.   * This solution was used to ingest vulnerability findings into an ITSM (e.g. ServiceNow) that was used for a partners workflow with their end customers.
-  * {{ :temp:aims-ui-access.py |}}+  * The solution would authenticate with the UI and then fetch the latest scan results from a specified scan job and save the data as a CSV file that could be readily ingested into an ITSM. 
 +  * **source code:** {{ :temp:aims-ui-access.py |}}
   * {{ :temp:customer-readme.pdf |}}   * {{ :temp:customer-readme.pdf |}}
-  * [[https://www.youtube.com/watch?v=bCZ7yprk3Ig|Video demo of POC]]+  * [[https://www.youtube.com/watch?v=bCZ7yprk3Ig|Video demo of proof-of-concept]]
  
  • amzn.1581512136.txt.gz
  • Last modified: 2020/02/12 12:55
  • by mmuze