PKF AvantEdge

Tag: usm appliance

Alienvault Appliance End of Sales and End of Life

September 27, 2021 / / 2 Comments

All good things must come to an end.

Over the weekend, AT&T put an official announcement out to all partners what we have been informed weeks earlier, that the Alienvault Appliance has now got an expiry date in terms of its life. Since we picked up Alienvault six years ago, dealing with the small support team out from Spain and sales team from Cork, Ireland, it has been a good ride and we’ve learnt massively a lot through the years. AT&T is steering into a different direction, and Alienvault is moving completely into cloud, putting an end to the ever popular All-in-Ones and Standard Appliance. We will miss the days of writing plugins for our clients.

Anyway, here is our official announcement:

27th September 2021

Alienvault USM Appliance End of Sales (EOS) and End of Life (EOL) Announcement

There has been an official announcement from AT&T to all channel partners dated 25th September 2021, that the Alienvault USM Appliance will be placed on a new sales hold effective January 1, 2022. AT&T will also no longer support the USM Appliance effective January 1, 2025. These dates are effectively the End of Sales (EOS) and End of Life (EOL) dates for the USM Appliance (otherwise known as Alienvault On-Premise). If your solution is an “All-in-One”, “USM Standard” or “USM Enterprise”, these solutions will be the ones affected by this announcement.

As one of the first partners of Alienvault in Malaysia since 2015, we are saddened with the news that the popular USM Appliance solution will no longer be available from 2022 onwards. We therefore require any new sales made (either from us or from our partners) from now till 31st December 2021 to inform the potential customer of the above EOL and EOS dates to ensure that purchases are made with this information clearly stated. This is to avoid any miscommunication of expectations to the end-user. Additionally, we will cease all local maintenance support renewal from the date of this letter. The local maintenance support includes arrangements for 24×7, or 8×5 call or onsite support from PKF directly. We will continue to honour all ongoing contracts until the contract expiry. This is in line with us re-allocating our technical resources and focus to other solutions and initiatives. The annual maintenance support and threat intelligence subscription from AT&T will still be continued until 31st December 2024. PKF will still be continuing our quarterly preventive maintenance or any ad-hoc professional service to assist our clients on USM Appliance matters. In summary, the cease dates are as follows:

As we move our focus away from the USM Appliance in both sales and support, we would recommend a transition plan to be in place. This can include the option to move to USM Anywhere, which is the direct transition to AT&T’s SaaS based SIEM. Please contact us at alienvault@pkfmalaysia.com for further details in moving forward.

Thank you for your support all these years and we hope that we can continue to work together for many years to come.


Alienvault USM – Flat File Log Capture – Part 1

June 3, 2019 / / 0 Comments

We’ve been working with and on Alienvault since the beginning of 2016 and a lot has changed since then. When we started out with Alienvault, they were a small-ish company still, with big ambitions, working with a very technical group out of Cork, Ireland. We had direct access to their technical team (I think even to one engineer) and the amount of knowledge we got from those early days are pretty much invaluable to where we are right now. Of course, Alienvault has changed a lot since then, and now being part of AT&T – for the record, we believe they have the right roadmap to go into cloud with their USM Anywhere concept, and their product right now is much more robust and enterprise ready. They are on the right trajectory.

However, back in the days, for Alienvault USM Appliance (not Anywhere), which is their Appliance offering, we could literally ‘jailbreak’ the system and go into the underlying OS and do stuff to Alienvault that we can’t do anymore in Anywhere. Some of the changes we made were to increase optimisation, put in our own scripts to clean up the system, troubleshoot the system and of course, create plugins for custom applications. We would write custom plugins in 1 – 2 days for multiple applications because of deadlines, I remember and had to do so much in so little time – but we did it anyway. We had to write a plugin for one of the oldest mainframes for a financial institution that was so difficult to interpret, we had to dig up old manuals to sort out the entries for log and events. It was like we were interpreting Egyptian hieroglyphs. But that’s what it took – 2 days, I think because of compliance requirements and customer breathing down our neck to get it done.

Writing plugins was the easier part of the battle – in some old machines or legacy applications, getting the logs was the problem. If Alienvault doesn’t get the logs, it can’t do anything with it. One solution was to leverage on the HIDs (Host IDS), or OSSEC as it was known, to grab log files from systems. It wasn’t so elegant, and we still had to end up writing plugins for it to normalise, but it resolve the issue where application was not able to forward logs to the SIEM, or not able to write the logs to the Windows Event service, or any other way to get logs out to a syslogger. So the solution here is for the application to just write the logs to a file, and Alienvault go ahead and grab this and interpret it. It may not be real time, but it works.

There’s a good write up over in Alienvault at
https://www.alienvault.com/documentation/usm-appliance/ids-configuration/process-reading-log-file-with-hids-agent-windows.htm. So a lot of it is just a repeat and probably an exposition on why we are doing certain things in a certain way.

So the first thing to do here is to ensure that you are able to install HIDs on the server. HIDs will be the key to get this file out to Alienvault. Technically, you could actually use NXLog as well but let’s explore that another time.

Once HIDs is installed, get into the ossec configuration file to define the <localfile> location. Now assuming that you have configured your application to write to a flat file called database.log.txt.

Go ahead and restart OSSEC. That’s pretty much what you need to do to start off so it’s pretty simple.

The rest of it is all done on Alienvault.

To summarise the steps:

Enable “logall” on your USM Appliance. You want to dump whatever you are getting in that flat file database log to a log inside your Alienvault so you can start doing stuff to it. In this case, in your AV User Interface:

Environment > Detection > HIDS > Config > Configuration.

Add <logall>yes</logall> to the <global> section of the file .

You are dumping these logs into /var/ossec/logs/archives/archives.log.

Restart the HIDs service through UI.

You should be able to see new logs coming into archives.log. Just do a tail -f on it, edit the log file (database.log.txt) in your remote system (just write something on it) and see if it appears in your archives.log. Once you see it, you are almost done. Very simple.

So for now, you have customised logs coming into your Alienvault. The next thing to do is to interpret these logs and make sure events are able to be derived from these logs to something that is useful to you!

Drop us an email at alienvault@pkfmalaysia.com for more information on Alienvault or any technical queries you have, and we will attend to it.

© 2024 PKF AvantEdge

— Up ↑