What is our primary use case?
We work on a dark site. It's the next generation ground station for the Air Force's GPS system. Our use cases are based mostly on an insider-threat perspective.
We utilize a lot of AI Engine rules within the LogRhythm SIEM to detect different types of privileged-user actions, whether it be escalation of privileges, creation of user accounts, or modification of user accounts. We also use it for IDS rules and firewall rules that are met, in terms of the IDS finding signature attacks.
How has it helped my organization?
It has helped our organization because we utilize the SIEM for a lot of analysis, not necessarily for malicious threats at this point, because we're in development. It's helping as far as figuring out how something got changed on the system, because it is in development and things are changing constantly. We are then using that forensic analysis to figure out what was changed, so we can turn it back because, a lot of times, in development, we don't know what caused something to happen.
What is most valuable?
The most valuable feature that we use is the AI Engine itself.
What needs improvement?
They're addressing a lot of the things that I've thought of over the past four years, in the various releases they're coming out with.
A lot of times they'll say something is coming out in a certain release and then we get to that release and they say, "No, we're pushing it back to a coming release." More engineering thought will go into when they are going to release something. Often, we'll give feedback to our management saying, "Hey it's going to come out in this release." That release comes out and it's not there and we have to go back to management and say, "Hey, they're not going to do it right now." Then management gets frustrated because they don't understand the intricacies of what goes into different components and into different releases.
What do I think about the stability of the solution?
The stability is very good, now. Initially, when I started working on this four years ago, the actual solution that was brought into our company wasn't very scalable, it wasn't architected properly for our type of environment. I've since re-engineered and architected a different solution with LogRhythm to actually meet our needs.
What do I think about the scalability of the solution?
It's very scalable. It's a matter knowing what you need regarding the quantity of logs you're putting out on a routine basis. If you size it and scale it correctly, you can keep scaling it as far as you need to scale it. We've added data processors, data indexes - we have multiple for each for each environment. And we have close to 20 environments that we have LogRhythm SIEMs in.
How is customer service and technical support?
I do more the architecting, engineering, and implementation, versus analysis. The only thing I would say in evaluating tech support is that a lot of times, I start out with the tier-1 and it's just not what I need. I need to get to tier-2, tier-3, and usually tier-3, before I get what I need.
If LogRhythm could do something on that side - for people who actually deploy and integrate the SIEM itself, instead of it just being an analyst - by having a different phone number for them, that would be a recommendation I could see going forward.
How was the initial setup?
Was the setup complex? Yes and no. I did a lot of research prior, on my own, regarding using the recommended specifications that LogRhythm puts out. I designed it around that. I didn't utilize customer support a lot, only for a few questions. It was pretty straightforward after the research I put into it.
What other advice do I have?
I would definitely recommend LogRhythm, based on my experience with it. LogRhythm is always trying to change and improve its product which is always a good thing. Other SIEMS are in development to upgrade and better their SIEMs but LogRhythm, across the board, has a great team. They look an inch deep but a mile wide, whereas other companies will look a mile deep and an inch wide. I think it's a lot better to do "across the horizon," instead of a small, six-foot-deep hole.
We are not using the full-spectrum analytics capabilities at this time. We are thinking about it, but there's a process for getting those changes into our baseline, being a development program. We have no playbooks at this time.
We have about 5,000 to 7,000 log sources per environment and there are 20 environments. In terms of logs per second, it all depends. We're in development. Some of our environments are not ramped up and they're all at different stages of development. Where we only get 100,000 to 150,0000 logs a day in some environments, in others we'll get close to 1 billion logs a day.
When it comes to what's important in selecting a vendor, price, names, and support are all great and dandy. Obviously, the big names of the world have a track record. LogRhythm hasn't been huge for a lot of time but they're starting to grow. They were one of the ones recommended by industry reviews in the SIEM world, but they were a relatively small company at the time. When you have industry reviewers recommending a small company, it says a lot for that small company. I know that they are growing now, but back when LogRhythm was first talked about by the industry they weren't very big, compared to the Arclights and IBMs of the world.
I rate it an eight out of ten because I don't have a lot of experience across the board with different SIEMs. I've worked with ArcSight but ArcSight is very expensive. And I've worked a little bit with QRadar. I actually like QRadar as much as LogRhythm.