FAQ

Devo’s pattern/processes/alert Libraries are updated every week or whenever a critical event happens e.g. a zero day.

Collective sharing of alerts. Devo clients can share alerts that are relevant for their own business/industry with other clients.
Alerts for Devo are far more sophisticated than those of our competitors: an alert is defined not as a simple rule, but rather as a process/behavioural pattern.

All alerts are delivered in real time, can use a richer set of historical data and are far more detailed than those for specific log fields (not only for the log per se)

Type of alerts: some alerts are defined by Devo and are common to most clients and others are specific to a certain industry and are defined using a transversal view and the sharing of client experience.
Devo has defined instructions for log delivery from most relevant devices, operative systems (Windows, Unix, Linux, Routers, Switches, etc.) and applications (Oracle, MySql, Apache, Tomcat, Websphere, etc.)

Devo also provides instructions on how to easily integrate the customers’ own application logs. Developers can integrate Devo services in their own applications through a public Java API.
For Devo, events are not treated as data strings; rather, logs are structured and treated according to their type and source allowing us to perform complex analyses of the logs’ data fields.

We accept logs from any type of device or system. Devo gathers data not only from security devices but also from systems (Linux, Windows, etc.), security infrastructure, (routers, switches, etc.) applications infrastructure (web servers, application servers, databases, etc.) and business applications (SAP, homemade apps, etc.).

Devo can recognize each datafield within a log from any of the above sources in order to perform searches and correlation.
No data is lost: Devo stores all the data of all the events of all the logs. Additionally, searches can be performed on specific datafields and can also be linked/resolved out of the system (e.g. Delocalization).
All data is actively searchable in real time. From a search point of view, it makes no difference whether it is a log stored 10 seconds ago or 10 years ago. Search time does not increase with the amount of data stored.

For instance, if a given search for data stored yesterday requires 3 seconds the same search in 10 years time will require 3 seconds.
Devo handles upgrades via the temporary replication of client infrastructure. For example, for every new version for each client Devo will run the old and the new version in parallel for a period of a week until we are confident the new version works properly.

Devo will also pilot new versions with a selected set of clients.
Devo always provides two replica databases which are constantly updated (in real time). Further backup services may be contracted, such as separate datacentres and geographical areas.

Devo offers different backup alternatives: 6 months, 1 year, 2 years, 5 years.
Delivery: Devo supports compression at the origin for the delivery of data using standard lzw algorithms– with typical compression ratios of around 12:1

Storage: compression is performed in real time upon receipt of logs and events. These logs and events are immediately available for querying and correlation.
Real time. There is no batch processing, all events and logs are available for search and correlation from the moment they are received, which happens in less than a second.

Devo can deliver real time reports based on recent past data or complete historical data.
Real time, unless the client decides otherwise (Devo can also support deferred delivery of data).
Each client is assigned an ID code, if logs are encoded at destination. Devo can also provide its clients with private, isolated data storage.
Devo supports the delivery of encoded data using standard protocols over SSL, TLS, syslog (TCP, UDP and TCPC), SFTP, etc. and authentication with X509v3 digital certificates. The client may deliver their logs to a relay server that will deliver the properly encoded logs to Devo.
Devo's highly secure standards are delivered in several ways:
  • Permission levels per type of view. There is total granularity when viewing of log data. Different types of view can be attached to each log and different permission levels can be assigned to each view. For instance, a technician can view certain data in comparison to a Security Manager or an Auditing department. Also, views can be established based on the importance of the log.
  • Encoding of events. Data fields for each event may be encoded or decoded for certain specific access profiles.
  • Privacy levels. Data may be stored with different privacy levels. Additionally, data can be stored in WORM (write Once Read Multiple) systems to avoid modification.
  • Digital Signature and TimeStamp per event to ensure compliance with legal requirements.
See What Devo Can Do for You REQUEST DEMO