WEBVTT 1 00:00:00.623 --> 00:00:12.727 Welcome to NxSAM training. This module covers A P I Security: the assessment of service endpoints, tracked separately from the applications that consume them. 2 00:00:12.998 --> 00:00:19.921 That separation is a deliberate design choice, and understanding why makes the rest of the module obvious. 3 00:00:20.200 --> 00:00:38.354 An A P I is usually consumed by several applications and built by a different team from the ones consuming it. Assessing it in its own right means a weakness is found once, owned by the team who can fix it, and not re-reported against every application that calls it. 4 00:00:38.955 --> 00:00:46.790 What A P I testing looks for also differs in emphasis, and knowing the four main classes helps you read the findings. 5 00:00:47.377 --> 00:01:03.875 Authorisation flaws come first - whether one caller can reach another caller's data simply by changing an identifier in a request. It is the commonest serious A P I finding and it is almost invisible from the outside of an application. 6 00:01:04.450 --> 00:01:17.300 Then excessive data exposure, where an endpoint returns far more than the screen using it displays. The screen looks fine; the response contains fields nobody intended to publish. 7 00:01:17.883 --> 00:01:32.632 Missing rate limits, which turn a slow attack into a fast one. And forgotten versions - version one still answering happily long after everyone moved to version two, usually without the same fixes applied. 8 00:01:33.206 --> 00:01:38.856 The audit list carries the same grouped columns as the other assessment modules. 9 00:01:39.460 --> 00:01:59.269 Request Info is who asked and when it starts. Audit Details is what is being assessed. Vulnerabilities is the count so far - progress rather than a verdict. Audit Properties holds your organisation's own fields. And Audit Status is where it has reached. 10 00:01:59.856 --> 00:02:07.043 The status chips above the table are the most useful thing on this screen, and they do two jobs at once. 11 00:02:07.673 --> 00:02:19.328 Saved, Scheduled, Work In Progress, and Completed. They are filters - clicking one narrows the list. And they are the audit's own life, in order. 12 00:02:19.956 --> 00:02:37.007 Which makes them a pipeline view. If you have forty audits sitting at Saved and three in progress, your constraint is getting work requested and approved, not testing capacity. That is visible from this screen without opening a single audit. 13 00:02:37.639 --> 00:02:57.617 Request New Audit starts one. Update Bulk Status moves several at once - what a weekly review meeting produces. More Filters narrows further, and Reset Filters puts it back, which matters because a forgotten filter is the usual explanation for a list that looks wrong. 14 00:02:58.233 --> 00:03:14.227 Twelve actions can appear on an audit row, and no row ever offers all twelve, because several of them exclude each other. Rather than list them, we will open two rows whose states are different and let the menus show you what that means. 15 00:03:14.822 --> 00:03:30.313 This is the first row, the one still at Saved. Seven items: edit its details, edit its tags, read its status history, manage its scope, view its chain, manage its test summary, and delete it. 16 00:03:30.903 --> 00:03:45.244 Edit Tags is here only because the audit is still a draft. Tags are your own classification -- external, regulatory, pre-release -- and they are what a search across years of assessments actually filters on. 17 00:03:45.840 --> 00:03:58.782 Two are ticked on this one. The list itself is fixed by your administrator, which is the point: a free-text label that half the team spells differently is not something you can report on. 18 00:03:59.399 --> 00:04:06.515 Manage Audit Scope is the agreement in writing -- what is being tested and, more usefully, what is not. 19 00:04:07.101 --> 00:04:21.682 Every documented endpoint of the public version two A P I, tested unauthenticated and again with a customer token. Out of scope: the partner A P I, and any test that would write to production records. 20 00:04:22.291 --> 00:04:35.811 Read that second paragraph as the important one. A finding raised outside the agreed scope is where an assessment turns into an argument, and the place to settle it is here, before the work starts. 21 00:04:36.430 --> 00:04:47.696 An image can be attached too, which in practice is an architecture diagram with the boundary drawn on it. That settles more arguments than the prose above it. 22 00:04:48.314 --> 00:04:52.474 Now the same menu on the last row, which is Completed. 23 00:04:53.042 --> 00:05:05.895 Edit Audit Details has gone, and so has Edit Tags -- a finished assessment is a record, not a draft. Two items have appeared instead: View Vulnerabilities, and Re-Audit. 24 00:05:06.481 --> 00:05:20.243 Re-Audit starts a fresh assessment of the same endpoints and links it to this one, rather than raising an unrelated audit that happens to have a similar name. That link is what the next item shows you. 25 00:05:20.857 --> 00:05:38.844 View Audit Chain. Two entries: the baseline, and the re-test that followed it. Both completed, both named after the same work, and the chain is what stops the second one being read as an unrelated assessment that happened to find fewer problems. 26 00:05:39.477 --> 00:05:50.502 This is also how you answer "did the fixes work". Not by comparing two numbers, but by opening the confirmatory audit and reading what it re-tested. 27 00:05:51.107 --> 00:05:55.030 View Audit Status History is the audit's own trail. 28 00:05:55.610 --> 00:06:08.195 Six entries for this one, in order: saved, requested, approved, scheduled, work in progress, completed. Each carries who moved it, when, and why. 29 00:06:08.765 --> 00:06:21.517 Read the gaps rather than the entries. If approval took nine days and testing took three, the assessment is not your constraint -- the approval step is, and this is the only screen that shows it. 30 00:06:22.084 --> 00:06:30.856 Manage Test Summary is the tester's account of what was actually covered, which is not the same thing as the scope agreed beforehand. 31 00:06:31.446 --> 00:06:47.465 Sixty-one endpoints exercised twice over, authorisation tested horizontally and vertically, rate limiting held under load. That paragraph is what a reader of the report needs in order to know what the absence of a finding means. 32 00:06:48.043 --> 00:06:59.738 Note that it is read-only here. Once a summary has been written this dialog shows it and will not take a change, so write it when the work is finished rather than while it runs. 33 00:07:00.352 --> 00:07:13.754 And Delete Audit, which is on both menus and should be rare. An assessment raised by mistake is worth removing; one whose findings were disputed is not, because the dispute is part of the record. 34 00:07:14.323 --> 00:07:20.381 The findings screen is where the work lands, and its columns are worth taking one at a time. 35 00:07:20.977 --> 00:07:37.379 Above the table, three things. The assessment report, ready to download in either format. The asset and the audit this list belongs to. And the totals -- twenty findings here, eighteen still open, two closed. 36 00:07:37.991 --> 00:07:43.762 Beside the audit name is the audit chain again, and it is worth opening from here too. 37 00:07:44.360 --> 00:07:55.865 The baseline is complete; the re-test is still in progress. Each entry links straight to its own findings, so comparing the two is one click rather than a search. 38 00:07:56.474 --> 00:08:04.527 Below all of that sit the severity chips, and they do the same job here as the status chips do on the audit list. 39 00:08:05.129 --> 00:08:17.785 Critical two, High four, Medium eight, Low five, Info one -- and they add up to the twenty above them, which is worth checking, because a filter left on is the usual reason they do not. 40 00:08:18.379 --> 00:08:33.126 Vulnerability carries the title, its identifier and the affected endpoint. Tool says which scanner or tester reported it. Risk is the severity, with the C V S S score underneath it. 41 00:08:33.755 --> 00:08:54.023 Then the pair that gets conflated everywhere in this product. Validation asks whether the finding is genuine. Current Status asks where it has reached in its life. They move independently -- a finding can be validated and still open, and an unvalidated finding still counts. 42 00:08:54.630 --> 00:09:03.668 Validation is the auditor's judgement, and it is a control rather than a label. Approved, Closed, or False Positive. 43 00:09:04.270 --> 00:09:21.969 That matters more here than in most modules, because authorisation findings are frequently disputed. Somebody will say the endpoint is protected at the gateway, and False Positive is where that conclusion gets recorded rather than argued again next quarter. 44 00:09:22.587 --> 00:09:33.327 Current Status is the customer's side of the same finding, and it offers a different set entirely: patch in progress, patched, on hold, risk accepted. 45 00:09:33.959 --> 00:09:48.512 Risk accepted is the one to watch. It is a legitimate answer, and it is also where findings go to be forgotten -- which is why the row carries the acceptance date beside it and the S L A column keeps counting regardless. 46 00:09:49.118 --> 00:09:56.136 Artifacts hold the evidence, and for an A P I finding that is the only thing that settles a dispute. 47 00:09:56.740 --> 00:10:10.189 The affected endpoint, and the proof-of-concept steps underneath it: the ordinary request first, then the same request with one thing changed, then a confirmation that does not read any data at all. 48 00:10:10.784 --> 00:10:24.549 Opening the first one gives you what was actually sent, and what came back. A plain search returned three records. The same call with one condition appended returned every row in the table. 49 00:10:25.134 --> 00:10:35.439 This is what you send when somebody says the input is sanitised. Not a severity rating and not a scanner's name -- the requests, and what came back. 50 00:10:36.035 --> 00:10:42.743 The finding row menu is gated the same way the audit menu is, and this time the gate is validation. 51 00:10:43.333 --> 00:10:56.060 On a finding still being validated, the menu is about the finding itself: edit this instance, edit the shared master record behind it, and edit or view its C V S S metrics. 52 00:10:56.651 --> 00:11:09.959 Edit Issue Master Details changes the shared record behind every instance of this weakness, so a correction there improves every report that cites it -- and a careless edit does the same in the other direction. 53 00:11:10.557 --> 00:11:15.391 View C V S S Metrics opens the values behind the score. 54 00:11:15.967 --> 00:11:31.863 Reachable over the network, low complexity, needs a valid account, no user interaction, and a high confidentiality impact with no effect on integrity or availability. Six point five, and now you know why. 55 00:11:32.455 --> 00:11:48.666 Use this before you argue about a rating. Two findings can both be Medium for entirely different reasons -- one reachable by anybody and mildly damaging, the other devastating but only from inside -- and the metrics are where that difference lives. 56 00:11:49.278 --> 00:12:08.873 There are three tabs. Base is the weakness itself. Temporal is what has changed since it was found -- whether a fix exists, whether exploit code is circulating. Environmental is your own estate, which is where a rating stops being generic and starts being yours. 57 00:12:09.461 --> 00:12:16.671 Once a finding is approved that menu changes completely, and what appears instead are the two histories. 58 00:12:17.271 --> 00:12:26.162 View Vulnerability History is the full internal trail, and it follows the weakness across audits rather than only within this one. 59 00:12:26.766 --> 00:12:43.047 Raised critical in the annual review, put on hold, then reopened as high in a later audit and closed there. That is one weakness across two assessments, which is exactly the view you want when somebody asks whether this has come up before. 60 00:12:43.667 --> 00:12:51.983 View Client Status History is narrower, and more useful in an argument: the status as the customer saw it, and when. 61 00:12:52.582 --> 00:13:08.765 This one has been raised and nothing more, which is honest -- it is a new finding. On an older one, this is what you quote when somebody asks what they were told and when, because it records what was communicated rather than what was known internally. 62 00:13:09.372 --> 00:13:21.070 The two are deliberately separate. Internal notes on a disputed finding are not something you want quoted back at you, and the client history is the half that safely can be. 63 00:13:21.674 --> 00:13:29.173 One more control, and it is the one that explains most lists that look wrong. More Filters. 64 00:13:29.763 --> 00:13:44.319 Validation, status, and vulnerability type. Apply closes the drawer and narrows the list; Reset clears the fields but leaves the drawer open, which is worth knowing, because they are not opposites. 65 00:13:44.902 --> 00:13:56.481 The badge on the button counts how many fields are set, and it is the thing to look at when a colleague says a finding has disappeared. Nine times out of ten, it has not. 66 00:13:57.116 --> 00:14:13.925 That is A P I Security. Endpoints assessed in their own right, four classes of finding to look for, two row menus whose contents depend on the state of the thing you are looking at, and a chain that ties a re-test back to the assessment it re-tested. 67 00:14:14.553 --> 00:14:37.922 Three habits. Read the status chips before opening anything -- they tell you where the delay is. When an authorisation finding is disputed, settle it with the artifact and record the outcome in validation, so the same argument is not had twice. And when a re-test is raised, raise it as a re-audit, so the chain says what it was.