WEBVTT 1 00:00:00.618 --> 00:00:12.626 Welcome to NxSAM training. This module covers System: the platform's own configuration, its health, and the screens you open when somebody tells you the numbers are wrong. 2 00:00:13.238 --> 00:00:25.199 Most of it is set once and left alone. But knowing what is here is the difference between diagnosing a problem in five minutes and escalating one that was never a problem at all. 3 00:00:25.772 --> 00:00:36.798 We will go through it in the order you would actually need it: the settings that shape how the product behaves, the ones that decide what gets delivered, and then the health screens. 4 00:00:37.370 --> 00:00:41.851 Start with the setting that touches more numbers than any other. 5 00:00:42.472 --> 00:00:58.445 Service-level configuration is where you say how long a finding of each severity may remain open before it is overdue. Every overdue count, every ageing chart and every escalation in the product derives from these durations. 6 00:00:59.073 --> 00:01:15.546 Which makes it worth setting once, deliberately, with the people who will be held to it. A duration nobody agreed to produces a permanently red dashboard that everybody learns to ignore, and an ignored dashboard is worse than no dashboard. 7 00:01:16.150 --> 00:01:33.128 Be aware of what changing it does. Durations are applied when a finding is measured, so a change moves the position rather than only affecting new work. That is usually what you want - but tell people before the overdue count moves overnight. 8 00:01:33.755 --> 00:01:39.837 Adding one asks for three things, and the third is the only one that is really a decision. 9 00:01:40.401 --> 00:01:47.251 An asset type, because a network device and a public A P I do not deserve the same clock. 10 00:01:47.867 --> 00:01:58.773 A severity - and note that container findings get their own seven-level scale rather than the usual five, because the distributions that feed them grade things that way. 11 00:01:59.376 --> 00:02:12.250 And the duration itself. Below those, Add Asset Properties is the part worth knowing about: it lets one severity carry different clocks depending on a property of the asset. 12 00:02:12.840 --> 00:02:30.064 So an internet-facing application can have seven days for a critical finding while an internal one has thirty, without inventing a second severity scale to express it. That is the mechanism most organisations reach for eventually, and it is already here. 13 00:02:30.660 --> 00:02:36.909 Then how risk is scored, which is configurable in two places for two different reasons. 14 00:02:37.491 --> 00:02:50.629 The first is the base: how much a finding's severity contributes, and how much its age does. That pair alone decides whether an old medium outranks a new high in your organisation. 15 00:02:51.225 --> 00:03:08.373 There is no universally right answer to that. A regulated business usually wants age to bite hard, because a finding open past its due date is a compliance problem regardless of severity. Others weight severity almost entirely. 16 00:03:08.999 --> 00:03:14.289 The second place is the analytics rule engine, which is more expressive. 17 00:03:14.910 --> 00:03:31.936 It has two halves. Sources say where scoring inputs come from. Scoring rules say what to do with them - so you can raise the score of anything on an internet-facing asset, or anything owned by a business unit under particular scrutiny. 18 00:03:32.538 --> 00:03:46.695 Two controls here are worth understanding before you touch them. Re-discover finds what is available to score against. Recompute scores applies your rules to everything that already exists. 19 00:03:47.302 --> 00:04:03.898 That second one is the important one, and it is deliberately manual. Changing a rule does not silently rewrite history - you decide when the existing population is rescored, which means you can change a rule and see what it would do before committing to it. 20 00:04:04.511 --> 00:04:10.283 Then the setting that decides whether anything the platform produces reaches anybody. 21 00:04:10.904 --> 00:04:22.122 Mail server configuration is unremarkable - a host, credentials, encryption. Two controls beside it are not, and both save real time. 22 00:04:22.722 --> 00:04:37.104 Test sends a message immediately and reports what happened. Use it after every change, because the alternative is discovering the configuration is wrong when a scheduled report fails to arrive three weeks later. 23 00:04:37.701 --> 00:04:56.863 And debug mode records what the platform tried to send. When somebody says they did not receive a report, that setting is what tells you whether it was never generated, never sent, or sent and lost after it left you. Those are three different problems with three different owners. 24 00:04:57.459 --> 00:05:05.800 Leave debug off routinely and turn it on when investigating. It is a diagnostic, not a permanent state. 25 00:05:06.436 --> 00:05:13.600 Directory integration is next, and it changes how accounts are managed rather than what they can do. 26 00:05:14.215 --> 00:05:24.908 Connect a directory and people sign in with the credentials they already have, which removes a password to forget and gives you one place to disable somebody who leaves. 27 00:05:25.493 --> 00:05:36.832 More than one account can be configured, which matters for organisations that have more than one directory - after an acquisition, or where contractors sit somewhere separate. 28 00:05:37.425 --> 00:05:53.417 What it does not change is authorisation. The directory says who somebody is; their role in this platform still says what they may do. Keep that distinction clear, because it is the one people assume the integration removes. 29 00:05:54.028 --> 00:05:59.772 Three smaller settings, each of which shows up in more places than you would expect. 30 00:06:00.372 --> 00:06:13.919 Tags are defined per area - applications, audits, network security, A P I. Defining them centrally rather than letting people type free text is what keeps a tag usable as a filter later. 31 00:06:14.501 --> 00:06:32.274 Colour configuration sets the severity palette used everywhere: in the product, in exports, in generated reports. Change it once and every future document follows, which is how a report matches your house style without anybody editing a template. 32 00:06:32.876 --> 00:06:46.542 And the asset limit is a licensing boundary rather than a preference. Worth knowing it exists before an import stops part-way, because that is a confusing failure if you do not know what caused it. 33 00:06:47.151 --> 00:06:52.752 Now the health screens, and the first is the most substantial thing in this module. 34 00:06:53.359 --> 00:07:02.628 Health check answers a question every security team eventually asks: does what this platform holds still match what the scanner says? 35 00:07:03.201 --> 00:07:13.317 You upload a fresh export from the tool and compare. The result is not a pass or a fail - it is a breakdown, and the columns are the point. 36 00:07:13.893 --> 00:07:27.959 A baseline count and a current count. Then new, fixed, repeated and re-opened. Then a match key, a classification, a status and sub-status, and an S L A expiry. 37 00:07:28.521 --> 00:07:43.436 Match Key is the column that explains everything else. It is what the comparison used to decide two records are the same finding - so when the numbers look wrong, the match key is almost always the reason rather than the data. 38 00:07:44.005 --> 00:08:03.865 Classification is where each row lands: matched cleanly, present here but not in the tool, present in the tool but not here, and so on. Download All Failures takes out everything that did not reconcile, which is what you work through. Rerun Now repeats the comparison. 39 00:08:04.476 --> 00:08:09.091 The configuration screen decides what is checked and who is told. 40 00:08:09.701 --> 00:08:26.222 Which connects directly to the integration settings we saw elsewhere. A matching key that is too narrow collapses distinct findings together; one that is too wide makes every finding look new. This screen is where that choice is made. 41 00:08:26.822 --> 00:08:40.081 Add recipients there and it becomes a scheduled reconciliation that emails somebody rather than a screen anybody has to remember to open - which is the difference between a check that runs and one that exists. 42 00:08:40.717 --> 00:08:44.903 Two screens report on the machinery behind the analytics. 43 00:08:45.495 --> 00:08:56.041 Large estates do not report well from the same store that runs the application, so analytics are served from a separate warehouse, kept in step by a sync. 44 00:08:56.661 --> 00:09:09.775 The top of the screen is the warehouse's own health: whether it is operational, how fast it is responding, how long it has been up, and a row of cards covering the things that go wrong first under load. 45 00:09:10.382 --> 00:09:20.308 Below that sit the source modules with their sync state, and a history of every run with its row count, who triggered it, and when it started and completed. 46 00:09:20.886 --> 00:09:35.248 If this screen reports that no warehouse is connected, that is a configuration matter rather than a fault - analytics simply have not been pointed at a warehouse yet, and somebody with system access needs to do that once. 47 00:09:35.863 --> 00:09:54.234 The reason to know this screen exists is a specific symptom. If a dashboard disagrees with a findings list, the findings list is authoritative and the warehouse is behind. That is a sync question, not a data question, and this is where it is answered. 48 00:09:54.809 --> 00:10:00.121 Beats configuration reports the same shape for the scheduled data feeds. 49 00:10:00.757 --> 00:10:17.744 Per module and sub-module: the last sync status, its type, and when it was initiated and processed. The same reading habit as everywhere else in this product - an initiated time with no processed time is a job that started and did not come back. 50 00:10:18.339 --> 00:10:23.435 And four operational screens, each of which answers one question. 51 00:10:24.036 --> 00:10:33.748 Server status says whether the platform's own components are running - the A P I, the database, the queue and the cache, each with its uptime. 52 00:10:34.324 --> 00:10:54.682 Process manager shows the background workers - the things that parse uploads, generate reports and send email. That one is worth checking early when a queue is not moving. A report stuck at pending and a worker that is not running look identical from the reporting screen, and only one of them is a reporting problem. 53 00:10:55.292 --> 00:11:06.079 Task information lists the scheduled work and lets you add to it - the syncs, the notifications, the nightly jobs that expire deviations and close findings. 54 00:11:06.668 --> 00:11:19.922 And the licence screen records when your licence expires. Read it alongside the asset limit rather than separately, because between them they explain most of the ceilings you can run into. 55 00:11:20.525 --> 00:11:32.535 Application update is the last of them, with release logs beside it. Read them before updating rather than after - they are where a change to a default is written down. 56 00:11:33.120 --> 00:11:53.865 One more screen, and it is new. AI Configuration is where the platform's AI service is connected and told what it may be used for. Today that is one thing: reading the evidence uploaded against a compliance or third-party control, and suggesting a finding to the auditor with a confidence score. 57 00:11:54.440 --> 00:12:09.403 The provider and its key - stored encrypted, and never shown again once saved. The model that reads the evidence. How often queued evidence is analysed. And a spending cap per audit. 58 00:12:10.000 --> 00:12:31.781 Set the cap from the evidence, not from the budget. A cap is spent by reading files, so an audit with a large evidence pack exhausts a small cap early - and its remaining controls then sit at pending indefinitely. An auditor reporting that the AI stopped halfway through has almost always met the cap. 59 00:12:32.360 --> 00:12:50.109 Two things worth knowing before switching it on. Nothing is written by it - the auditor still answers every control, and the evaluation appears beside the evidence as a suggestion. And it is on per module: Compliance, third-party risk, or both. 60 00:12:50.680 --> 00:12:55.851 The queue behind it is one click away - it opens in a tab of its own. 61 00:12:56.460 --> 00:13:01.223 Every analysis run, with its status and when it was queued. 62 00:13:01.800 --> 00:13:15.251 Re-analyse runs one again: it reads the same evidence and replaces the previous evaluation - and spends against the same cap, so a queue re-analysed to get past a cap stops in the same place. 63 00:13:15.840 --> 00:13:40.548 That is System. Service levels and risk scoring, which shape every number. Email, directory and tags, which shape how the platform behaves. Health check, which reconciles what you hold against the tools. And the operational screens that say whether any of it is running. 64 00:13:41.120 --> 00:14:00.594 Three screens are worth knowing by heart, because they answer the three complaints you will actually get. The warehouse sync, when a dashboard disagrees with a list. The process manager, when something is stuck. And health check, when the data itself is in question. 65 00:14:01.171 --> 00:14:06.800 Everything else here you will set once. Those three you will use.