1

2
3
4
This is what the new Web Console looks like; certainly, it is very unfamiliar to work
with at first.
You are unlikely to quickly learn what is where and how to perform standard
actions well-known from MMC.
That is why if you want to completely switch to the new Web Console, you must
arm yourself with patience.

The main advantages of Web Console when compared with the MMC:
- It does not require installing on the client side, you need only a web browser
- Since only a web browser is required, you do not need to care about the
operating system
- You can look through the reports right from the beach using a mobile device

You will be able to manage only KES for Windows and KES for Linux in the first
release of the Web Console.

It does not support encryption, MDM, or VAPM; but all reports are available.

5
Web Console has an individual distribution.
You can install it on the computer where KSC is installed, or on any other computer.

The Web Console distribution is not listed among other sub-packages, but you can
find it within the Server folder of the KSC distribution.

6
You can install the Web Console automatically when installing KSC.
One of the installation wizard steps prompts you to indicate whether the Web
Console should be installed together with KSC.
The Web Console is installed with the default parameters; in particular, port 8080 is
used for connections.

At the last step, the installation wizard will prompt you to start MMC or the Web
Console.

To connect to the Web Console manually, type https://<address>:8080 in the

browser address bar.

Port 8080 will most probably be changed to 443 in the release.

7
Let us quickly go over the Web Console installation wizard steps when deploying it
from an individual distribution.

After you start the installer, select the language for the installation wizard and click
Next on the first page.

8
Then accept the EULA and look through the languages available for the Web
Console.
You can load other languages in JSON format.

9
Then specify the installation path or leave the default one unchanged.
At the next step, specify the address and port that will be used for connecting to
the Web Console.

Port 8080 will most probably be changed to 443 in the release.

10
The step with service accounts is likely to be changed.
You will be able to select whether to use the default accounts, specify custom
accounts, or generate them automatically.

The next step is creating a certificate for the web server where Web Console will be
running.
It will be generated automatically. Alternatively, you can use a custom certificate.

11
The most important step is adding a trusted KSC Server.
The administrator specifies with which KSC the Web Console will be able to
interact.
If the Web Console is being installed on a computer where KSC is installed already,
this KSC will automatically appear on the List of Trusted Servers.

Otherwise, you will need to manually add the server: Specify its address, port, and,
last but not least, the path to the KSC certificate.
This certificate will then be copied to the Web Console installation folder.

Web Console will connect to KSC on port 13299 by default; you can change it in the
Administration Server properties if necessary.

12
The last but one step is starting the installation process with the Install button.
And the last step is to start the Web Console and finish the wizard, or just finish the
wizard.

13
After the Web Console has been installed, the following services are installed:

- Kaspersky Security Center Management Service

- Kaspersky Security Center Web Console—a Node.js platform on which the
interface of the Web Console is implemented.
Node.js (or simply Node) is a JavaScript runtime environment built on V8
engine, which converts JavaScript into machine code.
JavaScript performs actions on the client side, while Node, on the server.

- Kaspersky Security Center Web Console NSQ provides a platform for processing
the message queue

14
The interaction schema is as follows.

The Web Console is a Node.js web server.

The server part of the Web Console (in the center of the schema) connects to KSC
over a new KSC Open API protocol, which is based on HTTPs.
The client part of the Web Console (on the left) is a Single Page Application (SPA).

In its most basic form, SPA is a web application that literally has only one page,
which loads content dynamically.
Meaning, when you click an interface element in the Web Console, a Javascript
runs that loads the respective modules and visualizes the requested content.
It looks like a new page has opened.

15
The previous slide demonstrated the scenario with a single KSC.
And what are we supposed to do if we have several KSCs and want to connect to all
of them via a browser?

The simplest option is to install a dedicated Web Console on each KSC and work
with them from different browser tabs.

Alternatively, you can use one Web Console as a single entry point and add several
Trusted KSC Servers to it.

16
KES plugin is required for managing the product via the Web Console, just like with
the MMC console.
Products’ plugins are not installed by default, you must install them manually.

Open the list of plugins, click Add, and select from among those available.

By the way, the Web Console can uninstall plugins, unlike MMC.

18
19
20
Several new nodes have appeared in the console tree:
- Multitenant applications—applications by Kaspersky Lab that support
multitenancy are to be displayed here, for example, KSV. It is rather a
preparation for the future
- Deleted objects—removed entities such as tasks, policies, and installation
packages end up here
- Triggering of rules in Smart Training mode—this node contains information
about the events of a new Adaptive Anomaly Control component (rules
matched in the Training mode)
- Active threats (previously known as Unprocessed files)

21
What can get in the Deleted objects node?
All entities whose properties contain the Revisions section are moved to the
Deleted objects node upon removal.
Namely:
- Policies
- Tasks
- Installation packages
- Virtual Administration Servers
- Users
- Security groups
- Administration groups

In a sense, it is a counterpart of the Windows Recycle bin.

22
A subnet can be used in several places in KSC.
For example, in KSC properties, where you can limit traffic by time intervals.
Or in a Network Agent policy, when configuring connection profiles.

In KSC 10, you have to specify subnet parameters in each place individually, which
is rather cumbersome.

In KSC 11, a new section has appeared in the Administration Server properties
where you can specify the list of your organization’s subnets once, and this list will
be available wherever you need to select a subnet in KSC.

23
KES 11.1 installation packages do not have pre-configured installation options in
KSC 11 anymore.

Instead, a protection indicator has been added to the installation package

properties, which was available only in the policies previously.
If the administrator decides to disable installation of an important component in
KES 11.1, the indicator will change its color.
You will also see what decreases the protection level.

24
25
As you know, several sets of databases are stored on the update servers: Full and
so-called diff files, the difference (delta) between the current and previous update.
There are daily and weekly diffs.
KSC 10 can download only the full databases; KSC 11 can download both sets, full
and diffs.

The paradox is that KES can work with diffs since long ago, but only when
downloading updates from the internet; and from now on, KES will be able to use
diffs when updating from KSC, too.
It will help to decrease internal traffic manyfold.

26
Take notice!

There is the “Download updates from KSC in advance” option in the Network Agent
properties.
If this option is enabled (and it is enabled by default), KES will update the old-
fashioned way, without using diffs.

27
28
Update Agents can also distribute DIFF update files now.

Additionally, they can act as KSN Proxy and redirect KSN requests from the
protected devices to the Administration Server or directly to the global KSN
servers.

29
By default, KSC assigns Update Agents automatically.

With KSC 10, if the administrator wants to assign Update Agents manually, it can be
difficult in a large network.
Why? Because an Update Agent has been able to support 500 hosts at the most.
And in a network of several thousand hosts, you’ve had to assign numerous Update
Agents to cover the whole network.
Besides, not every computer can become an Update Agent; it must meet specific
system requirements and have a specific operation mode.

On the whole, manual allocation of Update Agents has been a tricky task in large
networks.

This issue has been solved, because one Update Agent supports up to 10 000 hosts
now.

30
Since the number of supported hosts has increased, the system requirements for a
computer that can become an Update Agent have changed accordingly.

31
32
33
KES plugins are backward compatible in KSC11.

So far, if a few KES versions have been used in the network concurrently, the
administrator had to support an individual set of policies and tasks for each
version.
Now, policies and tasks of KES 11.1 are applicable to KES 11.

34
A new section has appeared in the remote installation wizard: Behavior for devices
managed through other Administration Servers.

If there are several KSC servers in the network, they may see the same devices.
This option prevents installing the product on a device connected to another KSC.

35
36
Changes in RBAC.
First and foremost, RBAC does not require an Administration Server license
anymore.

Second, new roles have appeared:

- Auditor
- Security Officer
- Supervisor
By default, they are not assigned to anyone.

Third, the list of roles can be retranslated to slave Administration Servers.

You have had to work with roles on each Server individually so far, which has been
quite boring.
Now, you can create and configure roles in a single location on the Master
Administration Server and propagate them down the hierarchy.

37
New reports have appeared in KSC 11.
The first two are related to the new component of KES 11.1; we will talk about it
later.

‘Report on the status of application components’ clearly shows to the

administrator which components are installed, where, and their current statuses.
This information is important because if a component is installed, but is not
running, protection efficiency decreases on the endpoint.
Previously, there was no single location for checking KES components’ status for all
devices at once.
To find out which components are installed and running, the administrator had to
check every host one by one, which was tedious and took much time.

If necessary, you can create detailed reports for individual components based on
this report, for example, check where Endpoint Sensor is installed.

38
Report on threat detection by components and detection technologies.
The report displays detected threats and which protection components and
technologies pinpointed them.
It visualizes the solution’s work.

39
40
41
Let’s sum up the changes introduced in KSC 11.

Minor changes include integration with SIEM, but it is simple.

You do not need a KSC (Systems Management) license to send events to a SIEM
system over Syslog anymore.
However, it applies to Syslog only; integration with ArcSight, QRadar, and Splunk
still requires a license!

42
43
44
45
Two new components have appeared in KES 11.1:
- AMSI Protection Provider
- Adaptive Anomaly Control

AMSI Protection Provider can be installed on workstations and servers; and AAC,
on workstations only, at least as of now.

46
47
The first new component is AMSI Protection Provider.

AMSI (Antimalware Scan Interface) is a Microsoft technology with open API that
permits third-party applications to synchronously scan various objects: files,
memory, links.

For example, PowerShell scripts that may seem harmless on the face of it and
antiviruses may fail to detect any threat in them; when run, however, they can
generate malicious activity or download something from a remote source and
execute in the memory.
Or so-called fileless threats or obfuscated scripts.

Sure, contemporary protection applications have various mechanisms (behavior

analyzers) that permit fighting these threats too, but it is a nontrivial task.
That is why additional tools such as AMSI should not be neglected.

48
How does it work?
Let’s look at an example.

Many popular attacks start PowerShell interpreter from a macro within a Microsoft
Office document and then run a malicious script.
However, before the PowerShell script is executed on the device, it will be sent to
AMSI.
AMSI will log the script’s actions and send its commands to KES.
Meaning, all commands that the script generates either on-the-fly or in the
memory are sent to KES for scanning.
KES returns its verdict to AMSI, and AMSI instructs the application whether to run
the script depending on the verdict it has received.

49
This is what it will look like in reports and events in KES and KSC.

50
51
52
53
A new component: Adaptive Anomaly Control.
Similar to other control components, AAC requires a KESB Advanced license.

AAC is a classic behavior blocker that can adapt to the environment.

AAC contains a set of heuristics that will be updated periodically.

Most popular behaviors that are typically matched and rarely return false positives
are represented. (According to statistics by System Watcher.)

The component detects abnormal behavior non-characteristic of this specific

computer.
Which behavior is characteristic, and which is not, KES 11.1 can tell after two-week
learning. A so-called Smart mode is enabled by default.
Thus, depending on the user’s activities, KES 11.1 will learn differently on each
computer.

54
.

55
As I already mentioned, the component learns for approximately two weeks after
the installation. Nothing is blocked meanwhile.
If there are no detections within a fortnight, the rule will switch to the Block mode.
When a rule is matched, the corresponding alert is generated

56
57
58
59
60
61
62
63
64
If necessary, the administrator can configure everything manually instead of using
the Smart mode.
You can enable or disable a rule and switch the action from Block to Notify.

In this case, detection events will be sent to KSC as ordinary events.

If heuristics works in the Block mode, you can create an exclusion right from an
event if necessary.

65
66
67
The HTTPS protocol is widely used nowadays; previously, it imposed restrictions on
the Web Control and Web Threat Protection components.
Web Control could block such websites only by links; blocking by content did not
work.
Web Threat Protection was not able to scan downloaded content for malicious
objects.
HTTPS traffic scanning introduced in KES 11.1 has removed this limit.

Traffic interception is based on certificate spoofing.

If errors are encountered when scanning encrypted traffic on some websites, KES
can add such a website to exclusions and skip its https traffic.
The ‘Add domain to exclusions’ parameter is responsible for this. Domains will be
added to the local list of exclusions on the host.

Alternatively, the administrator can set this option to ‘Break connection’; the
websites where issues with https traffic scanning arise will not open then.

A KES certificate is used for scanning traffic; it is issued for 10 years.

The certificate is installed to the Trusted Root Certification Authorities store during
the KES installation.
Every time when the product starts, KES checks whether the certificate is in the
store, and reinstalls it if not.

68
69
70
71
WSL support has appeared in KES 11.1.

Its main purpose is to emulate Linux in the user mode. As a result, you can run
bash shell under a Windows operating system.

Windows Subsystem for Linux translates Linux system calls into Windows system
calls, which permits deploying full-fledged Linux tools on Windows without
virtualization.

The Windows Subsystem for Linux compatibility layer uses the file system of the
main operating system where it is installed, and KES 11.1 will intercept all file
operations executed in the Linux subsystem.

If a malicious file is compiled or run in the Linux environment, KES 11.1 will detect
it and react accordingly.

72
73
Protection from MAC Spoofing has appeared in KES11.1 as a part of Network
Threat Protection.
Protection from MAC Spoofing improves KES’s network protection capabilities;
besides, most of our competitors provide it.

74
How is password-protected access to local KES 11 interface implemented?

The administrator specifies a username and password in the policy, and configures
a list of permissions.
You can specify only one user in the policy. You can invent any username, it will be
just an internal KSC entity.

In KES 11.1, password-protected access is bound to Windows users and groups and
you can specify a password for each user and adjust their permissions.

Two user groups are already added by default: Everyone and KLAdmin with preset
permissions; you cannot delete them, but you can modify their permissions.

75
Another long-awaited change.
If FDE is used, you do not need to decrypt the drive before the migration anymore.
Everything goes smoothly!

Although it is applicable only to KES11. Meaning, if you are upgrading KES11 to

KES11.1, it will be all right.
If you are migrating from KES10, decryption will still be required.

All future releases are also planned to support migration without decrypting.

Also, support for migration from Windows 7 / 8 / 8.1 to Windows 10 has been
improved if KES is already installed in the system.
Previously, you had to uninstall KES before the migration, then upgrade OS, and
reinstall KES.
You will not have to do it with version 11.1.

76
77