According to an earlier article [0] about this, there's enough storage to keep 30 days of network traffic. That's not nothing. It's also something that apparently the regular UC IT folks have no control over whatsoever.
That's strange. My company uses the same Fidelis XPS appliances Berkeley is using, and they're entirely installed, administered, managed, configured, and monitored by our internal IT security staff. Only our staff has access to alerts it fires and the snippets of traffic it captures (for example, if it detects potential malware C&C beaconing, it'll show the bytes it flagged as matching the signature, and some ~200 bytes before and after it). We're also able to view, change, or add all the rules it uses. The source code is closed, so that part is a blackbox, but it seems like a huge stretch to call the entire appliance a blackbox considering we're 100% responsible for integrating, managing, and utilizing it.
I imagine Fidelis probably also offers a professional services option that allows them to manage setup and maybe even remote monitoring. If this is true, there's absolutely no reason why Berkeley can't hire competent infosec folks to handle it all internally, especially considering they have a lot of smart students in the field.
My understanding of the situation (which I'm not involved with since I'm no longer Berkeley faculty, but I follow because I was in the past) is that the office of the president (UC-wide, not just UCB) ordered the systems installed and specifically out of the control (and over the objections) of UCB IT services.
> If this is true, there's absolutely no reason why Berkeley can't hire competent infosec folks to handle it all internally, especially considering they have a lot of smart students in the field.
University IT tends to be super fragmented with each department having their own IT. It was probably a lot simpler to contract it out than try and build a central org... and infosec people ain't cheap these days.
0: http://utotherescue.blogspot.com/2016/01/ucop-ordered-spywar... 1: https://news.ycombinator.com/item?id=11006915