Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"


0 (0 Likes / 0 Dislikes)
Hello, RSA colleagues and partners, Matthew Gardiner here from the ASOC Product Marketing Team and I'm here to talk with you about the pricing and packaging of Security Analytics.

Basically, there are two models currently available for Security Analytics. One is a relatively new model referred to as the throughput or the throughput per day model for licensing. And the other is the traditional appliance base model. The throughput model was basically introduced towards the later half of 2015. And so this is the new model that we are gonna spend some time on. This model measures the ingest of data and so basically the customer licenses, the right to ingest either logs, packets or both into Security Analytics and we change accordingly for that license. The packets are measured in terabytes per day and the logs are measured in gigabytes per day but the basic principle still applies. The total number of packets collected in a given day and or the total number of logs collected in a given day are measured and the license needs to cover the amount that they ingest. malware analysis is really an add on to the network monitoring. So some of them would have network monitoring and then decide they want to add the malware analysis piece to the solution. They essentially add that to the solution but it's measured on the same terabytes per day. It's measured in the amount of packets, except now the packets are being used specifically for malware analysis. There is a built in volume curve, so the more data that's ingested into the system the less per unit the customer will need to pay. So the price goes down as the volume goes up and I will show you that volume curve in a minute.

So let's talk little bit more about throughput. The throughput model supports either a software only deployment. So if customers want to deploy Security Analytics virtually or based on software directly installed on certain servers, they can do that, or they can buy, like, traditionally, they can buy appliances with the software loaded on it. However, the way that you come up with that price is somewhat different than the pure appliance model. So the throughput per day, I talked about it, it's based on the amount of terabytes and gigabytes of packets and logs ingested into the entire system whereas in the throughput model the hardware is sold separately in essence. They can still get everything deployed on those hardware components but the hardware is sold at market prices. So there's still Dell servers and there are EMC base storage and the pricing that RSA offers for those is basically the market price for the given Dell server and the given storage from its ultimate RSA sources from EMC. So in effect with this throughput per day model does is it separates software from hardware. Customer can clearly see the software license based on the ingest, the daily ingest of data and they can clearly see the hardware value which is the servers and storage that we can distribute with the system. However, they can acquire software only. They do not have to acquire hardware through us. The licensing for throughput is either subscription or perpetual model. They can do either, it really is, RSA is neutral. It should be what's best for the customer.

So on a subscription basis, the customer sets a term 24 months, 36 months, you know, 20 months, something like that, that they want to license the solution for. And the maintenance and support are built into that subscription license. Whereas, they can also purchase these license on a perpetual basis where they own the licenses and presumably acquire maintenance to cover support and updates over time. The basic, you know, decision criteria is whether they want to think about acquiring licenses on an OPEX or CAPEX basis. So an OPEX is basically an annual charge. You know, that fits more towards the subscription model generally and if they want to... If they have capital budget, they want to spend on Security Analytics, they can do it CAPEX and acquire the technology on a perpetual basis. Really up to them.

So now to the appliance based model. So we can think of this as the legacy model of Security Analytics. If you've been selling Security Analytics for anything more than a few months, you're probably quite familiar with this model. It also was the model used even in the NetWitness days before Security Analytics even came out. It's the traditional appliance purchasing approach where you size and engineer a Security Analytics deployment to fit the retention and data collection needs of the customer. And with that bill of materials or BOM you might, see that term used, you will find a number of decoders or concentrators, hybrids, brokers, ESA, the basic components of Security Analytics and you acquire any number of those that you need to fulfill the bill of materials. Similarly, the retention side has the number of and size of direct-attached capacity or SANs that you need to connect to your decoders, concentrators, archivers, etcetera. So those are all sold in the appliance model, everything included, basically the software and the hardware in one package. So consequently, the appliance model really only supports the perpetual model. You can only buy appliances, you don't subscribe to an appliance. So if you want to go... If they want to do subscription model, they need to do throughput.

So actually that brings up the sort of when to use which model. And so I do have some guidance there. None of this is hard and fast. You know, use your judgment to what will make the customer more satisfied and, you know, more interested in continuing to do business with us. But there are some guidelines that I would like to go through that you should consider. So first when to use throughput? Basically, it should be your starting point for new customers and unless there's some reason not to use throughput, you know, you should probably start presenting the throughput model to them. That's for a number of reasons. One reason is, you know, if you come across a customer that wants to start small and grow very, very incrementally, the throughput model really fits better because, you know, you can acquire five terabytes and then... Per day and then move up to six terabytes per day and seven terabytes per day, much more incremental than acquiring another decoder and concentrator stack, for example. Another thing, if they don't want use RSA delivered hardware. If they want to do go down a software based deployment then the throughput model really is the only model you can use. If they want to use subscription pricing like I mentioned earlier. Subscription pricing is only supported through the throughput model so that would tend to lean them towards throughput.

A technical reason why you might want to use throughput is if the ingest rate is very small, by very small, I mean things like, if the enterprise ingest rate for packets is in the 100 megabytes per second or for logs is in the 500 EPS, you're probably gonna want to start or will go down the path of throughput because the appliance model is sort of heavy for a customer that's quite small. And of course, if they want to start small and move up incrementally, the throughput model fits even better. Another reason to use throughput is flexibility. You know, with the throughput model, we don't care how many decoders and concentrators and virtual log collectors and archiving units the customer uses, it's completely up to them. It doesn't impact their licensing unless they are acquiring hardware from us, of course. From a software point of view, they have maximum flexibility. They can change their mind. The architecture can change. All we care about is the total throughput per day in terabytes or gigabytes. So it gives them more flexibility.

Another reason to use throughput is if you are selling with or through an MSSP. MSSP is generally like the flexibility of term-based subscriptions as well as the throughput model more generally because it allows them to match their licensing to the end customer. You know, say the customer acquires the service from the MSSP for two years, it make sense that the license for the security monitoring system, Security Analytics, also be for two years so that both licenses, essentially, the service and the underlying technology co-term. So MSSP is like the throughput per day generally.

So now onto the appliance side, there are reasons to use appliance. It's still available and still so quite popular. One reason to use it is with an existing customer that initially acquired Security Analytics in the appliance mode. If they're just incrementally adding to their solution like, for example, adding more DACs or maybe adding a hybrid for logs or packets. You know, does it make sense to completely introduce a new pricing system to them to do that? Maybe not. You know, they just want to go ahead and buy a little bit more infrastructure using the appliance model. Some customers don't like the throughput model. Generally most do, but we've seen customers that think it's not reasonable, not fair. Now also organizations with very high throughput rates on very minimal infrastructure. So an example would be 50 gigabytes per second sustained on a decoder, concentrator stack. That's a lot of data jammed into a very minimal infrastructure. Systematically, it's no problem, it can support it, but you'll end up ingesting a tremendous amount of data in a 24 hour period. And thus the appliance model actually can be more financially attractive in that case than throughput. So in the case where the throughput rates are quite high but the infrastructure needed to support that is relatively low, you might want to lean towards appliance.

Another, kind of, area to consider is those organizations that don't really have a good handle on their data rates. So, you know what I mean probably if organizations have no idea what their EPS for logs is or what their actual network traffic is that they're gonna try to ingest, you know, it can be a little hard to size on a throughput basis because you need to know the amount of data ingested on a daily basis to really do that accurately. Whereas if you're doing appliances, it's a little bit more forgiving as long as you are within the scope, technical scope of the appliances, they can do it. So in those cases, more accuracy is always better. But if for whatever reason, you are not gonna get more accuracy, you know, sufficient enough to be comfortable on the throughput model, then you can use the appliance model.

So here I'm gonna show you the basic tiers and these are tiers for the throughput based of course. We have two basic tiering buckets, network monitoring and SIEM/Log Collection. So network monitoring has five tiers starting at 1 terabyte per day going up to 250 terabytes per day and above. So it's quite simple. What you here is, for example, someone needed 15 terabytes per day to do network monitoring they would in tier 2. tier 2, has a SKU and that SKU, you multiply by 15 and you get the price for 15 terabytes per day whether that's subscription or perpetual, works exactly the same way, just the same tiering. For on the SIEM side, very similarly, except the only difference is it's in 50 gigabyte per day steps. So if someone is licensing 300 gigabytes per day, they're also in tier 2, in this case, for logs and they would multiply... You know, the 2 would multiply 6 by tier 2, 6 being 6 times 50 equals 300. So that's basically how it goes. Now this gives you the licenses for the software, for the throughput per day model, servers and storage are sold separately and basically at the market rates. So they can be added to number of decoders or concentrators or DACs and SANs that they need to actually support the deployment. But from a licensing point of view of our software, basically, these tiers are what make it up.

So where you can learn more, there is some content attached this module and also, you can search in SalesIQ.

Video Details

Duration: 13 minutes and 24 seconds
Language: English
License: All rights reserved
Genre: None
Views: 13
Posted by: quinnb on Mar 28, 2016


Caption and Translate

    Sign In/Register for Dotsub to translate this video.