Neon Cyber Developer API (1.0.3)

The Developer API was designed to allow developers to quickly access data from their Neon Cyber deployment including data about each user and browser (AKA Clients), browser events such as platform information and Neon detections like malware or threat intelligence that triggered on browsing behavior.

It is important to understand our terminology when working with the API. A Client is likely an employee in your organization that is associated to a Deployment group, has a policy set, and registers their browsers with the Neon Cyber platform. Clients always have a corporate email as a reference to their management. This is distinctly different than a User of the platform. A User in our context is a dashboard user, such as a member of your Security Operations team. A User can log into the frontend, manage deployments, policies, detections, etc. While a User is mostly likely also registered as a Client we make a distinction.

Users can:

• Log into the dashboard at https://app.neoncyber.io
• Create deployments
• Create a developer key and use this API

Clients can:

• Register their browser with the Neon Cyber Platform
• Use the Neon Cyber Web Agent to generate events, detections, and receive Policies

Clients can't:

• Log into the dashboard
• Manage any configuration or settings
• Call this API

Now that you have a better understand of what a Client is, let's cover Registrations. If a Client is an employee with an email address, a Registration is their one-or-many browsers protected by the platform. In most cases Clients will have one Registration which is equivalent to a single browser, perhaps on their work laptop. In other cases Clients may have additional browsers that can also register. A Registration is the association of these browsers connecting to the Neon Cyber platform, creating a record, and getting authentication and policy settings.

Clients have:

• One record with an email address

Registrations can have:

• Many records associated with the Client id
• One record associated with the Client id

We have covered Clients and Registrations, let's talk about Deployments. A Deployment is a group of Clients that you want to manage as a logical group. It's easy to think of these groups like you would in any IT directory. You may have a deployment group for Engineering, or HR. When your account is created it also creates an Organization wide Deployment group that is immutable and has a default policy. This allows you to then register and onboard clients without additional configuration. However, you may want to create more Deployment groups based on your needs, as mentioned above. A Deployment has Settings and a Policy associated with it that gives you fine grained control over how that group will be configured when Clients register.

Deployments have:

• Settings that dictate what type of events you would like to collect
• A Policy that dictates what type of detections and security settings to enforce

Clients have:

• An assigned Deployment for associated settings
• Only one Deployment, but Clients can be assigned to different Deployments as needed

The Neon Cyber Platform has a multi-layered approach to investigating data throughout its lifecycle. We do this because we want our Users to have options when protecting their organization.

At their post basic Events are raw telemetry collected straight from the Clients browser. This data is uninterpreted by Neon Cyber and gives you access to what we can can see. We consider this an unopinionated data set, where no processing has been applied. A good example of this is the Platform event. This event gives you the Client browsers platform data without the additional associations we make in the frontend.

Detections are processed Events that go through our first level of security analytics to enrich and detect security relevant context. A Detection is always worth investigating but may be considered low/medium/high severity by your Organization. A good example of a Detection is when a Client downloads a file while in Incognito mode. The severity is up to you, but we think its important and so our Detections are considered opinionated events. Detections can be configured and supressed or elevated to Alerts, which we will discuss next.

Detections also include a Detection Pattern-of-life accessible through the API. When investigating a detection you can use the detection ID to get a complete snapshot of the browsing activity that triggered the detection. By default the PoL includes 20 entries and will always include the first 5, showing how the tab was opened and initial browsing activity, as well as the last 5 up to and including the page that triggered the detection. We continuously trim the middle 10 based on storage and memory for long running tabs.

All requests to the API must include an additional "Authorization" header with you API key. This key can be generated from your Account page on the Neon Cyber dashboard. A detailed example of the requirement is included in each request using curl but is the same for any request method.

As we continue to build we will create language specific SDKs to improve the Developer Experience. Our first SDK will be Python and we will update our users when it is available.

Apps are the SaaS apps in our catalog that are tied to user behaviors and includes a summary of the company, authentication, compliance, and more.

Clients (AKA Employees w/Email) associated with a Deployment group.

Logical groups for managing Client onboarding, policies, and browsers.

Security events that require attention. These detections are opinionated events that are either known security events or require investiation.

Note: For performance reasons the source data view is columnar and may include 'null' fields when a detection type filter is not applied. This does not mean that expected data for each detection type is missing.

The Neon agent keeps track of browsing events locally in the browser that are sent when a Detection occurs. This Pattern-of-life gives users the ability to see what lead to the detection, including why the tab was opened, what websites the user navigated to, and the remote resources of the offending page.

Browser telemetry events and actions. These events are collected from the Neon Agent as un-opinionated data as it happens in the browser.

Note: For performance reasons the source data view is columnar and may include 'null' fields when an event type filter is not applied. This does not mean that expected data for each event type is missing.

Policies allow you to manage which events or detections are collected and emitted.

Browsers that have registered with the Neon Platform and associated to Clients. Clients can have one-to-many registrations associated with their Client (w/Email)