In this article we introduce the classes available in the base MineMeld distribution and how to use them to create a managed services offering for your customer base. Either to differentiate yourself from these pure resellers that do not add any value or to build a new income source.
If this is your first time with MineMeld then you better read the Getting Started article and deploy your first MineMeld instance following the article from the following list that better suits your needs.
In this case example we will start with a basic offering consisting on a high-risk IPv4 feed that any customer should block at the Internet Gateway. That feed will consist on the aggregation of the following three standard miners:
In other words, we will create the following graph.
To reach to this configuration point you just have to import the following configuration snippet in the configuration section of the WebUI.
nodes:
dshield_blocklist:
output: true
prototype: dshield.block
myBaseOffering:
inputs:
- spamhaus_EDROP
- spamhaus_DROP
- dshield_blocklist
output: true
prototype: stdlib.aggregatorIPv4Generic
spamhaus_DROP:
output: true
prototype: spamhaus.DROP
spamhaus_EDROP:
output: true
prototype: spamhaus.EDROP
freeBaseOffering:
inputs:
- myBaseOffering
output: false
prototype: stdlib.feedHCGreen
All MineMeld feeds are exposed using a basic authentication mechanism. By default only the MineMeld admistrator user and password can be used to grab the feeds contents. Note, please, that if you check the feed URLs from a WebBrowser that is already connected to the MineMeld WebUI then you won't experience the authentication request because your browser has already been authenticated and do have a session cookie.
To implementa a granular control of feed content by customer or customer type you must create a "feed user" and give it a password in the Admin section of the WebUI.
Once the feed user has been created you must assign it an authentication tag and attach that tag to the output node.
Now it is time to commit the configuration changes.
To check that everything is fine so far just validate the feed is working by attempting to access its data with the corresponding user and password (basic authentication).
user$ curl https://yourBrand:xxxx@minemeld/feeds/freeBaseOffering
185.35.62.0-185.35.62.255
80.82.77.0-80.82.77.255
1.10.16.0-1.10.31.255
1.32.128.0-1.32.191.255
101.192.0.0-101.195.255.255
101.202.0.0-101.202.255.255
101.203.128.0-101.203.159.255
101.248.0.0-101.249.255.255
101.252.0.0-101.253.255.255
102.176.0.0-102.177.255.255
102.181.0.0-102.181.255.255
103.16.76.0-103.16.76.255
...
Now it is time to configure the Internet Gateway to block any packet coming from or going to any IP address belonging to these ranges. In the following example I will configure an IP External Dynamic List object linked to the feed we have just created and a couple of Policy Based Forwarding rules to discard traffic when these IP's are involved.
If your customer wants to be able to monitor the activity of traffic matching the EDL then you can use Security Policies with drop action instead of Policy Based Forwarding rules.
What about suggesting a specific SMB customer to subscribe to a premium service where other intelligence data is combined into his reputation fee?
We will continue with our example adding a new miner (the TOR exit nodes) to our instance and modifying the graph in such a way that only a given specific premium customer is allowed to consume this extended feed.
Try to clone nodes from the standard library to create the graph or, if you want to go straight to the point, just import the following configuration snippet into you configuration (use the “Append” button)
nodes:
torExitNodes:
inputs: []
output: true
prototype: blutmagie.tor_exit_nodes
premiumOffering:
inputs:
- myBaseOffering
- torExitNodes
output: true
prototype: stdlib.aggregatorIPv4Generic
premiumCustomerA:
inputs:
- premiumOffering
output: false
prototype: stdlib.feedHCGreen
And remember to create a new feed user for this premium customer and attach its corresponding authentication tag to the output feed.
The next step in your offering could be to provide a managed service to customize the reputation feed with any arbitrary source data. To do that we’ll add a “local list” (prototype: stdlib.listIPv4Generic) miner for one specific premium customer so the field engineers have a bucket in which any indicator requested by the customer could be placed.
Just append the following configuration snippet to append the two remaining nodes to complete the graph.
nodes:
bucketCustomerA:
inputs: []
output: true
prototype: stdlib.listIPv4Generic
customerA:
inputs:
- premiumOffering
- bucketCustomerA
output: true
prototype: stdlib.aggregatorIPv4Inbound
Note that, at this moment, the premiumCustomerA input will still be attached to the premiumOffering aggregator node. So we must change it to the recently created aggregator node called customerA.
This new bucketCustomerA node provides a way to add new indicators to the managed customer feed. The easiest way is to use the node’s WebUI feature.
MineMeld's API provides you with a way to upload indicators into a list to deal with bulk operation. A nice implementation is available in minemeld-sync tool available in GitHub.
I hope this article gave you interest in exploring ways to leverage MineMeld to add value to your NGFW deals and, eventualy, use it as a revenue stream.
The following is a list of ideas you could evaluate to extend your value proposition:
