eramba was made so people could access a to very very very cheap GRC solution provided that:
they understood linux to install and maintain
they could follow up with documentation and play with the tool until they master it (groups, access lists, notifications, filters, reports, imports, etc)
they understood enough GRC so mappings, controls, etc concepts would not be too strange
For a somewhat experienced (IT AND GRC) person, the above should not take more than 40 hours.
We have always assumed our public will meet the conditions above, and when not, they would engage with our implementation services or partners because in 6hs or so of workshops we get a lot done just because we know this things upside down.
Only %5 of the customers purchase implementation services…and i would say a good %20-30 of them just waste time trying to achieve the points above -without much results- at a far higher cost than the 600 eur an implementation workshop costs.
Should we make eramba include by default those 6 hours of consulting and spare that %20-30 from certain misery? We welcome your opinion.
I would agree that many people struggle with the implementation, but I’m also not sure what the best approach would be to solve this - couple of observations:
If you were to draw a Venn diagram of IT GRC minded folks, technical security folks and Linux wizards, you would find that there is very little overlap between those two groups. It is the exception, rather than the rule, to be an IT GRC minded person that can also utilize the Linux command prompt to install something, even if it is laid out in a step by step manner.
In many smaller organizations that we work with, they simply do not have the three characters that I described above. We’ll have a primary point of contact that looks more like a hat rack due to all of the hats that they are wearing within the organization. The hat rack type person typically does not “get” GRC and takes a while to get up to speed with the core concepts (thus, we usually end up taking care of that).
I’m of the opinion when rolling out a new GRC/security/controls/whatever program, the GRC implementation of it should be the easy part. The wrangling corporate politics, changing behavior within an organization, and so on needs to be in place before Eramba can actually become useful. That would mean that the consulting hours may not get used until 6 months after they buy it, because “intentions” were to implement quickly before they got distracted with that last shiny object.
Not sure where the thoughts end up… that just comes to mind…
yes, totally agree with this … we are hoping the cloud service will address this issue for every. we get 4-5 tickets per day in support, %80 of them are linux stuff we do for customers!!
i see the same and not just in SME kind of companies…
and you are right again, when we sell workshops customers take many months from the moment they purchased the software to begin. i think these people have many many things on their plate already.
its been a long time i wanted to fly over just to meet you!!
Debating whether this is a separate feature request or observation. I put off the 3.0 upgrade for the longest time (and even moving over to the CLI crons), but I’m finally bashing (heh) my way through it.
One of the biggest issues I’ve had has been differing PHP installations between the web server side and the CLI side. Yes, the install manual makes reference to the need to make sure both sides have the same version and modules installed, but the error messages aren’t super clear about the issue when those do not match.
The system health screen is ONLY checking the web side - as a result, I discovered I was still running PHP 5 on the CLI side. Then I found I was missing a few packages and I was off to the races on v3 updating - until it stopped working with an unhelpful message. Digging into it, it was yet another module that was missing.
Therefore - it would make sense to me that the System Health Checker looks at both sides of PHP installation. I think it would solve a lot of grief for those that can’t drop to the command prompt and figure out the real error message and then diagnose that.