Problem: A module of 8,000 lines of code (8 KLOC) is found to contain 24 defects during system testing.

Solution:

\[ \text{Defect Density} = \frac{24}{8} = 3.0 \text{ defects per KLOC} \]

Interpretation: Industry benchmarks for well-reviewed code are typically 1–5 defects per KLOC during system testing. A density of 3.0 is acceptable but suggests that unit-test coverage could be improved. If the same team consistently exceeds 10 defects/KLOC, the review process or requirements clarity needs attention.

Problem: A server application ran for 1,200 hours in a quarter and crashed 4 times, with a total repair time of 8 hours.

Solution:

\[ \text{MTBF} = \frac{1200}{4} = 300 \text{ hours} \]

\[ \text{MTTR} = \frac{8}{4} = 2 \text{ hours} \]

\[ \text{Availability} = \frac{MTBF}{MTBF + MTTR} = \frac{300}{302} \approx 99.34\% \]

Interpretation: 99.34% availability corresponds to roughly 58 minutes of downtime per month. A "three nines" (99.9%) target would require either fewer failures or a faster repair time.

Problem: A team's velocity over the last three sprints was 24, 28 and 26 story points. The remaining product backlog totals 195 points. How many sprints are required, and when is the release?

Solution:

\[ \text{Average Velocity} = \frac{24 + 28 + 26}{3} = \frac{78}{3} = 26 \text{ points/sprint} \]

\[ \text{Sprints Remaining} = \frac{195}{26} = 7.5 \rightarrow 8 \text{ sprints} \]

With two-week sprints, the release is approximately \(8 \times 2 = 16\) weeks away.

Engineering note: always round up and add a buffer of one sprint for integration, hardening and documentation. A more honest estimate is 9 sprints (18 weeks).

Context: A 400-bed hospital requires a system covering patient registration, appointments, billing, pharmacy, lab reports and insurance claims. The project has a fixed 18-month timeline, a fixed budget, and heavy regulatory (medical-records) requirements. The hospital's process is well documented.

Analysis:

• Agile? Attractive for feedback, but the regulatory documentation burden and fixed budget argue against pure Scrum.
• Prototype? Useful for the appointment UI, but not for the whole system.
• Spiral? Justified by the risk in insurance-claim integration, but costly to run for 18 months.
• Incremental + V-Model (hybrid): Deliver in increments — registration first, then appointments, then billing, then pharmacy, then claims. Each increment follows V-Model discipline with test cases written alongside design.

Recommendation: An incremental delivery with V-Model discipline inside each increment. This satisfies the documentation/traceability requirements while allowing the hospital to start using the registration module months before the full system is ready.

Problem: A team must decide whether to build a third-party payment integration in-house or to buy a licensed gateway. Two unsatisfactory outcomes are possible: (i) the in-house build fails late — probability 0.25, loss ₹40,00,000; (ii) the licensed gateway is discontinued — probability 0.10, loss ₹15,00,000.

Solution:

\[ RE_{\text{in-house}} = 0.25 \times 40{,}00{,}000 = ₹10{,}00{,}000 \]

\[ RE_{\text{licensed}} = 0.10 \times 15{,}00{,}000 = ₹1{,}50{,}000 \]

Decision: The licensed gateway has substantially lower risk exposure. The spiral model would direct the team to build a prototype of the in-house option only if the strategic value (data ownership, cost at scale) outweighed the additional ₹8,50,000 of expected risk.

User story format: As a <role>, I want <capability> so that <benefit>.

Story: "As a registered student, I want to reset my password via a one-time link sent to my registered email, so that I can regain access without contacting the administrator."

Acceptance criteria (Given–When–Then):

• Given a registered email, when the student requests a reset, then a one-time link valid for 15 minutes is emailed.
• Given an expired link, when the student clicks it, then an "expired link" page is shown with a re-request option.
• Given a successful reset, when the new password is set, then all existing sessions are invalidated.

Each criterion is directly testable — this is what separates a well-written story from a vague wish.

Project A: A college fest registration website, built by 5 students over 6 weeks, deployed to a shared host weekly.

Recommendation: GitHub Flow. One main branch that is always deployable, short-lived feature branches (feature/registration-form), and a pull request with at least one reviewer before merging. Weekly deploys make release branches unnecessary overhead.

Project B: A desktop accounting package with quarterly versioned releases (v4.1, v4.2) that customers install, and which must be patched for older versions.

Recommendation: Git Flow with release branching. develop accumulates features; a release/4.2 branch is cut for stabilisation and QA; main holds released versions; hotfix/4.1.3 branches patch older supported versions. The multi-version support requirement makes long-lived branches valuable.

# 1. Start from an up-to-date main branch
git switch main
git pull origin main

# 2. Create the feature branch
git switch -c feature/password-reset

# 3. Implement the feature
#    ... edit auth/reset.js, tests/reset.test.js ...

# 4. Review what changed before staging
git status
git diff

# 5. Stage and commit in logical units
git add auth/reset.js
git commit -m "feat: add password reset token generation"

git add tests/reset.test.js
git commit -m "test: cover reset token expiry and reuse"

# 6. Sync with main before opening a PR
git fetch origin
git rebase origin/main          # resolve conflicts now, not at merge time

# 7. Push the branch
git push -u origin feature/password-reset

# 8. Open a Pull Request on GitHub, request one reviewer,
#    wait for CI to pass, then merge (squash or rebase-and-merge)

# 9. Clean up locally
git switch main
git pull origin main
git branch -d feature/password-reset

Why this order matters: rebasing onto the latest main before opening the PR means reviewers see a clean, conflict-free diff, and CI runs against the code as it will actually be merged.

Situation: Two developers modify the same configuration line. On merge, Git cannot decide and inserts conflict markers.

$ git merge feature/timeout
Auto-merging config/settings.py
CONFLICT (content): Merge conflict in config/settings.py
Automatic merge failed; fix conflicts and then commit the result.

Content of the conflicted file:

<<<<<<< HEAD
SESSION_TIMEOUT_SECONDS = 1800
=======
SESSION_TIMEOUT_SECONDS = 3600
>>>>>>> feature/timeout

Resolution steps:

1. Open the file and understand both intentions: the main branch wanted 30 minutes; the feature branch wanted 60 minutes for a security-hardened session policy.
2. Decide the correct value. Suppose the security review concluded 45 minutes is the agreed policy.
3. Replace the entire conflict block with the decided line: SESSION_TIMEOUT_SECONDS = 2700.
4. Remove all marker lines (<<<<<<<, =======, >>>>>>>).
5. Verify nothing else broke: git diff, then run the test suite.
6. Stage and commit: git add config/settings.py then git commit (Git pre-fills the merge message).

Key insight: a merge conflict is not an error. It is Git correctly refusing to guess at a semantic decision that only a human can make.

Situation: A developer runs git reset --hard HEAD~3 intending to undo three local commits, then realises that the second of those commits contained two days of work that was never pushed.

Recovery procedure:

# 1. Inspect where HEAD has been
git reflog
#    a3f9c21 HEAD@{0}: reset: moving to HEAD~3
#    7b2e110 HEAD@{1}: commit: feat: add payment retry logic   <-- the lost work
#    91acd44 HEAD@{2}: commit: feat: integrate Razorpay SDK
#    55f1b02 HEAD@{3}: commit: chore: update dependencies

# 2. Restore the lost commit
git reset --hard 7b2e110

# 3. Verify
git log --oneline -5
git status

Lesson: Git rarely loses committed work. Only uncommitted changes are truly unrecoverable. The reflog is your safety net — and this is precisely why committing frequently in small increments is a defensive practice, not merely a stylistic preference.

Scenario A: A company's file server shows all documents renamed with a .locked extension, and a text file on the desktop demands payment in Bitcoin within 72 hours.

Diagnosis: Ransomware. Immediate response: isolate the server from the network (prevent spread), do not pay, restore from the most recent offline backup, report to the CERT-In, and conduct a root-cause analysis of the initial access vector (likely a phishing email or an exposed RDP port).

Scenario B: A university network slows to a crawl. Log analysis shows thousands of outbound connections from lab machines to an unknown external IP, each sending small packets every few seconds.

Diagnosis: Botnet agent / worm propagation. The lab machines have been recruited into a botnet and are beaconing to a command-and-control server. Immediate response: block the C2 IP at the firewall, isolate affected hosts, run full endpoint scans, patch the vulnerability that allowed initial infection.

Scenario C: A free "PDF converter" downloaded from a third-party site installs silently, adds browser toolbars, and opens a hidden reverse shell to an external host.

Diagnosis: Trojan horse (with adware and backdoor components). Immediate response: remove the software, scan with a reputable anti-malware tool, change any credentials entered while it was installed, and enforce a policy restricting software installation to approved sources.

Requirements: A three-tier application — public web server (10.0.0.5), application server (10.0.1.10) and database (10.0.2.20). Admin access originates from the office subnet 192.168.10.0/24.

# ---- Perimeter firewall (Internet-facing) ----
ALLOW  TCP   any               10.0.0.5   80,443  Public HTTP/HTTPS to web tier
ALLOW  TCP   192.168.10.0/24   10.0.0.5   22      SSH from office only
DENY   TCP   any               10.0.0.5   22      Block SSH from the Internet
DENY   TCP   any               10.0.1.10  any     Web tier must never reach app tier directly
DENY   ANY   any               any        any     Default deny

# ---- Internal firewall (between tiers) ----
ALLOW  TCP   10.0.0.5          10.0.1.10  8080    Web tier → app tier on the app port
ALLOW  TCP   10.0.1.10         10.0.2.20  5432    App tier → PostgreSQL only
DENY   TCP   10.0.0.5          10.0.2.20  any     Web tier must never touch the database
DENY   TCP   192.168.10.0/24   10.0.2.20  5432    No direct admin DB access (use a bastion)
DENY   ANY   any               any        any     Default deny

Reasoning for each design decision:

• The web tier is the only component exposed to the Internet — it is the designated attack surface, kept minimal.
• SSH is restricted to the office subnet; direct Internet SSH is the single most exploited exposure in small deployments.
• The web tier is explicitly prevented from reaching the database, enforcing tier isolation. Even if the web server is compromised, the attacker cannot directly exfiltrate data.
• Administrative database access is routed through a bastion host rather than allowed from the office subnet, providing an auditable choke point.

Roles and permissions:

Separation of duties: the Exam Coordinator can publish results but cannot manage user accounts; the Admin can manage accounts but results publication requires the Coordinator role — no single person can both alter marks and publish them undetected.

PoLP in practice: a Faculty member can edit only the courses they teach, not the entire department's records. If a Faculty account is compromised, the damage is confined to one semester's courses.

Password A: summer2024 — 10 characters from a set of lowercase + digits (\(C = 36\)).

\[ N_A = 36^{10} \approx 3.66 \times 10^{15} \]

At \(R = 10^{10}\) guesses/second (a modern GPU rig):

\[ T_A = \frac{3.66 \times 10^{15}}{2 \times 10^{10}} \approx 183{,}000 \text{ s} \approx 2.1 \text{ days} \]

Password B: Tr0ub4dor&3 — 11 characters from the full set (\(C = 94\)).

\[ N_B = 94^{11} \approx 5.13 \times 10^{21} \]

\[ T_B = \frac{5.13 \times 10^{21}}{2 \times 10^{10}} \approx 2.56 \times 10^{11} \text{ s} \approx 8{,}100 \text{ years} \]

Password C: correct-horse-battery-staple — 28 characters, lowercase + hyphens (\(C = 27\)).

\[ N_C = 27^{28} \approx 1.2 \times 10^{40} \]

Conclusion: Length dominates complexity. Password C is a passphrase — easy for a human to remember, but astronomically harder to brute-force than a short cryptic password. The modern recommendation (NIST SP 800-63B) prioritises length, discourages forced complexity rules and periodic rotation, and mandates screening against known-breached password lists.

Situation: A third-year student receives a notification that someone logged into their university email from an unrecognised city at 3 a.m.

Correct response sequence:

1. Contain: from a different, trusted device, change the email password immediately.
2. Revoke: sign out of all active sessions and remove any unfamiliar recovery email or phone number.
3. Enable: turn on MFA using an authenticator app if it is not already active.
4. Check: review mailbox rules and forwarding settings — attackers commonly add a hidden forwarding rule to keep receiving mail after a password change.
5. Trace: review the login activity log to determine the entry point (a phishing link, a reused password from another breach, or a malicious browser extension).
6. Contain downstream: change the password on any other account that used the same password, starting with banking and social media.
7. Report: inform the university IT/security team so they can check for related compromise on other accounts.
8. Learn: identify the root cause and remove it. If a phishing site captured the credentials, the same site may still be live and targeting classmates.

Preventive reflection: MFA alone would have blocked this. A password manager would have prevented the credential reuse that likely enabled it.

Situation: A final-year CSE student with a strong CGPA (8.6) and two internships is receiving no interview calls despite applying to over forty companies.

Audit findings:

Corrective action plan:

1. Archive or delete the 2019 Instagram posts; set the account to private; audit remaining content.
2. Delete the Twitter account entirely — the reputational cost exceeds any benefit.
3. Restructure GitHub: pin three original projects, each with a proper README (problem, tech stack, screenshots, setup, results).
4. Rewrite the LinkedIn headline: "Final-Year CSE | Python · SQL · AWS | Built 3 deployed web apps | Seeking SDE Internship" and add project entries with repository links.
5. Create a professional email address (firstname.lastname@example.com) and update it across all applications and accounts.
6. Rebuild the portfolio site with six documented projects and test every link.
7. Begin publishing one technical blog post per month to generate positive search results.
8. Set Google Alerts for the full name and re-audit every quarter.

Outcome: Within one recruitment cycle, four interview calls. Lesson: the digital footprint is a screening filter that acts before the interview — and it is entirely within the candidate's control to shape it.

Scenario: During a college tech fest, a student discovers that the registration portal (built by a peer) stores user passwords in plaintext in the database, and that the database is publicly readable at an unauthenticated URL. The student is unsure what to do.

Analysis of options:

Resolution: Notify the developer and supervisor privately, verify only what is visible without authentication (a single screenshot of the error page, no data extraction), and volunteer to implement password hashing and endpoint authorisation. After the fix, write a short internal post-mortem so future fest portals do not repeat the mistake.

Key principle demonstrated: responsible disclosure — demonstrate the minimum necessary, disclose privately, and support remediation.

Definition: Software engineering is the systematic application of engineering principles — process, measurement, documentation and review — to the design, development, testing, deployment and maintenance of software systems.

The software crisis: The term was coined at the 1968 NATO Software Engineering Conference to describe the chronic failure of large software projects. Projects consistently exceeded budgets and schedules, produced unreliable products, and were prohibitively expensive to maintain. The root cause was that project size and complexity grew rapidly while development discipline did not — code was written ad hoc, requirements were undocumented, and testing was an afterthought.

How SDLC processes addressed it:

• Requirements discipline — formal elicitation and specification of what the system must do before coding begins.
• Design before implementation — architecture and interface decisions made deliberately rather than emerging accidentally.
• Verification at every phase — testing is planned and executed systematically rather than deferred.
• Documentation — knowledge is captured in artefacts rather than residing only in developers' heads.
• Measurement — defect density, MTBF, velocity and coverage provide objective quality indicators.
• Change control — modifications are managed through a defined process rather than introduced informally.

Largest maintenance share: Perfective maintenance — approximately 50% of maintenance effort — covering improvements to performance, maintainability and readability without changing external behaviour. Corrective is ~20%, adaptive ~25%, preventive ~5%.

Why this matters: Maintenance consumes 60–70% of a system's total lifetime cost. This makes maintainability a first-class quality attribute: readable code, meaningful names, adequate test coverage, good documentation and modular design all reduce the long-term cost of change. It also justifies Agile practices such as continuous refactoring — paying down technical debt early is far cheaper than paying it during maintenance.

Recommendation for the banking mobile application:

Neither pure Waterfall nor pure Agile fits. The fixed regulatory deadline and the need for auditability argue against a pure Agile approach; the evolving UI requirements argue against pure Waterfall. The recommended approach is a hybrid: Agile delivery inside a Waterfall-governed framework.

Justification:

• Regulatory compliance requires documented requirements, traceability matrices, security testing evidence and formal sign-offs. These are produced as governance artefacts around the Agile process, not as a substitute for it.
• Evolving UI requirements are handled by two-week sprints with a product owner from the bank, allowing continuous feedback on the interface.
• Fixed deadline is managed through release planning: the total scope is split into a mandatory regulatory core (non-negotiable, delivered first) and an optional enhancement set (dropped if time runs short).
• Security testing for a banking app cannot be deferred; automated security scans run in CI on every commit, with a formal penetration test before release.
• Risk is managed through a threat model maintained alongside the backlog, rather than through a full spiral model which would be disproportionately expensive for a mobile application.

Given: Velocities = 22, 26, 25, 27. Remaining backlog = 240 points. Sprint length = 2 weeks.

Average velocity:

\[ \overline{V} = \frac{22 + 26 + 25 + 27}{4} = \frac{100}{4} = 25 \text{ points/sprint} \]

Sprints required:

\[ \text{Sprints} = \frac{240}{25} = 9.6 \rightarrow 10 \text{ sprints} \]

Calendar duration:

\[ 10 \times 2 = 20 \text{ weeks} \]

Why a buffer is necessary:

• Velocity variance: the observed range (22–27) shows a spread of nearly 20%. A bad sprint could reduce output materially.
• Scope growth: in practice, backlog items are refined and new requirements emerge. The backlog rarely shrinks by exactly the estimate.
• Non-feature work: the raw velocity figure excludes integration effort, documentation, hardening, release preparation, and any unplanned production incidents.
• Dependencies and blockers: external API readiness, compliance review cycles and third-party approvals are outside the team's control.
• Historical inaccuracy: story-point estimates are relative and imprecise; systematic underestimation is the norm.

A defensible buffer is 1–2 additional sprints, giving a commitment of 11–12 sprints (22–24 weeks) for external communication, while planning internally for 10. Publishing the buffered figure protects credibility; planning to the unbuffered figure maintains focus.

Why Git stores snapshots rather than differences:

Traditional version control systems store a base version plus a chain of deltas (differences). Reconstructing any version requires replaying every delta from the base — an operation whose cost grows with history depth. Git instead stores a complete snapshot of the project tree at each commit, but achieves efficiency through two mechanisms:

1. Content-addressed storage: a file's content is hashed (SHA-1) and stored once. If the same content appears again, it is referenced rather than duplicated.
2. Deduplication across commits: only files that actually changed get new blob objects. Unchanged files are referenced by the same hash in the new tree.

Benefits this provides:

• Instant branching and switching: a branch is merely a pointer to an existing commit; checkout does not require replaying deltas.
• Fast history traversal: any commit can be inspected in constant time regardless of how far back it is.
• Efficient merging: three-way merge requires the complete trees of the two branches and their common ancestor — all available locally and immediately.
• Cryptographic integrity: because a commit hash depends on the hashes of its tree and parents, the entire history forms a tamper-evident chain. Altering any past commit changes every subsequent hash, making silent history rewriting detectable.
• Complete offline operation: the whole repository, including every version ever committed, exists on every clone.

The three trees of Git:

Data flows: Working Directory → (git add) → Staging Area → (git commit) → Repository. The reverse flow is (git checkout/switch/restore).

The staging area exists to allow selective, coherent commits. If you have fixed a bug and simultaneously begun a new feature, you can stage and commit only the bug fix, leaving the feature work uncommitted — producing a clean, reviewable history.

Complete feature-branch workflow:

# 1. Sync the base branch
git switch main
git pull origin main

# 2. Create the feature branch
git switch -c feature/payment-gateway

# 3. Implement and commit in logical units
#    ... edit src/payment.js, tests/payment.test.js ...
git status
git diff
git add src/payment.js
git commit -m "feat: integrate Razorpay payment SDK"
git add tests/payment.test.js
git commit -m "test: cover payment success and failure paths"

# 4. Keep the branch current with main
git fetch origin
git rebase origin/main
#    resolve any conflicts, then: git add . && git rebase --continue

# 5. Publish and open a pull request
git push -u origin feature/payment-gateway
#    open PR on GitHub, request 1–2 reviewers, wait for CI

# 6. After the PR is merged (squash or rebase-merge)
git switch main
git pull origin main

# 7. Clean up
git branch -d feature/payment-gateway
git push origin --delete feature/payment-gateway

# 8. Verify
git log --oneline --graph -8

Definitions:

• Threat: any potential cause of harm to an asset — e.g. a cybercriminal group, a disgruntled insider, a natural disaster.
• Vulnerability: a weakness that a threat can exploit — e.g. an unpatched server, a weak password policy, a misconfigured S3 bucket.
• Exploit: a technique, tool or piece of code that takes advantage of a vulnerability — e.g. a SQL injection payload, a phishing kit.
• Risk: the likelihood and impact of a threat successfully exploiting a vulnerability.

Risk quantification:

\[ \text{Risk} = \text{Threat} \times \text{Vulnerability} \times \text{Impact} \]

For financial quantification:

\[ \text{SLE} = \text{Asset Value} \times \text{Exposure Factor} \qquad \text{ALE} = \text{SLE} \times \text{ARO} \]

Worked illustration: A database worth ₹50,00,000 has an exposure factor of 0.4 (a breach would destroy 40% of its value). Then SLE = ₹20,00,000. If such an incident is expected twice a year, ARO = 2 and ALE = ₹40,00,000. A security control costing ₹15,00,000 that reduces the ARO to 0.5 would deliver an ALE reduction of ₹30,00,000 — clearly justified.

Classification by generation:

1. Packet Filtering Firewall (1st generation) — inspects source/destination IP, port and protocol against a static ACL.
2. Stateful Inspection Firewall (2nd generation) — maintains a connection state table (NEW, ESTABLISHED, RELATED, INVALID).
3. Application / Proxy Firewall (3rd generation) — terminates and re-creates connections at the application layer, inspecting full payloads.
4. Next-Generation Firewall (NGFW) (4th generation) — deep packet inspection, application awareness, integrated IPS, TLS inspection, user identity awareness and threat intelligence.

Additionally, by deployment: host-based, network-based, cloud-native and virtual appliance firewalls; and Web Application Firewalls (WAFs) specialise in HTTP/HTTPS traffic.

Comparison — Packet Filtering vs Stateful Inspection:

DMZ — concept and topology:

A DMZ is a buffer sub-network that hosts public-facing services between two firewalls:

INTERNET
    │
    ▼
[ External Firewall ]     ← allows only 80/443 inbound to the DMZ
    │
    ▼
   DMZ   (web server, mail relay, reverse proxy, DNS)
    │
    ▼
[ Internal Firewall ]     ← allows DMZ → LAN only on specific ports
    │
    ▼
   LAN   (workstations, application servers, database)

Rule design: Internet → DMZ on ports 80/443 only; DMZ → LAN denied by default, with narrow exceptions (e.g. the web server may query the internal database on port 5432 only); LAN → Internet permitted with inspection.

Security benefit: if the web server in the DMZ is fully compromised, the attacker still faces the internal firewall and cannot freely reach internal systems. A total breach is thereby converted into a contained incident. The DMZ also concentrates the attack surface into a designated, heavily monitored zone rather than exposing internal servers directly.

Principle of Least Privilege (PoLP): Every user, program or process should be granted only the minimum privileges necessary to perform its intended function, and only for the minimum time required.

Four practical implementation methods:

1. Separate administrative and daily-use accounts. Each administrator holds two accounts: a standard account for email and browsing, and a privileged account used only for administrative tasks. Malware executed while browsing cannot inherit administrative rights, because the compromised account does not possess them.
2. Just-in-time elevation. Instead of logging in permanently as root or Administrator, users elevate on demand with sudo or a privileged access management (PAM) tool, with the elevation time-limited and fully logged. This shrinks the window during which privileged credentials are exposed.
3. Scoped service accounts. A database service account should have read/write access to its own data directory and nothing else — not to the entire filesystem, not to the application source code, and not to other databases. Similarly, a web server process should run as a dedicated low-privilege user such as www-data.
4. Regular access reviews with prompt revocation. Conduct quarterly attestation in which each manager confirms that their team members still require their current access. Revoke access immediately on role change or termination. Stale accounts belonging to departed employees are among the most commonly exploited entry points.

Two additional supporting practices: no shared accounts (every account maps to one person, preserving accountability) and role-based provisioning (access derives from the role, not from individual negotiation).

Comparison of DAC, MAC and RBAC:

Practical observation: most real systems combine models. A Linux server might use DAC for ordinary file permissions, MAC (SELinux) for confinement of network-facing daemons, and RBAC at the application layer for business functions.

Given: Guessing rate \(R = 10^{11}\) guesses per second. Expected time \(T = N / (2R)\).

Part (a): 8-character lowercase-only password

Character set \(C = 26\) (lowercase letters only), length \(L = 8\).

\[ N_a = 26^{8} = 208{,}827{,}064{,}576 \approx 2.09 \times 10^{11} \]

\[ T_a = \frac{2.09 \times 10^{11}}{2 \times 10^{11}} \approx 1.04 \text{ seconds} \]

Part (b): 14-character password from a 94-character set

Character set \(C = 94\) (upper, lower, digits, symbols), length \(L = 14\).

\[ N_b = 94^{14} \approx 4.21 \times 10^{27} \]

\[ T_b = \frac{4.21 \times 10^{27}}{2 \times 10^{11}} \approx 2.10 \times 10^{16} \text{ seconds} \]

Converting to years: \(2.10 \times 10^{16} / (3.15 \times 10^{7}) \approx 6.7 \times 10^{8}\) years — approximately 670 million years.

Comparison summary:

Implications for password policy:

• Length dominates complexity. Increasing length from 8 to 14 multiplies the search space by roughly \(10^{16}\), whereas adding symbols to a short password produces a far smaller gain. Modern policy (NIST SP 800-63B) therefore emphasises minimum length of 8–12 characters and encourages long passphrases over forced symbol substitution.
• Eight-character lowercase passwords are effectively worthless against modern hardware — they fall in about one second. Any system still permitting them is not providing meaningful authentication.
• Dictionary and rule-based attacks change the calculus. The search space assumes truly random characters. Human-chosen passwords follow predictable patterns (Password1!, Summer2024), so effective entropy is far lower than the formula suggests. This is why breach-list screening is essential.
• Rate limiting and account lockout remain necessary. Even a strong password can be attacked online at 1,000 attempts per minute if the system allows unlimited tries. Server-side throttling, exponential backoff and CAPTCHA are independent controls that complement password strength.
• MFA is the decisive control. Since no password is immune to phishing or database breaches, MFA ensures that possession of the password alone is insufficient to gain access.
• Password managers make long unique passwords practical. Since humans cannot memorise 100 distinct 14-character strings, a manager is the enabling technology for the policy that the mathematics demands.

Six-step digital footprint management strategy:

1. Audit. Search your own name across multiple search engines (Google, Bing, DuckDuckGo) using exact-match quotation marks and image search. Review old posts, comments and tagged photographs. Check breach-monitoring services.
2. Prune. Delete outdated, offensive or overly personal content. Deactivate unused accounts. Remove tags where possible. Where deletion is impossible, publish newer positive content to displace old material in search rankings.
3. Lock down. Set social profiles to private. Disable location tagging in camera settings. Review and revoke third-party application access. Turn off ad personalisation and tracking where the platform allows.
4. Separate. Maintain distinct professional and personal identities. Use one email address for professional correspondence and another for social sign-ups. Keep professional profiles (LinkedIn, GitHub) consistently polished and current.
5. Monitor. Set Google Alerts for your name. Review account activity logs periodically. Re-check privacy settings after major platform updates, which frequently reset defaults to more permissive values.
6. Build positively. Publish technical blogs, contribute to open source, maintain a project portfolio and engage in professional communities. A strong positive footprint becomes a genuine career asset rather than merely an offset against negative content.

Why deletion alone is insufficient:

• Caching: search engines and content delivery networks retain cached copies for days, weeks or longer after the original is removed.
• Web archives: services such as the Wayback Machine and Google Cache may have captured the page permanently.
• Screenshots: any viewer may have captured and redistributed the content; these copies are entirely outside your control.
• Third-party re-publication: content may have been copied to aggregator sites, forums or scrapers that never remove it.
• Passive data retention: the passive footprint held by advertisers and data brokers cannot be deleted by the user at all, because the user has no direct relationship with those parties.
• Search index lag: even after deletion, the search result may persist until the index refreshes and the crawler confirms the removal.

The practical conclusion is that prevention is substantially more effective than cleanup — hence the value of the "front page test" before publishing anything.

Definition: Cyber ethics is the study of moral, legal and social issues arising from the use of computers, networks and digital information. It establishes standards of responsible behaviour in cyberspace, covering areas where legislation is absent, ambiguous or lagging behind technological change.

Six major cyber ethics issues:

Key sections of the IT Act, 2000 (as amended) relevant to the offences named:

Critical point for students: Section 43 imposes civil liability for unauthorised access even in the absence of theft or damage. Section 66 elevates this to a criminal offence when the access is dishonest or fraudulent. There is no exemption for "curiosity", "educational purposes" or "I was only testing". Written authorisation with a defined scope is what distinguishes legitimate security research from a criminal act.

Complementary framework: the Digital Personal Data Protection Act, 2023 establishes consent-based processing requirements, obligations on data fiduciaries, and rights for data principals including access, correction, erasure and grievance redressal — filling the privacy gap that the IT Act only partially addressed.