Security and Backup I: OEM Architecture

Security and Backup I:
OEM Architecture
Ben Lavalley
Product Manager, Kaseya
Copyright ©2014 Kaseya 1

The information in this presentation is confidential and proprietary to Kaseya and may
not be disclosed or distributed without the prior written permission of Kaseya. This
document, and any related presentation, as well as Kaseya's strategy, possible future
developments, products, platforms, directions and/or functionality are all subject to
change without notice at Kaseya’s sole discretion. The information in this document
does not constitute a commitment, contract, promise or legal obligation to deliver any
material, code or functionality. This document is provided without warranty of any
kind, either express or implied, including but not limited to, the implied warranties of
merchantability, fitness for a particular purpose, and non-infringement. This document
is for informational purposes only and may not be incorporated into a contract.
All forward-looking statements, including those set forth in this presentation, are
subject to various assumptions, risks and uncertainties that could cause actual results
to differ materially from projections. Readers are cautioned not to place undue
reliance on such forward-looking statements, and specifically, not to rely upon such in
making purchasing decisions.

OEM Architecture Status
 Before, in version 6.3:
– Each OEM product was integrated individually with
the Kaseya Agent (client-side) and with the VSA
(server-side).
– Time-consuming maintenance
 Now, in version 6.5 and forward:
– Implemented a unique and generic driver that
manages all OEM products
– Integration with a new OEM product follows a simple
set of rules

Proven Design
 OEM products leveraging this new
architecture today:
– Backup (Acronis)
– Antivirus (Kaspersky)
– Antimalware (MalwareBytes)
– Endpoint Security (AVG)

Overview
 The purpose of the Driver is to run tasks that
take the form of an OEM product executable
being launched as a process.
 Examples of tasks: running a backup, scanning
for viruses, deploying software, etc.

How it works
 The Driver is an “Agent Extension” and therefore is
packaged as a DLL exporting well known functions
(SendMsg, Stop, IsDone). It is loaded by a program
that is launched by the Kaseya Agent.
 Being an Agent Extension, the Driver expects to receive
commands via the SendMsg function. The commands
must be formatted as a command line when typed into
a command shell.
 The Driver is completely “data driven”, meaning that it
has not been built with the knowledge of any OEM
product inside of it.
 The Driver loads data from files and that data drive the
runtime of the Driver.

Catalogs
 First uses of Driver are done internally by Kaseya
for our OEMs
 “Catalogs” created that detail information about
the third party, such as: where it is typically
installed, how to run that product tasks, etc.
 Support for Driver will be part of TAP program
 Three catalogs:
– Supported Products catalog
– Command catalog
– Message catalog
 Catalogs are written in JSON.

Summary
 Benefits of new architecture:
– Generic, same for all OEM & partner products
– Simple, easy to maintain
– Can be dynamically patched
 SDK coming soon -> recruiting new partner
candidates to help create the SDK

Questions and Answers
Thanks for Attending Kaseya Connect
#KaseyaConnect
Let's Share!

Security and Backup I: OEM Architecture

More Related Content

What's hot (20)

More from Kaseya (14)

Recently uploaded (20)

Security and Backup I: OEM Architecture