How Security Consulting Works

5.1 · The service lines

A security consultancy sells a handful of distinct services. Freshers often blur them together, but each has a different aim and a different output. Knowing which one you are doing tells you what "finished" looks like.

Four kinds of work

The difference is real and worth feeling. A penetration test is allowed to actually break in and prove impact — its output is "here is what an attacker could do." A config review or VACA does not break in; it compares settings to a standard and its output is "here is where you differ from the baseline." Notice how much Modules 2 and 4 already fed this: the config review reads exactly the device and database configs you learned to recognise.

The service menu

Those four words describe the kind of work. What a client actually buys is a named service, and a consultancy of any size sells a dozen of them. You will not touch most of these in your first year — but you will hear all of them in your first month, in meetings, on timesheets and in job adverts, so meet them now:

Two honest observations about that list. First, nobody does all of it — consultants specialise, and most people build depth in two or three lines before widening. Second, the mix is not even: in Indian BFSI work, network VAPT, web and API testing, and configuration and firewall reviews carry the bulk of the billable days, which is precisely why this training starts there.

Where this course is taking you

Set against that menu, it should be clear what you are doing here and what comes next:

The Beginner course takes the three highest-volume lines — network VAPT, VACA and web VAPT — and teaches each hands-on until you can run it. Intermediate adds API, mobile and thick-client work. Everything else on that menu is real, sellable work you may well end up doing, and none of it is a mystery once the first three are solid; the techniques rhyme.

5.2 · Testing to a framework — the OWASP Top 10 family

Here is a question every fresher gets wrong at first: when you sit down to test an application, where does your list of things to try come from? Not from inspiration. A professional test is measured against a published framework — an agreed list of what must be checked — so that your coverage can be stated, compared and defended.

That is what a client means by "did you cover the OWASP Top 10?" They are not asking whether you are clever. They are asking whether your work can be mapped to a standard they already trust.

OWASP — the Open Worldwide Application Security Project — is a non-profit that publishes exactly these lists, free, and the industry has settled on them. There is not one Top 10; there is a family, one per kind of application:

Alongside the Top 10 lists sit the deeper testing guides, which are what an experienced tester actually works through: the WSTG (Web Security Testing Guide) and the MASTG for mobile, plus ASVS and MASVS, which express the same ground as requirements to be verified. A Top 10 tells you the themes; these tell you the tests.

The web list, in one pass

You will see these ten categories on report covers and in job interviews for the rest of your career. Read them once now; the Beginner course teaches most of them hands-on:

The same idea, for every other service

Application testing is not special here. Each service line on the menu has its own reference work, and naming the right one is part of writing a credible report:

The practical upshot for your first engagement is small and concrete. Your report will carry a methodology line naming the framework you followed, and each finding will be tagged with the category it belongs to. That tagging is not paperwork for its own sake — it is how a client with four reports from four vendors can tell whether anyone actually looked at the same things.

5.3 · Scope, rules of engagement and authorisation

This section carries the single most important rule in the whole profession: you only test what you are authorised to test. Security testing without permission is not clever — it is a crime, in India and everywhere else. What makes your testing lawful is the client's written authorisation, nothing less.

Three terms define the boundary of every engagement:

• Scope — the exact list of what you may test: which applications, which IP ranges or subnets, which accounts. Anything not on the list is off-limits, full stop.
• Rules of engagement (RoE) — the how and when: permitted testing hours, techniques you may or may not use (for example, "no denial-of-service"), and who to contact if something breaks.
• Authorisation — the signed document from someone empowered to grant it, saying "yes, test this." This is your legal cover. Without it, do not touch anything.

This is why Module 2's CIDR lesson mattered so much. If your scope says 10.10.20.0/24, you test those 256 addresses and not one more. Straying outside scope — even out of pure curiosity — can breach the contract and the law. The professional instinct to build now is simple: when in doubt, stop and ask the lead. Nobody is ever punished for confirming scope; people are dismissed for exceeding it.

5.4 · The deliverable is the report

Here is a truth that surprises many newcomers: the client does not pay for the hacking — they pay for the report. Breaking in is the means; the written report is the product you actually hand over. A brilliant finding that is badly explained is a poor deliverable, and a clear report of a moderate finding is a good one.

A good finding, written up, has a few standard parts:

• Title and severity — a clear name and how serious it is (Critical, High, Medium, Low).
• Description — what the weakness is, in language the client can act on.
• Evidence — proof it is real: the request you sent, the response, and screenshots. In practice, clear screenshots of your tool showing the flaw are the heart of the evidence — at SESMO the working standard is that a web finding is demonstrated through the browser and Burp, and the screenshot is the deliverable.
• Impact — what an attacker could actually do with it (steal data, take over an account, move money).
• Remediation — how to fix it.

So from your very first practice lab, build the habit of capturing evidence as you go — the screenshot at the exact moment of proof, the payload you used, the response you got. A finding you cannot evidence is a finding you cannot report, and therefore, to the client, a finding that did not happen.

5.5 · The risk vocabulary

Security people throw around a few words as if everyone already knows them. Here they are, plainly.

The CIA triad

The CIA triad is the three-word summary of what security protects. Almost any attack harms one of these three:

Confidentiality — only the right people can read the data. Integrity — the data is not secretly changed. Availability — the system is up and usable when needed.

Threat, vulnerability, risk

These three are not synonyms, and mixing them up marks you as green:

• A vulnerability is a weakness — an unlocked window.
• A threat is who or what might exploit it — a burglar.
• Risk is the chance and cost of it actually happening — roughly likelihood × impact. An unlocked window on the tenth floor is a small risk; the same window at street level is a large one.

CVSS

To score how bad a vulnerability is, the industry uses CVSS (Common Vulnerability Scoring System) — a number from 0 to 10 that maps to Low, Medium, High or Critical. When a report calls something "a CVSS 9.8," it is telling you this is near the top of the scale — treat it as urgent. You will learn to reason about these scores later; for now, recognise the term and its 0–10 range.

5.6 · The rulebooks — compliance frameworks

Clients, especially banks and financial firms, are held to external compliance frameworks — published rulebooks of security controls they must follow. A large part of consulting is checking systems against these. You will not memorise the controls yet, but you must recognise the names and who they serve, particularly in the Indian BFSI (Banking, Financial Services and Insurance) world you are most likely to work in.

Two of these carry hard reporting clocks worth remembering: an RBI-regulated entity may have to report an incident within about 6 hours, and CERT-In requires reporting certain incidents within 72 hours. These are not trivia — a bank facing a ₹-crore fine for missing a reporting deadline is exactly why it hired your firm. When a client says "we need this for our RBI audit," you now know which world you are standing in.

5.7 · Tools, the blue team, and the vulnerability lifecycle

A few last pieces of vocabulary so nothing on your first day sounds foreign.

The toolbelt

You will hear tool names used as shorthand from your first week — "run it through Burp", "check the Nessus output". Nobody expects you to know how to drive them yet. Recognise what each is for, and the conversations stop being opaque:

Burp Suite, since you will meet it first

Nmap is easy to picture: it knocks on ports and tells you which ones answered. Burp deserves a sentence more, because its idea is less obvious and it underpins nearly all web work.

Normally your browser talks straight to the server and you see only the finished page. Burp is an intercepting proxy: you point the browser at it, and every request now stops at your desk on the way out.

That single change is what makes real testing possible, because the limits a page puts on you — a dropdown with three options, a field that only accepts numbers, a button that is hidden — all live in the browser. Once the request is paused in Burp, none of them apply. Three parts of it do most of the work:

• Proxy — catches traffic as it passes, and lets you change a request before it continues.
• Repeater — sends one request over and over with small edits, so you can watch how the server's answer changes. This is where most findings are actually confirmed.
• Intruder — repeats a request automatically across a list of values, for the jobs too repetitive to do by hand.

The Community edition is free and enough to learn on; teams buy the Professional edition for its scanner and speed. One habit to absorb early, because it is the house standard here: a web finding is demonstrated through the browser and Burp, and the screenshot of that request and response is the evidence that goes in the report.

Red team and blue team

Security has two sides. The red team attacks — that is the testing work this course points toward. The blue team defends, often from a SOC (Security Operations Centre), watching alerts through a SIEM (a system that gathers and correlates logs) and running incident response when something goes wrong. Many consultants actually begin their careers on the blue side, so these words will surround you regardless of where you start.

The vulnerability-management lifecycle

Finding a flaw is one step in a loop that organisations run continuously:

Discover weaknesses (scan), rank them by risk (prioritise), fix them — usually by patching, i.e. applying vendor updates — then scan again to confirm the fix held. This loop is exactly what VACA work plugs into, and "patch management" is simply the fixing stage given a name.

Module 5 glossary

VAPT / VACA

Actively test for exploitable flaws / check systems against a secure baseline.

Config review / Audit

Read a device's settings for weaknesses / check process and controls against a framework.

Service lines

The named services a consultancy sells: external/internal network VAPT, web, API, mobile and thick-client testing, wireless, firewall rule review, config review, source code review, cloud, red team, phishing simulation, compliance audit.

OWASP

The non-profit behind the Top 10 lists for web, API, mobile and desktop applications, plus WSTG, MASTG and ASVS.

PTES / NIST SP 800-115 / CIS Benchmarks

The reference methods for network testing / network testing / configuration hardening.

Scope

The exact list of what you may test.

Rules of engagement (RoE)

How and when you may test — techniques, hours, contacts.

Authorisation

The signed permission that makes testing lawful.

The report

The real deliverable: title, severity, description, evidence, impact, remediation.

CIA triad

Confidentiality, Integrity, Availability — what security protects.

Threat / Vulnerability / Risk

Who might attack / the weakness / likelihood × impact.

CVSS

A 0–10 severity score (Low → Critical).

RBI / SEBI / PCI-DSS / ISO 27001 / DPDP / CERT-In

The compliance rulebooks clients are measured against.

Intercepting proxy

A tool such as Burp Suite that sits between browser and server so requests can be paused, read and edited.

Red / Blue team

Attackers / defenders (the SOC, with a SIEM and incident response).

Vuln-management lifecycle

Scan → prioritise → patch → rescan.