Based on my understanding of CloudGuard we differentiate again by the "automated investigation" we do. It's not just a "you have misconfigured this thing here" but then also "because of that misconfiguration this following resource is now exposed to the internet (we checked, it is!) and it's exposing these other resources as well, look, here's a diagram that shows you this."
This is what products like CloudGuard expect you to manually do. They approach security from a compliance point of view. "You are violating control XYZ from framework ABC, so you are less secure."
Unfortunately, it's not that simple.
An AWS EC2 instance should not have a Security Group on it that allows RDP from the internet, that's true and should probably be flagged, but in itself is not a security issue. It only is if the EC2 has a public IP (or a public Load Balancer), the VPC has an internet gateway and there's no NACL blocking the traffic.
This is just one part of what ARGOS checks, what others just don't and expect you to do manually, for each of their hundreds and thousands of critical detections.
> Based on my understanding of CloudGuard we differentiate again by the "automated investigation" we do. It's not just a "you have misconfigured this thing here" but then also "because of that misconfiguration this following resource is now exposed to the internet
CloudGuard does this exact same thing. WE just had our AWS env. scanned and they did tell us that one of our S3 buckets had a wildcarded principle. It documented the exact bucket name and the policy we used.
I agree that the diagram is something I haven't seen from other vendors in the space.
But I am still struggling to understand the differentiation of the other features.
A wildcarded principle by itself doesn't mean too much. There are settings outside of the S3 bucket access policy that can mean "it doesn't matter what the bucket thinks".
This here is something other products typically don't check, and because of that create a lot of noise that a person has to check through.
https://www.youtube.com/watch?v=kMi5PSyFu8s
Other products only look at properties in isolation. As I mentioned the SG rules only become security relevant if many other things in an environment are also true, ARGOS checks for those, others typically don't. Only one example of our "context awareness".
The diagram shows the "kill chain" of how someone could laterally move through your environment, again something others typically don't do.
I said it before, we don't find more, we help you find the ones in the noise that actually matter from a security point of view.
Thanks for that detailed response.
ARGOS definitely feels more like an Enterprise / larger SMB product, unfortunately, I think this is mostly due to where people are really feeling "the need" for cloud security.
I had many conversations with smaller organisations / startups and most of them said that they could not spend money on something like cloud security (AV and Firewall was #1 spend in those conversations, very interesting) or sometimes even didn't believe that cloud security was a problem ("doesn't Microsoft/Amazon take care of this for me?").
So, as much as I'd like to help smaller organisations, it seems only at a certain size do people really recognise this as a problem.
What do you think? Also, what made the site "targeted at Enterprise" in your opinion?
Also, yes, ARGOS is, for now, only public cloud, no private cloud.
What made me think it was for enterprise was as the few other commentators have said: pricing, wordings, and …
lack of the superficial First wave demo. This is the thorny issue that nearly plagues every marketing/sales.
Assuming that my own restrictive criteria were cast aside, I would be even more intrigue by some example eyeball-catching (and perhaps semi-interactive) faux outputs. For me, this would prompt me to contact you for more details of which i expect a set of authentication info for me to visit and look around as well as take a call for some Q and As.
Again, this last step is the fishing lure that enables those who are severely time-constraint to make that “last judgement” to bite that marketers and sales ever so want to cast … and snag.
However, enterprise folks may have more time on their hand (as opposed to SMB-like folks) and may make that push to elicit for a more personal feedback … without that semi-interactive demo.
Of course, the real danger to any demo is the lack of differentiation from what they already may have could translate to lost sales opportunity.
Did you see the short video on the first page? It's a bit further down and might need to be pulled up. We have two other videos under "Resources/Videos" as well.
I am currently working on a "longer demo video" that shows ARGOS's full potential and differentiation.
Thanks for your comment.
As I mentioned to others, I followed what other companies are doing and what actual customers (not just Enterprises) asked me to do.
If I just put a "contact us for pricing" button onto the website, would that make you check the rest out and potentially sign up for a trial?
Also, ARGOS is still early and the pricing, to be completely transparent, is still very custom depending on the value a company communicates to me.
It's not meant as a trick, otherwise I wouldn't give out a free trial for 14 days to everybody without even asking for a credit card. It's genuinely a "I don't really know yet how much to charge as a baseline".
You don't understand where you are in the business lifecycle.
You're very early. Paying customers are the most important thing for you to get.
However, it doesn't matter how much the first 1% (of your target market) pay, now or in the future. (If you're successful, they're only 1%. If you're not successful....)
Let's assume that success is 100k-1M paying customers.
Anything that gets in the way of someone being one of your first 1,000 paying customers is bad. Not telling the price upfront is one such thing. Trying to charge "market/what it's worth" is another.
Now is not the time to optimize pricing. In fact, you should tell the first 1-2% of paying customers that they will always and without any effort on their part get better pricing than anyone else going forward.
Yes, you should ask them what they think other people should/would pay....
I appreciate that comment, thanks.
It does feel a bit like a catch22, that I am definitely trying to solve.
ARGOS does have early paying customers, and of course they are heavily discounted (and they know).
You mention not telling a price is an issue (and so have others, point taken), but also say I shouldn't focus on price right now. I'm trying not to.
So, what's your recommendation? Should I remove the page? Rename it to something like "Plans" and not "Pricing"? But then I'm still not telling you how much it will be.
I know how to deal with this when talking to someone, but what I'd be really interested in what you would expect on a website, knowing what you told me.
Put low prices on the pricing page together with a note along the lines of "prices/terms are negotiable". That page should probably also mention that customers now will always pay less than later customers.
Be as friction-free as possible. When you talk with someone, ask if there is anything that would have helped. (The problem being that you want to hear from the folks who didn't talk with you.)
Note - while you want an interesting number of paying customers, you don't want any bad customers, where bad means "suck up a lot of time, provide no benefit."
Be flexible up to the point where you feel that you're being take-advantage of.
For example, if you're offering 15 days free and you're asked for 30, that's probably okay (and may be useful information telling you what you should offer). However, if someone demands 6-12 months, thank them and tell them to go elsewhere, nicely.
The landing page looks nice. I feel like, based on your comments, you really are trying to build a product for customers - and not building towards some esoteric sales figure. Some comments from someone who's worked for a number of "enterprise" security vendors over the last decade...
Your product is competing in the CNAPP (Cloud Native Application Protection Platform) space. I'm sure you already knew this, but you may want to look at how companies have merged CSPM/CIEM/IaC/etc tooling to get to this "Gartnerized" name and just know who's who in the competitive landscape.
14 days isn't long enough to make a decision for most organizations unless they are really small. I'd suggest leaving that in place but also extending that to 30-45 days (1 month workflow) for prospects that will, in turn, go through additional resistance to validate they're truly viable customer candidates. Those things could be a 15 minute qualification call where you have a list of things you want to review with them to understand the fit (good feedback loop for you in features).
Standardize on your pricing - you need to understand this so you're both not losing money and so that you don't turn customers away because of the unknown. You can always have a custom pricing tier or an "Ask Us" option. If you don't know what your baseline cost for a customer is - then figure it out quickly.
Demos can go a long way - since you're a small shop you need something that won't soak your time, so I'd suggest taking your customer's top couple pain points and recording a nice looking demo that won't cost them more than 10 minutes to watch. People in this space want to see the product. There are so many security tools that a lot of buyers already have too many - so they want to see what it is and many customers are also looking for ways that new tooling can be integrated into existing workflows. There is no "single pane of glass" anymore for customers and instead it's morphed into, as I like to refer to it: "single pain of glass", because every vendor claims you only need them. Right.
If you have any questions I'd be happy to chat - [my_hn_name] at counterbrea dot ch. Best of luck!
I am indeed. I've seen those issues one too many times as a consultant, and I never got to really(!) fix them as I was only ever brought in as a band aid really, not strategically.
Yeah, CNAPP is the new acronym for where we probably best fit right now. I will continue checking out some of the other players.
I initially had a 14 day trial, then people (not potential customers) told me that would not be long enough, so I increased it to 30. That did not make a difference at all. Smaller companies still signed up and converted, larger companies "ignored" any time limits and just assume that those don't apply to them.
Based on all the comments now I wonder if I should have a "base" plan that has the cost on the website and an Enterprise / Custom plan with a "Contact us" button. I pretty much know what a customer costs "on average", so that's not difficult.
Curious, did you see the short demo video on the website? There is a short one on the main site "below the fold" and there are two more in the "Resources/Videos" section. I am working on a longer version that I can send out to potential customers instead of a demo initially.
Yeah, I've seen and felt the "single pain of glass" many times :D
I'd love to take you up on that offer, thanks, a lot!
It's a fair comment, and I used to have prices on the website and then actual customers, while they were on their way to becoming customers, told us to take the prices offline.
Their procurement teams really didn't like prices on the website.
Doomed if you do, doomed if you don't.
The trial is completely free, we don't ask for a credit card, only when you decide to want to become a customer, you can actually see the self service prices in your ARGOS dashboard.
Those prices are also available via the Azure/AWS marketplaces.
If your entire target market is enterprise then I suppose this route works well but if you want to hit smaller organisations it deviates a lot from what we're used to. GitHub, Slack, GSuite, they all provide prices and are successfully sold to small organisations and enterprises.
As a non-enterprise, there's no point in me signing up for a trial of a tool that may be orders of magnitude outside of my budget. A lot of my decision is based on the value proposition and I can't understand the value I might get if I don't know the price. If it's $10 a month and does what it says then I probably won't think about it, if it's $1,000 a month then that's quite a different decision process. I don't want to bother with a free tiral if I can't even see the price. Am I just booking to test drive a car I'll never be able to afford?
Again, fair comment.
Frankly, I'm still figuring out what this would be worth to smaller organisations.
ARGOS really scales by AWS Account / Azure Subscription / GCP Project right now and I'm currently charging "for each...".
I know what Enterprises are paying for ARGOS and some larger SMB, but not clear on what value smaller orgs or even startups assign to this problem.
keep in mind, AWS best practices (and IAM limitations, for those without resources/time to finely craft the boundaries) encourage account sprawl...
Not all customers spread out like we do... but I manage over 50 AWS accounts, and our DevOps team is 7 FTE... Our application/situation is admittedly unusual, but I could easily see a small business using 10 accounts to manage their org and a single "product"
I used to be a consultant building exactly those designs, limit the blast radius, have separate accounts etc.
"In the earlier days" of ARGOS that's exactly why I didn't charge per Account, but different ways (tried # of resources, then % of spend) and people were always confused.
Similar to the "take the price off the website" that customers told me, me charging per Account is also what customers asked me to do.
What do you think would a good unit be for a product like this?
I'm happy to try anything really, as long as it helps companies be more secure.
Great question.
First, I feel most of the integrations (aside from Slack) are really asked for by Enterprises. Smaller orgs don't really ask for those.
Roadmap is absolutely around context, even more context.
We want to get to the point where we're almost a cloud security lake (can't come up with a better word) where we know about everything that happens in the environment and allow you to make decisions almost on the spot based on what we show you. (Lateral movement possibilities by an attacker, what is actually running on those workloads and in what versions, who/what has access to them, etc)
We're also looking to make our remediation engine more intelligent (not AI), but potentially allow you to give us a script we should execute to remediate, or trigger some other SOAR engine even. Right now remediation is whatever we think is a good remediation (and rollback) for an issue, but that's not always what you might want.
Does that give you a view into my mind for a roadmap?
I'm British, so I'm aware of the retailer. Thanks for the warning, we've been assured by many legal professionals that this should not be an issue.
We tell everybody that we are not associated with them and that we are actually named after Argos Panoptes (https://en.wikipedia.org/wiki/Argus_Panoptes), the all-seeing giant.
I guess I'd caution that there might not be an issue now in a strictly legal sense, but come trademark registration time Argos-the-retailer might decide to put up a fight.
My more cynical side wishes to express that this would make the lawyers very happy.
Trademarks are registered within a specific category of business. That's why Apple, the music label, could exist next to Apple, the computer company, all those years back. It's also why Apple got into a trademark dispute all those years down the line when they got started in the music business.
The http://argos.com/ people don't have trouble with the ARGOS trademark (there was a lawsuit about this!). OP's product might not be so lucky, though.
If OP can get a trademark registration for the right category through, they should be fine using the name Argos from what I can tell. Either Argos or ARGOS might object to that trademark and make that very difficult, though.
That’s not quite how it works. Companies argue that there’s no brand confusion in order to coexist with similar trading names and use market sector as evidence but there isn’t any specific law that says this has to be the case.
To use your Beetles vs Apple Computers case study, Apple Computers actually settled with the record label and part of the agreement of that settlement was that Apple wouldn’t enter the music industry. It wasn’t a case that the record label lost, it was a settlement. Hence the follow up case between the two after Apple released iTunes (or whatever it was that triggered their “arrival” in the music industry).
Thanks for that feedback.
We have MSSPs as partners already and the pricing there is pretty much "custom". I haven't thought about "individual security consultants" yet. I assume they would rather prefer a "point in time" scan to what we currently do (continuous scan).
I did actually think about reaching out to Rumble at some point. They seem to have figured out the whole "unauthenticated workload info" that I'd love to see within ARGOS.
Based on my understanding of CloudGuard we differentiate again by the "automated investigation" we do. It's not just a "you have misconfigured this thing here" but then also "because of that misconfiguration this following resource is now exposed to the internet (we checked, it is!) and it's exposing these other resources as well, look, here's a diagram that shows you this."
This is what products like CloudGuard expect you to manually do. They approach security from a compliance point of view. "You are violating control XYZ from framework ABC, so you are less secure." Unfortunately, it's not that simple.
An AWS EC2 instance should not have a Security Group on it that allows RDP from the internet, that's true and should probably be flagged, but in itself is not a security issue. It only is if the EC2 has a public IP (or a public Load Balancer), the VPC has an internet gateway and there's no NACL blocking the traffic. This is just one part of what ARGOS checks, what others just don't and expect you to do manually, for each of their hundreds and thousands of critical detections.