Feature request: API for management console

[thegeekkid]

One of the biggest things that I miss in the management console that I find in many other enterprise security solutions is an API.  I'm of the opinion that anything and everything that you have to do more than 3 times in IT security needs to be automated.  Recently I've found that I need to log into the management console daily because we are finding that certain things such as signature updates are getting hung up, and a number of our endpoints are also getting errors with updates and we aren't getting alerted.  This is not the first time we've experienced this either.  While we are working with support to fix the underlying issues, we are now forced to add logging onto the management console and checking signature and client versions to our daily routine (all of which could be easily automated with an API).  I know it's probably not the easiest thing to add, but I could see a huge benefit for enterprise customers.

[djacobson]

The console is actually just a GUI portal to the SQL database and a host of an internal IIS website. An API would not be applicable to it in its current form. The clients themselves are the ones that control communication.

The business Anti-Malware agent does have an API, the tool is called mbamapi, and this is actually how the managed version is manipulated, through mbamapi commands. It is located in %programfiles%\Malwarebytes' Anti-Malware. The commands are covered in the documentation for the unmanaged version of Anti-Malware in your download package.

[djacobson]

If you have a good DBA on staff, I can give you the DB schema so that they may create SQL queries to accomplish the version status investigations you need to do.

[thegeekkid]

I'm pretty comfortable with SQL and we also have a few DBAs on staff... so yes... the schema would help.

The mechanics behind how the management console works isn't really extremely different from many other products that offer an API.  One of the reasons people prefer to use an API (in addition to it being easier if it's properly documented) and companies prefer giving users an API instead of having them directly access SQL is that the developers can build checks in to be sure nothing drastic happens - which makes any troubleshooting needed later much easier since that takes an unknown variable out of the mix.

None the less, I understand this isn't just a "snap your fingers and it's done" request... just something to consider down the road.  For now having the SQL schema should help us quite a bit, and we shouldn't have to worry about it causing issues since all we would need to run are select statements to identify issues and alert us so we can take action manually.

Thanks!

[thegeekkid]

I just shot you an PM with my email address if you prefer to email that rather than posting it publicly.

[djacobson]

Sending it your way!

For anyone else out there that may stumble upon this thread in the future when searching around, PM me and I can send you the schema as well if needed.

[IRMeetsVR]

For anyone who needs more functionality than read-only access to the MBMC data via the database (to programmatically control scanning, for example) my company has developed a third party API for Malwarebytes. The software runs in the background as a service alongside the Malwarebytes service on your MBES server and it exposes a RESTful API which gives you full and proper access to all MBMC functionality including:

• Initiate scans of any type with and without the remove option
• Retrieve scan results and other alerts programmatically
• Consolidate client information and control from multiple MBES servers
• Build custom reports based on your queries
• Full policy control
• Read/write full client, group, policy, and other details
• Plus more

On top of the API module we have also built a new MBMC client which uses all of this functionality to provide a more interactive and flexible management solution for MBES. It does not prevent you from continuing to use the traditional MBMC - merely it adds the option to view the information and control MBES however you prefer.

If you would like more information or to be included in the currently-running beta please PM me

* This API and MBMC alternative is a third party solution and is not endorsed or sponsored by Malwarebytes

 

Edited April 17, 2017 by IRMeetsVR

[thegeekkid]

On 4/17/2017 at 5:46 PM, IRMeetsVR said:

For anyone who needs more functionality than read-only access to the MBMC data via the database (to programmatically control scanning, for example) my company has developed a third party API for Malwarebytes. The software runs in the background as a service alongside the Malwarebytes service on your MBES server and it exposes a RESTful API which gives you full and proper access to all MBMC functionality including

That's very interesting.  One of my concerns with that though would be that there are rumors that there might be some pretty significant changes coming to the MBMC and it's functionality, so along with the pending release of the new next gen AV capability to the Managed versions of MBAM, I'm wondering how much that might change a 3rd party API?  Also, considering my company pays quite a bit of money to Malwarebytes for premium support (and we do use it somewhat often due to our size - based on the number of endpoints we have, running into issues with various software is just inevitable no matter how well written it is), I'm wondering if a 3rd party API could make it so Malwarebytes wouldn't provide support anymore for certain functionalities (which is one of the reasons I am always hesitant about directly tying into SQL and prefer a officially supported API)?

As it stands now, the SQL schema that we were sent allowed us to put together the functionality that we needed, but we are aware that if a significant update does come soon, we will probably have to re-write our integrations.  That being said, if your API does withstand the rumored update, it certainly might be something we would consider in the future since automation is becoming a huge part of our IT department.

[thegeekkid]

Also, just to clarify: the support issue would be our biggest concern if we ever implemented a 3rd party API with any product.  At least with tying directly into SQL, it was suggested by a Malwarebytes staff member; and I am completely responsible for my code, so if it ever came into question, I would know exactly what it's doing and if it could be causing XYZ problem.  With a 3rd party API, if it ever came into question whether or not it could be causing XYZ issue, I am not responsible for that code, so I would have no idea how to respond to that.

[IRMeetsVR]

You summed it up perfectly. We share all of those same concerns but we had to move ahead to support orchestration and automation requirements of our customers. Originally we tried to do everything with MBES by directly accessing the database because we believed that would be the simplest and most reliable method. However what we discovered is that while reading works fine when it came to making changes or issuing commands that method is actually not very stable in a lot of cases. For example, if you modify specific policy fields directly in the database we've seen lockups and crashes of the server and the MBMC client(s). If you try to control scanning activity by adding entries to the TBL_CommandToClient table that doesn't work and in fact prevents the server from running any other jobs until your changes are backed out again. The database is simply not reliably tolerant to updates and inserts outside of the system in our experience.

Fortunately the MBES architecture is already built on an API-like client/server model. The server is 2 parts - the MBES service and the MBMC GUI client that accesses it. In the supported architecture you can already deploy multiple MBMC management console clients and that works well. The MBES service exposes a control protocol (SOAP API) to the MBMC clients and that is how they interact with the server service. 

Our automation solution is middleware that uses the same SOAP API as the MBMC clients to perform all of its functions and in testing so far has been extremely reliable. As far as the MBES service is aware our connection is just another MBMC client making and putting requests. We are very open and transparent and if you wanted to go deep to a code level into how it works we could definitely walk you through it. You are also right to point out that as new releases come any third party integrations are potentially going to have to play catch-up. Historically there hasn't been a high frequency of significant updates to the MBMC or the client/server architecture and the changes that there have been to date have mostly maintained protocol compatibility save for a few tweaks. 

As automation initiatives continue to ramp upwards and outwards within most large enterprises there is always a discussion about what can be brought into the scope vs what isn't going to make it. We can help make MBES a part of that taking advantage of all the existing investment and deployment efforts that have gone into it.

I've also heard those rumors about something new that may be on the horizon and we are eagerly awaiting that!

[RickAtRITE]

Has this database schema been made public?  If not could someone DM it to me as well?  Looking to do something similar.  Thanks!

[djacobson]

18 hours ago, RickAtRITE said:

If not could someone DM it to me as well?

Sent.

[krisgabor-axonius]

Any update on this topic?  Looking for an API to the management back-end (both on-prem and cloud) to fetch info on managed endpoints.

[straffin]

On 11/27/2018 at 1:28 PM, krisgabor-axonius said:

Any update on this topic?  Looking for an API to the management back-end (both on-prem and cloud) to fetch info on managed endpoints.

#metoo