Applied Cybersecurity

Applied is where we stop describing computers and start thinking like attackers and defenders. We keep the language human, but we anchor every idea to assets, entry points, and the controls that actually change outcomes.

In simple terms, threat modelling is how I decide what to worry about first. It is not a perfect prediction. It is a structured way to turn "security feels scary" into "these three controls will reduce harm most for this system."

In the real world, a cyber person does not sit around naming movie villains. We sit with engineers, product, and sometimes ops, and we ask annoying questions. Where does data enter, where does it leave, who can change it, and what happens if it is wrong. We then write down the assumptions and test them.

How it fails. Teams either go too broad (a huge diagram nobody reads) or too narrow (only listing SQL injection because it is familiar). Another failure is skipping the human actors. Support staff, vendors, and internal admins are where many realistic attack paths live.

How to do it well. Keep scope small, tie each threat to an entry point, and tie each entry point to a control you can actually implement or measure. Accept trade offs. If a control adds friction, decide where that friction is worth it and where it will be bypassed.

Before you use the tool, the goal is not to produce a pretty canvas. The goal is to spot one or two high leverage failures. When you fill it in, focus on what would actually hurt and what someone could realistically do with the access they have.

After you use the tool, sanity check your output. Do your threats connect to real entry points, or did you drift into generic fear. Also check whether your controls are specific. "Be secure" is not a control. "Require MFA for staff logins and alert on new device sign in" is closer to a control.

Operating systems run services, services open ports, and apps expose inputs. The attack surface grows with every feature and every default left unchanged.

In simple terms: attack surface is everything someone can touch. If they can touch it, they can try to break it, confuse it, or use it in a way you did not plan for.

In the real world, what I actually do is inventory exposure: endpoints, admin panels, file uploads, third party scripts, public buckets, test environments, and forgotten subdomains. Then I ask which of those touches sensitive data or powerful actions. That is where I look first.

How it fails. A feature gets shipped behind a toggle, then the toggle is left on in production. A debug route leaks stack traces. An admin page is "temporary" and ends up indexed by a crawler. A dependency is added and nobody reviews what it loads in the browser.

How to do it well. Reduce what is exposed, secure what must be exposed, and make sure every exposed input has validation, authentication where appropriate, and monitoring. The trade off is speed. More exposure makes development easier until the day it makes incident response harder.

Before you use the tool, treat each toggle as a real decision. When you turn something on, ask two questions. What new input did I create, and what new assumption did I just make.

After you use the tool, look for the "quiet" exposure. A lot of damage comes from boring things like default ports, metadata, admin routes, and third party scripts. The common mistake is focusing only on big obvious inputs and missing the small ones that are easiest to probe.

A session is a bridge in a stateless world. Cookies or tokens are just carriers. Their safety depends on creation, storage, expiry, rotation and server side checks.

In simple terms, a session is the site remembering you between clicks. Without it, every request looks like a stranger. With it, every request is trusted as "you", which is powerful and therefore risky.

In the real world, what I see is not magic crypto. I see teams choosing between cookies and tokens, setting expiries, deciding how logout works, and then finding out that one missing authorisation check exposed data. I also see incidents where a stolen session gets reused from a different device, and nobody notices because there is no monitoring on session anomalies.

How to do it well. Use secure and HttpOnly cookies where possible, set short lifetimes for high risk sessions, rotate tokens on sensitive events, and invalidate server side on logout. Also treat authorisation as a rule that must be enforced on every request, not just in the UI. The trade off is user convenience. Short sessions can annoy users, so you need to decide where you accept friction and where you compensate with better UX.

Before you use the session flow tool, focus on what is stored where. The browser will happily send cookies back to the server. The question is whether the server should believe them, and under what conditions.

After you use it, check you can explain where the trust comes from. If your model is "the cookie proves it is me forever," you are missing expiry, rotation, and invalidation.

Before you use the hijack demo: this is not teaching you to attack anyone. It is showing why session identifiers are sensitive. If someone gets one, they often do not need your password.

After you use it, focus on the controls that break the replay. Short lifetimes, rotation, binding sessions to device signals, and server side invalidation all reduce the window. A common mistake is assuming HTTPS alone prevents session theft. HTTPS protects transport, not your entire browser environment.

In 2018, British Airways experienced a data breach affecting 500,000 customers. Attackers injected malicious code into the airline's website that stole payment card details. The attack worked because cookies were not properly secured. The ICO fined British Airways £20 million for the breach. The direct cost was significant, but the reputational damage was worse. Customers lost trust, and the incident raised questions about the airline's ability to protect sensitive payment information.

Cookies carry session identifiers and authentication tokens. If they are not configured correctly, attackers can steal sessions, hijack accounts, and access sensitive data. Missing the Secure flag means cookies can be sent over unencrypted HTTP. Missing HttpOnly means JavaScript can access cookies, making XSS attacks more dangerous. Missing SameSite means cookies can be sent in cross-site requests, enabling CSRF attacks.

Use the cookie checker tool to analyse real cookie configurations. See what secure cookies look like versus insecure ones. Understand how missing flags create vulnerabilities. This hands-on practice builds the skills you need to spot cookie security issues in real applications.

I log what I fear: authentication, authorisation, sensitive access, privilege changes, unusual network patterns.

In simple terms, logs are the footprints. Monitoring is deciding which footprints matter. Response is what you do when you see them.

In the real world, this is triage. You see a burst of failed logins, a login from a new country, an API key used at 3am, or a privilege change followed by data export. You decide what to investigate first, and you decide what evidence to preserve.

How it fails: alert fatigue, missing context, and no owner. Teams create rules that fire constantly, then everyone ignores the channel. Or they log everything but cannot search it. Or the person who gets paged has no permission to do anything meaningful.

How to do it well. Start with a few high value signals tied to real harm, tune them, and write a short playbook. Decide your trade offs. More alerts can catch more badness but will also burn people out. A smaller set of reliable signals often beats a thousand noisy ones.

Risk thinking joins likelihood and impact. Controls reduce one or both but add cost and friction. This is why a good risk decision is not "maximum security." It is "enough security for what we are protecting, given constraints."

Before you use the log triage tool, do not try to read every line. Try to spot the pattern and the story. Ask what changed, who did it, and what is the plausible next step for an attacker.

After you use it, check your priorities. A common mistake is chasing the weirdest looking event instead of the highest impact path. Another mistake is ignoring baseline behaviour. "Unusual" only makes sense when you know what normal looks like.

Before you use the risk trade off tool, this is about making trade offs explicit. You are practising how to talk about risk without sounding like a robot or a fortune teller.

After you use it, focus on residual risk. The common mistake is assuming one control takes risk to zero. Another mistake is ignoring cost and usability until users bypass the control. Good controls reduce harm without breaking the business.

Applied learning is only useful if you can verify it. Verification is how you check that a control really works. It is also how you avoid security theatre.

In practice, you verify three things.

1. The control exists where it should exist
2. The control fails safely when something is wrong
3. The control is monitored so failure does not stay hidden

APIs are how systems talk to each other. This makes them powerful. It also makes them a common path for abuse.

When you review an API, focus on these ideas.

1. Authentication and authorisation for each action
2. Rate limits and abuse controls
3. Key scoping and rotation
4. Replay and idempotency for sensitive actions

This capstone is a short design review. Choose one feature you understand. Write down assets, entry points, and what could go wrong. Then choose controls that reduce harm and describe how you would verify them.