NetWitness Platform Reviews

Generally, we use the solution for network forensics. It allows us to do visual data detection and prevention. 

The solution should have more integration capabilities with different platforms. The API is nearly open and scalable, so the solution can integrate with many platforms. The solution has more than 200 log sources in the scalability to support, but this is its limit. 

Installation is pretty easy. However, there are a couple of modules involved, so it is not as easy as it could be. We are talking about a distributed module, not a single-module type. This is what makes things a bit complex, instead of easier. I rate it as a seven out of ten on its installation and configuration capabilities.

We use the on-premise deployment model of this solution. Our primary use case of this solution is for malware detection and for reconstruction during the incident and forensic analysis.

The web interface needs improvement because right now they have problems combining an older interface with a newer interface. They're in the middle of the process of combining the old and the new one. It sometimes confuses the user and sometimes you are not able to find the necessary information. You need to click the information and that is something that should be improved.

The data isn't a problem but you need to get used to it. You need to know where to click in order to get the results. Otherwise, you can encounter some problems.

I would be very happy if they would fix all the issues from 11.3 to the 11.4 version to have more advantages from the UEBA because the UEBA we have implemented will be the longest. If they will fully integrate the UEBA with the network data, this could be a very huge advantage and impact on the market. Right now, you have a solution like Darktrace which has the same capabilities as RSA NetWitness so NetWitness should implement the same things. They have UEBA, they have data. They should implement algorithms to digest that data and produce additional, more advanced reporting, alerting and support of internal security teams.

It's a log management solution where we have logs from different sources, like network devices, firewalls, load balancers, IT, application servers, and database servers. We also use it for compliance and governance. Our cyber security team uses it to monitor malicious activity across our IT infrastructure.

The development of use cases on the SSA console is quite user friendly. This means that the security analyst or the researcher does not have to learn another language.

Overall, it is easy to implement.

I can have enterprise security, email security, next generation firewall security logs, HIDS and NIDS logs, etc. all on the same dashboard. It makes it easy to pinpoint or correlate our server to this. I can find out if there is lateral movement. This is the biggest advantage of this solution.

Sometimes, it gives me static when integrating Windows-based systems. It should produce a precise log of sorts as to where the problem is. For example, a few days ago because of the McAfee application firewall, I couldn't get access to the particular Windows machine.
So, my team and I had to figure out by ourselves that there was a virus responsible for the obstacle. This solution should trigger a meaningful log or message indicating the reason the user or implementer can't get into the machine.
The workflow is not smart enough. For example, if I'm monitoring or analyzing log events and alerts from the SIEM system, it has to be reviewed by the person responsible for this in the organization. So, the review should be automated and should be signed off per the FR-ISO 27001 control requirement. This is lacking in RSA NetWitness Logs and Packets (RSA SIEM). This is also the case with PCI-DSS compliance because we are in the banking industry.

The most iconic disadvantage of the solution is that I cannot tag my asset by my name. There should be a portal or a photo where I could check the applicant name. Whatever asset it discovers, it takes only the IP address. If it gets it from Active Directory, then it gets only the host name, which is not actually meaningful to an analyst. There should be a way to tag a name manually so that it can be mapped later to the actual machine, besides the machine I'm investigating on.

RSA NetWitness Logs and Packets (RSA SIEM) does not have SOAR, and we have to do it manually. SOAR is a new concept that is still in development.

The product has a user-friendly interface and a valuable feature for threat intelligence integration.

It is quite tedious to make changes in the playbooks. There could be an option to integrate or adapt AI and machine learning for our threat-hunting solution. It should have a monitoring feature. It would help us analyze the current state of attacks faster from a single platform.

We provide NetWitness along with Archer, and multiple sites. We are managing their security operations using this other station and Archer. A collector can work in two different ways. It can collect the logs, and it can aggregate the traffic tools from different net flow logs. When I saying "logs," I mean a log collector and when I say "packet," that means the packet or log connector. 

The stability all depends upon how well the site is set up. All these solutions are good, but the CPU and OS are the major portion of undoing the correlations. If you have a poor correlation, then you need to have less than 70 percent utilization. Then that may not be good performance. 

It is an SIEM solution used regularly as a part of the SOC to collect data from all the security environments in my company.

NetWitness Platform is valuable for creating rules that the solution must detect.

RSA NetWitness Logs and Packets are used exclusively for monitoring scenarios, insider threat analysis, and log retention.

The most valuable feature of RSA NetWitness Logs and Packets are the alerts and correlations tools.