Module 1: Applica on Security & Security Tes ng

1.1 Web Applica on Security, SQL Injec on, Forms and Scripts

 Web Applica on Security (WAS):

o Defini on: Web Applica on Security encompasses all strategies, technologies, tools, and prac ces
designed to protect web applica ons, their data, and their users from malicious a acks and
uninten onal vulnerabili es. It's a con nuous process, not a one- me fix.

o Core Goals (CIA Triad in WAS context):

 Confiden ality: Ensuring that sensi ve data (e.g., user creden als, personal iden fiable
informa on (PII), financial details, proprietary business logic) is accessible only to authorized
individuals and processes. Achieved through encryp on, access controls, and secure data
storage.

 Integrity: Maintaining the accuracy, consistency, and trustworthiness of data and applica on
processes. This means preven ng unauthorized modifica on or dele on of data and
ensuring the applica on behaves as intended. Achieved through input valida on, output
encoding, hashing, digital signatures, and transac on controls.

 Availability: Ensuring that the web applica on and its associated data are accessible to
authorized users when they need it. This involves protec ng against Denial of Service (DoS)
a acks, ensuring system up me, and having robust disaster recovery/backup plans.

o Common Web Applica on Threats (OWASP Top 10 is a good reference):

 Injec on (SQLi, NoSQLi, OS Command Injec on, LDAP Injec on)

 Broken Authen ca on

 Sensi ve Data Exposure

 XML External En es (XXE)

 Broken Access Control

 Security Misconfigura on

 Cross-Site Scrip ng (XSS)

 Insecure Deserializa on

 Using Components with Known Vulnerabili es

 Insufficient Logging & Monitoring

o Key Areas of Focus in WAS:

 Secure Development: Wri ng secure code from the start.

 Input Valida on & Output Encoding: Crucial for preven ng injec on a acks.

 Authen ca on & Session Management: Securely verifying users and managing their
sessions.

 Access Control (Authoriza on): Ensuring users can only access what they are permi ed to.

 Cryptography: Protec ng data at rest and in transit.

 Error Handling & Logging: Securely managing errors and logging relevant events.
  Configura on Management: Securely configuring all components (web server, app server,
database, frameworks).

 Vulnerability Management: Regularly tes ng for and remedia ng vulnerabili es.

 SQL Injec on (SQLi):

o Defini on: A severe code injec on vulnerability where an a acker inserts or "injects" malicious SQL
(Structured Query Language) code into an applica on's input fields. This malicious code is then
passed to the backend database and executed, poten ally allowing the a acker to control or
compromise the database.

o How it Works (Detailed Example):

 Imagine a login form where the applica on constructs an SQL query like this:
String query = "SELECT * FROM users WHERE username = '" + userName_input + "' AND
password = '" + password_input + "';";

 If an a acker enters ' OR '1'='1 into the userName_input field and anything (or nothing) in
the password field, the query becomes:
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '...';

 Since '1'='1' is always true, the WHERE clause condi on becomes true for all users,
poten ally logging the a acker in as the first user in the database (o en an admin) or
returning all user data.

o Types of SQLi:

 In-band (Classic) SQLi: A acker uses the same channel to launch a acks and gather results.

 Error-based SQLi: Exploits verbose error messages from the database to reveal its
structure and data.

 Union-based SQLi: Uses the UNION SQL operator to combine the results of a
legi mate query with results from a malicious query injected by the a acker,
exfiltra ng data.

 Inferen al (Blind) SQLi: A acker sends payloads and observes the applica on's behavior
(e.g., response me, boolean differences in pages) to infer informa on about the database,
as no direct data is returned.

 Boolean-based SQLi: Asks the database TRUE/FALSE ques ons and determines the
answer based on the applica on's response.

 Time-based SQLi: Injects queries that cause a me delay if a condi on is true,

allowing the a acker to infer informa on based on the response me.

 Out-of-band SQLi: Uses alterna ve channels (e.g., DNS or HTTP requests to an a acker-
controlled server) to exfiltrate data. Less common, used when direct responses are not
possible.

o Impacts (Elaborated):

 Data The : Accessing and exfiltra ng en re databases (customer PII, credit card numbers,
trade secrets).

 Data Modifica on/Dele on: Altering records, dele ng tables, corrup ng data.

 Authen ca on Bypass: Gaining unauthorized access to the applica on, o en with

administra ve privileges.
  Denial of Service (DoS): Execu ng queries that consume excessive resources or drop tables,
making the database or applica on unavailable.

 Remote Code Execu on (RCE): On some database systems (e.g., xp_cmdshell in MS SQL
Server), SQLi can lead to execu ng OS commands on the database server, poten ally
compromising the en re server and internal network.

o Preven on (Detailed Strategies):

 Parameterized Queries (Prepared Statements): This is the primary and most effec ve
defense. The SQL query structure is pre-compiled by the database. User input is then
supplied as parameters, treated strictly as data, not executable code. The database engine
handles the proper escaping automa cally.

 Example (Java JDBC): PreparedStatement pstmt = conn.prepareStatement("SELECT *

FROM users WHERE username = ? AND password = ?"); pstmt.setString(1,
userName_input); pstmt.setString(2, password_input);

 Input Valida on (Whitelis ng): Before using any input in a query (even with parameterized
queries, as a defense-in-depth measure), validate it against a strict whitelist of expected
characters, formats, and lengths. For example, if an input should be a 5-digit number, reject
anything else.

 Stored Procedures: Can prevent SQLi if implemented correctly (i.e., they don't dynamically
construct SQL from user input within the procedure itself). They can encapsulate database
logic and limit direct SQL exposure.

 Object-Rela onal Mappers (ORMs): Libraries like Hibernate (Java), SQLAlchemy (Python),
En ty Framework (.NET) o en abstract away direct SQL query construc on, reducing the risk
if used according to their security guidelines. However, custom queries within ORMs can s ll
be vulnerable if not careful.

 Principle of Least Privilege: The database account used by the web applica on should have
only the minimum necessary permissions on the database (e.g., SELECT, INSERT, UPDATE on
specific tables, but not DROP TABLE, CREATE USER, or admin rights).

 Web Applica on Firewalls (WAFs): Can detect and block known SQLi pa erns in HTTP
requests. Useful as an addi onal layer but should not be the sole defense, as they can be
bypassed.

 Output Encoding (for display): While not directly preven ng SQLi, if data retrieved via SQLi is
then displayed back to an a acker, proper output encoding can prevent secondary a acks
like XSS.

 Regular Security Audits & Penetra on Tes ng: Proac vely find and fix SQLi vulnerabili es.

 Forms (Web Forms):

o Func on: HTML <form> elements are the primary interface for users to submit data to a web
applica on. This data can include login creden als, registra on details, search queries, comments,
file uploads, etc.

o Security Concerns (Elaborated):

 Injec on Vulnerabili es (SQLi, XSS): If data submi ed through forms is not properly
validated on the server-side and sani zed/encoded before being used in database queries or
displayed back in HTML, forms become a prime vector for these a acks.

 Cross-Site Request Forgery (CSRF): A ackers can cra malicious web pages that cause a
logged-in user's browser to unknowingly submit a form to a vulnerable applica on,
 performing ac ons on behalf of the user (e.g., changing email, transferring funds). Requires
an -CSRF tokens.

 Data Tampering: A ackers can modify form data in transit (if not using HTTPS) or using
browser developer tools to submit unexpected values (e.g., changing the price of an item in
a hidden field). Server-side valida on is key.

 Automated Submissions (Bots): Forms can be targeted by bots for spam, account crea on,
creden al stuffing, etc. CAPTCHAs or other bot detec on mechanisms are used for
mi ga on.

 File Upload Vulnerabili es: Forms allowing file uploads can be risky if not properly restricted
(file type, size, content scanning) as a ackers might upload malware or web shells.

o Security Measures for Forms:

 Server-Side Valida on: Absolutely cri cal. All data submi ed through forms must be
rigorously validated on the server for type, length, format, and business logic rules. Client-
side valida on is for user experience only and can be easily bypassed.

 Output Encoding: When displaying data originally submi ed via forms, encode it
appropriately for the context (HTML encoding, JavaScript encoding) to prevent XSS.

 An -CSRF Tokens: Implement unique, unpredictable tokens in forms to ensure requests

originate from the applica on itself.

 Use HTTPS: To encrypt form data in transit.

 CAPTCHA/Rate Limi ng: To prevent automated abuse.

 Secure File Upload Handling: Validate file types, sizes, scan for malware, store uploads
outside the webroot if possible.

 Scripts (Client-Side & Server-Side):

o Client-Side Scripts (e.g., JavaScript, VBScript (legacy)):

 Execu on Environment: Run within the user's web browser.

 Purpose: Enhance user experience (interac ve elements, dynamic content updates without
page reload via AJAX), perform client-side valida on (for immediate feedback, not security),
manipulate the Document Object Model (DOM).

 Security Risks (Elaborated):

 Cross-Site Scrip ng (XSS): The most significant risk. If an applica on embeds user-
supplied input into its HTML pages without proper output encoding, an a acker can
inject malicious JavaScript. This script then runs in the vic m's browser with the
permissions of the legi mate website, allowing the a acker to:

 Steal session cookies (if not H pOnly).

 Log keystrokes.

 Redirect users to malicious sites.

 Deface websites.

 Perform ac ons on behalf of the user.

 DOM-based XSS: A type of XSS where the vulnerability lies in the client-side code
itself. The malicious payload is executed as a result of modifying the DOM
environment in the vic m's browser.
  Bypass of Client-Side Valida on: A ackers can easily disable or modify client-side
scripts, so server-side valida on is non-nego able.

 Data Exfiltra on: Malicious scripts can send data from the user's browser to an
a acker-controlled server.

 Security Measures: Strict output encoding (context-aware), Content Security Policy (CSP),
input valida on on the server.

o Server-Side Scripts (e.g., PHP, Python (Django/Flask), Ruby on Rails, Node.js, Java (Servlets/JSP),
ASP.NET):

 Execu on Environment: Run on the web server.

 Purpose: Process user input from forms/requests, interact with databases, implement
business logic, generate dynamic HTML content to be sent to the client, manage sessions and
authen ca on.

 Security Risks (Elaborated):

 SQL Injec on: (As detailed above) if scripts construct SQL queries with unsani zed
input.

 Command Injec on (OS Injec on): If scripts use user input to build and execute
opera ng system commands. (e.g., system("ping " + user_input);).

 File Inclusion Vulnerabili es:

 Local File Inclusion (LFI): Allows an a acker to include and execute/view

local files on the server (e.g., /etc/passwd, config files, source code).

 Remote File Inclusion (RFI): Allows an a acker to include and execute a

script from a remote server. More severe but less common now.

 Insecure Authen ca on/Session Management: If scripts handle user login or

session tracking insecurely.

 Path Traversal / Directory Traversal: If scripts use user input to construct file paths,
allowing access to files outside the intended web root directory.

 Security Misconfigura ons: Incorrectly configured server-side frameworks or

components.

 Informa on Leakage: Through verbose error messages or debug informa on le in

scripts.

 Security Measures: Strong input valida on, parameterized queries, secure coding prac ces
for file handling and command execu on, proper error handling, keeping server-side
so ware patched.

1.2 Cookies and Session Management, General A acks, SQL Injec on A acks, Regular Applica on Security,
Running Privileges, Applica on Administra on, Integra on with OS Security

 Cookies and Session Management:

o Cookies:

 Defini on: Small pieces of textual data that a web server sends to a user's web browser. The
browser stores these cookies and sends them back to the same server with subsequent HTTP
requests.
  Purpose: Maintain state in HTTP (session tracking, personaliza on, shopping carts, tracking).

 Key Cookie A ributes for Security:

 H pOnly: Prevents access by client-side scripts (mi gates XSS cookie the ).

 Secure: Transmits cookie only over HTTPS (prevents sniffing).

 SameSite (Strict, Lax, None): Controls cross-origin cookie sending (mi gates CSRF).
None requires Secure.

 Expires / Max-Age: Defines cookie life me. Shorter for sensi ve cookies.

 Domain and Path: Scopes the cookie.

 Security Risks: The (sniffing, XSS), modifica on, fixa on.

o Session Management:

 Defini on: Mechanisms to track user interac ons across mul ple HTTP requests (logins,
mul -step processes).

 Mechanism: Server generates unique Session ID -> sends to client (usually via cookie) ->
client sends Session ID with subsequent requests -> server uses ID to retrieve session data.

 Common Session Management A acks:

 Session Hijacking (Sidejacking): Stealing a valid Session ID to impersonate a user.

 Session Fixa on: Forcing a user to use a Session ID known to the a acker.

 Weak Session IDs: Predictable or easily guessable IDs.

 Session Replay A ack: Reusing a captured session token.

 Secure Session Management Prac ces:

 Use strong, long, random Session IDs (CSPRNG).

 Regenerate Session ID a er login/privilege change (prevents fixa on).

 Transmit Session IDs over HTTPS (Secure cookie flag).

 Use H pOnly cookie flag.

 Implement idle and absolute session meouts.

 Proper server-side logout (invalidate session).

 Avoid storing sensi ve data in session cookies.

 General A acks (relevant to applica ons):

o Denial of Service (DoS) / Distributed Denial of Service (DDoS): Overwhelm applica on/system with
traffic/requests to make it unavailable.

o Man-in-the-Middle (MitM): Intercept/alter communica on between two par es. Prevented by

HTTPS/TLS.

o Phishing: Deceiving users into revealing sensi ve info via fake communica ons.

o Malware: Viruses, worms, Trojans, ransomware, spyware. Delivered via various vectors.

o Cross-Site Scrip ng (XSS): Injec ng malicious client-side scripts into web pages viewed by others.
(Covered in 1.1)
 o Cross-Site Request Forgery (CSRF): Tricking a logged-in user's browser into making unintended
requests to a site where they are authen cated. Prevented by an -CSRF tokens, SameSite cookies.

o Directory Traversal (Path Traversal): Accessing files outside web root using ../ sequences. Prevented
by input valida on.

 SQL Injec on A acks: (Reitera on from 1.1, highligh ng its significance).

o Key focus on types (In-band, Inferen al/Blind, Out-of-band) and preven on (Parameterized Queries
as primary defense).

 Regular Applica on Security (Holis c Best Prac ces):

o Secure So ware Development Lifecycle (SSDLC): Integra ng security into all SDLC phases
(requirements, design, implementa on, tes ng, deployment, maintenance).

o Threat Modeling: Proac vely iden fying threats, vulnerabili es, and a ack vectors during design
(e.g., STRIDE).

o Secure Coding Prac ces: Input valida on, output encoding, secure error handling, secure API use, no
hardcoded secrets.

o Principle of Least Privilege (PoLP): Gran ng only minimum necessary permissions.

o Defense in Depth: Layered security controls.

o Regular Security Tes ng: SAST, DAST, IAST, penetra on tes ng.

o Patch Management: Promptly upda ng all components (OS, libraries, applica on code).

o Comprehensive Logging and Monitoring: Recording significant events and ac vely analyzing for
suspicious ac vity.

o Security Configura on Management: Securely configuring all components, changing defaults,

disabling unused features.

o Dependency Management: Tracking and upda ng third-party libraries.

 Running Privileges (Principle of Least Privilege - PoLP):

o Defini on: En es (users, processes, applica ons) should only be granted the minimum permissions
necessary to perform their intended func ons.

o Applica on Context:

 Web/App server processes run as low-privilege users (not root/admin).

 Database accounts used by apps have restricted DB permissions (e.g., only DML on specific
tables, no DDL).

 Applica on components/modules operate with minimal necessary rights.

 Restricted file system access for the applica on.

o Benefits: Reduces a ack surface, limits damage if compromised, improves stability, enhances
accountability.

 Applica on Administra on:

o Defini on: Secure management of applica on's opera onal aspects (configura on, admin accounts,
access controls, monitoring).

o Security Aspects:
  Strong, unique admin creden als; no shared admin accounts.

 Mandatory Mul -Factor Authen ca on (MFA) for admin access.

 Restricted access to admin interfaces (IP whitelis ng, VPN, separate network).

 Separate administra ve interfaces if possible.

 Robust audit logging of all administra ve ac ons.

 Secure applica on configura on (change defaults, disable unused features).

 RBAC for granular administra ve roles.

 Strict session management for admin sessions.

 Integra on with OS Security:

o Defini on: How an applica on leverages and respects underlying OS security mechanisms.

o Leveraging OS Features:

 File System Permissions: Operate within permissions set for the app's user.

 User Account Control (UAC)/Process Privileges: Run under non-privileged accounts.

 OS-Level Logging: Integrate app logs with system logs (Windows Event Log, syslog).

 Sandboxing/Containeriza on: U lize OS/Docker for process isola on.

 Secure API Usage: Use OS APIs (crypto, IPC) securely.

o Avoiding Bypass: Applica ons should not subvert OS security controls.

o Dependency on OS Patching: Applica on security relies on a secure, patched OS.

o Resource Management: Proper management of OS resources (memory, CPU, file handles) to prevent
exhaus on.

1.3 Applica on Updates, Spyware and Adware, Network Access

 Applica on Updates (Patch Management):

o Defini on: The systema c process of iden fying, acquiring, tes ng, and deploying updates (patches)
to so ware, including opera ng systems, applica ons, and firmware. Patches fix security
vulnerabili es, bugs, and may introduce new features.

o Importance for Security:

 Addressing Known Vulnerabili es: This is the primary driver. A ackers ac vely scan for and
exploit known, unpatched vulnerabili es.

 Preven ng Malware Exploita on: Many malware variants (worms, ransomware) rely on
exploi ng unpatched so ware.

 Maintaining Compliance: Many regula ons (PCI DSS, HIPAA) mandate mely patching.

 Ensuring System Stability & Performance: Patches o en include bug fixes that improve
reliability.

o Typical Patch Management Process:

1. Inventory: Maintain an accurate list of all so ware and hardware assets and their current versions.
2. Monitor & Iden fy: Track vendor announcements, vulnerability databases (CVE), security feeds for new
patches.

3. Assess & Priori ze: Evaluate patch cri cality (e.g., CVSS score), applicability, and poten al impact of the
vulnerability. Priori ze based on risk.

4. Acquire & Test: Download the patch and test it thoroughly in a non-produc on environment (staging/QA) to
ensure it doesn't break func onality or cause instability.

5. Schedule & Deploy: Plan the rollout (o en during maintenance windows) and deploy the patch to
produc on systems using automated tools or manual processes. Consider phased rollouts.

6. Verify & Report: Confirm successful installa on on all target systems. Monitor for post-deployment issues.
Maintain deployment records for audi ng.

7. Rollback Plan: Have a procedure to revert a patch if it causes cri cal issues.

o Challenges: Poten al for down me, compa bility issues, resource constraints for tes ng, emergency
patching.

 Spyware:

o Defini on: A type of malicious so ware (malware) that secretly installs itself on a user's device to
gather informa on about the user, their compu ng habits, and their data without their explicit
knowledge or consent. This informa on is then typically transmi ed to an a acker or third party.

o Methods of Opera on & Types:

 Keyloggers: Record every keystroke made by the user (capturing passwords, credit card
numbers, private messages).

 Screen Scrapers/Recorders: Capture screenshots or video of the user's screen.

 Password Stealers: Specifically search for and exfiltrate stored creden als.

 Informa on Stealers (Infostealers): Scan for specific types of files or data (documents,
browsing history, financial informa on).

 Tracking Cookies (Aggressive): While not always malicious, some tracking cookies used for
adver sing can be highly invasive and considered spyware if they collect extensive PII
without consent.

 Banking Trojans: O en incorporate spyware features to steal online banking creden als.

o Infec on Vectors: Bundled with "free" so ware, malicious email a achments, drive-by downloads
from compromised websites, exploi ng so ware vulnerabili es.

o Impact:

 Iden ty The : Stealing PII for fraudulent purposes.

 Financial Loss: Compromising bank accounts, credit card details.

 Privacy Invasion: Exposing private communica ons, browsing habits.

 Corporate Espionage: Stealing sensi ve business informa on.

 System Performance Degrada on: Spyware processes can consume system resources.

o Preven on & Detec on:

 Use reputable an -malware/an -spyware so ware and keep it updated.

  Exercise cau on when downloading so ware, especially freeware/shareware (read EULAs,
check for bundled so ware).

 Keep OS and applica ons patched.

 Use a firewall.

 Be wary of suspicious email a achments and links.

 Monitor system performance and network traffic for anomalies.

 Adware (Adver sing-supported so ware):

o Defini on: So ware designed to automa cally display or download adver sements to a user's
computer, typically in the form of pop-up windows, banners within applica ons, or by redirec ng
browser searches to adver sing websites.

o Mo va on: Primarily to generate revenue for its developer.

o Difference from Spyware: The primary intent of adware is to show ads, whereas spyware aims to
secretly collect informa on. However, the line can blur:

 Some adware may track user browsing habits to serve targeted ads, which can be a privacy
concern.

 Aggressive adware can be highly intrusive and difficult to remove, behaving like malware.

 Some adware may be bundled with spyware components.

o Infec on Vectors: O en bundled with free so ware downloads (users may unknowingly agree to
install it during the setup process), or through browser toolbars/extensions.

o Impact:

 Annoyance and User Frustra on: Due to intrusive pop-ups and ads.

 System Performance Degrada on: Consumes CPU, memory, and network bandwidth.

 Browser Hijacking: May change browser homepage, search engine, or redirect traffic.

 Poten al Privacy Risks: If it tracks browsing habits extensively.

 Exposure to Malicious Content: Some adware can inadvertently (or inten onally) lead users
to malicious websites or download further malware.

o Preven on & Removal:

 Carefully read installa on prompts and EULAs; opt-out of bundled so ware.

 Use ad-blocking browser extensions.

 Download so ware only from reputable sources.

 Use an -malware so ware that also detects and removes adware.

 Regularly check installed programs and browser extensions for unwanted items.

 Network Access (from an Applica on's Perspec ve):

o Defini on: Refers to the controls and configura ons that dictate how an applica on is allowed to
communicate over a network, including what incoming connec ons it can accept and what outgoing
connec ons it can ini ate.

o Controlling Inbound Network Access:

  Firewalls (Host-based & Network-based): The primary mechanism. Firewalls filter network
traffic based on rules (source/des na on IP, port, protocol).

 Applica ons should only expose necessary ports (e.g., a web server typically only
needs TCP ports 80 for HTTP and 443 for HTTPS open to the internet). All other ports
should be blocked by default.

 Network Segmenta on: Isola ng applica ons in different network zones based on their
sensi vity or func on (e.g., DMZ for public-facing web servers, internal zones for databases).

 Access Control Lists (ACLs): Rules on routers and firewalls that explicitly permit or deny
traffic based on defined criteria.

 Binding to Specific Interfaces: Server applica ons can be configured to listen for connec ons
only on specific network interfaces, rather than all available interfaces.

o Controlling Outbound Network Access (Egress Filtering):

 Importance: O en overlooked but crucial. Restric ng an applica on's ability to make

outbound connec ons can prevent:

 Data Exfiltra on: If an applica on is compromised, egress filtering can block it from
sending sensi ve data to an a acker's server.

 Command and Control (C2) Communica on: Malware o en tries to "call home" to
an a acker's C2 server; egress filtering can block this.

 Further A acks: Preven ng a compromised applica on from being used to a ack

other internal or external systems.

 Implementa on: Configuring firewalls to allow outbound connec ons only to known,
legi mate des na ons and ports necessary for the applica on's func on. Deny all other
outbound traffic by default.

o Principle of Least Privilege in Network Access:

 An applica on should only have the network connec vity absolutely required for its
intended opera on. If an applica on doesn't need internet access, it shouldn't have it. If it
only needs to talk to a specific database server, it should only be allowed to connect to that
server on the required database port.

o Security Considera ons for Network Communica ons:

 Encryp on: All sensi ve data transmi ed over the network by the applica on should be
encrypted using strong protocols like TLS/SSL.

 Authen ca on: Applica ons communica ng with each other over a network should
authen cate each other (e.g., using client cer ficates, API keys).

 Secure Network Protocols: Use secure versions of protocols where available (e.g., SFTP
instead of FTP, SSH instead of Telnet).

1.4 Remote Administra on Security, Cybersecurity Essen als

 Remote Administra on Security:

o Defini on: The prac ce of managing and controlling computer systems, network devices, or
applica ons from a loca on physically separate from the target device. This is essen al for IT
opera ons but introduces significant security risks if not properly secured.
 o Common Remote Administra on Methods/Protocols:

 SSH (Secure Shell): Provides encrypted command-line access to servers (primarily

Linux/Unix, but also available for Windows). Replaces insecure Telnet. Uses port 22 by
default.

 RDP (Remote Desktop Protocol): Microso 's proprietary protocol for graphical remote
access to Windows desktops and servers. Uses port 3389 by default.

 VNC (Virtual Network Compu ng): A pla orm-independent graphical desktop sharing
system. Less inherently secure than RDP or SSH if not tunneled over SSH or VPN.

 Web-based Interfaces: Administra on through a web browser (HTTPS is crucial here).

 Proprietary Management Tools: Specific vendor tools for managing their hardware or
so ware (e.g., VMware vSphere Client, Cisco ASDM).

 VPN (Virtual Private Network): Creates a secure, encrypted tunnel for remote access.

o Security Risks Associated with Remote Administra on:

 Unauthorized Access: Weak creden als, brute-force a acks.

 Creden al The : Phishing, malware, man-in-the-middle.

 Man-in-the-Middle (MitM) A acks: Intercep ng unencrypted or weakly encrypted remote

administra on traffic.

 Exploita on of Vulnerabili es in Admin Tools/Protocols: Flaws in SSH, RDP, or web interface

so ware.

 Exposure of Admin Interfaces to the Internet: Publicly accessible admin ports are prime
targets.

o Best Prac ces for Securing Remote Administra on:

 Strong Authen ca on: Complex passwords/passphrases, Mul -Factor Authen ca on (MFA)

is crucial.

 Use Secure Protocols: SSH instead of Telnet, RDP with Network Level Authen ca on (NLA)
and encryp on, HTTPS for web interfaces.

 VPNs: Access remote administra on interfaces only through a VPN.

 IP Whitelis ng: Restrict access to specific, trusted IP addresses.

 Change Default Ports (Security through Obscurity - limited effec veness but can reduce
automated scans).

 Regularly Patch Admin Tools and Systems.

 Disable Unused Remote Administra on Services.

 Principle of Least Privilege: Remote admin accounts should have only necessary
permissions.

 Session Timeouts: Automa cally disconnect inac ve sessions.

 Logging and Monitoring: Monitor remote access a empts and ac vi es.

 Cybersecurity Essen als (Founda onal Concepts):

o These are the core principles and prac ces that underpin effec ve cybersecurity:
o CIA Triad (Confiden ality, Integrity, Availability):

 Confiden ality: Protec ng informa on from unauthorized disclosure. (Achieved via:

Encryp on, Access Control, Data Classifica on).

 Integrity: Ensuring informa on is accurate, complete, and has not been tampered with by
unauthorized par es. (Achieved via: Hashing, Digital Signatures, Version Control, Input
Valida on, Access Control).

 Availability: Ensuring that informa on and systems are accessible to authorized users when
needed. (Achieved via: Redundancy (RAID, clustering), Backups, Disaster Recovery Plans,
DoS/DDoS Protec on, Patch Management).

o Defense in Depth (Layered Security):

 Implemen ng mul ple, overlapping security controls so that if one control fails or is
bypassed, other controls are s ll in place to detect or prevent an a ack.

 Example layers: Perimeter firewalls, network intrusion detec on/preven on systems

(IDS/IPS), host-based firewalls, endpoint detec on and response (EDR), strong
authen ca on, applica on security measures, data encryp on, user training, physical
security.

o Principle of Least Privilege (PoLP): (Already detailed in 1.2) Gran ng only the minimum necessary
permissions for any user, system, or applica on to perform its required tasks.

o Patch Management: (Already detailed in 1.3) Regularly iden fying, tes ng, and applying updates to
so ware and systems to fix vulnerabili es.

o Strong Authen ca on & Authoriza on:

 Authen ca on: Verifying the iden ty of a user or en ty (e.g., passwords, MFA, biometrics).

 Authoriza on (Access Control): Determining what an authen cated user or en ty is allowed

to do or access (e.g., RBAC, ACLs).

o Access Control Models: Frameworks for how access rights are managed (e.g., DAC, MAC, RBAC,
ABAC).

o Security Awareness & Training: Educa ng all users (employees, contractors) about cybersecurity
threats (phishing, social engineering, malware), safe online prac ces, and organiza onal security
policies. Human error is a major factor in breaches.

o Logging & Monitoring:

 Logging: Systema cally recording events that occur in systems and applica ons.

 Monitoring: Ac vely reviewing and analyzing logs and system behavior to detect anomalies,
security incidents, or policy viola ons. O en involves Security Informa on and Event
Management (SIEM) systems.

o Incident Response Plan (IRP): A documented, pre-defined plan outlining the procedures and
responsibili es for effec vely responding to and managing a cybersecurity incident (e.g., data
breach, malware outbreak, DoS a ack). Includes phases like prepara on, iden fica on, containment,
eradica on, recovery, and lessons learned.

o Data Backup & Recovery: Regularly backing up cri cal data and systems, and having tested
procedures to restore them in the event of data loss, corrup on, or system failure (e.g., due to
ransomware, hardware failure, natural disaster).
 o Risk Management: The ongoing process of iden fying cybersecurity risks, assessing their poten al
impact and likelihood, and implemen ng measures to mi gate, transfer, accept, or avoid those risks.

o Secure Configura ons (Hardening): Configuring systems and applica ons to be as secure as possible
by default. This includes changing default creden als, disabling unnecessary services and protocols,
applying security templates, and removing unused so ware.

o Zero Trust Architecture (Conceptual): A security model based on the principle of "never trust, always
verify." It assumes that no user or device, whether inside or outside the network perimeter, should
be trusted by default. Access is granted on a per-session, least-privilege basis a er strict verifica on.

Module 2: Email Security, Mobile security and Cryptography

2.1 Understanding Email Security Concepts, Email Security Procedures

 Understanding Email Security Concepts:

o Defini on: Email security encompasses the technologies, policies, and best prac ces used to protect
email accounts, content, and communica on systems from unauthorized access, loss, compromise,
or disrup on.

o Goal: To ensure the Confiden ality, Integrity, and Availability (CIA) of email communica ons and to
protect users and organiza ons from email-borne threats.

o Key Threats to Email Security:

 Spam: Unsolicited, unwanted bulk email messages.

 Phishing: Decep ve emails trying to trick recipients into revealing sensi ve informa on.

 Spear Phishing: Highly targeted phishing a acks.

 Whaling: Spear phishing targe ng high-profile individuals.

 Malware Delivery: Emails with malicious a achments or links.

 Business Email Compromise (BEC) / CEO Fraud: Impersona ng execu ves to authorize
fraudulent transac ons.

 Data Leakage/Loss Preven on (DLP): Accidental or inten onal transmission of sensi ve

informa on.

 Eavesdropping/Intercep on: Intercep ng unencrypted email content.

 Email Spoofing: Forging the sender address.

 Account Takeover: Gaining unauthorized access to an email account.

o Core Technologies and Protocols for Email Security:

 SMTP (Simple Mail Transfer Protocol): Standard for sending emails. Unencrypted by default.

 POP3/IMAP: Protocols for retrieving emails. Can be secured with TLS/SSL.

 TLS (Transport Layer Security) / SSL: Cryptographic protocols for secure communica on.

 STARTTLS: Upgrades an unencrypted SMTP connec on to encrypted.

 Implicit TLS (SMTPS/POP3S/IMAPS): Dedicated ports for immediate TLS.

 S/MIME (Secure/Mul purpose Internet Mail Extensions): Standard for end-to-end

encryp on and digital signing of emails. Requires X.509 cer ficates.
  PGP (Pre y Good Privacy) / GPG (GNU Privacy Guard): Another system for end-to-end email
encryp on and digital signatures. Uses web of trust or key servers.

 SPF (Sender Policy Framework): DNS record specifying authorized mail servers for a domain
to prevent spoofing.

 DKIM (DomainKeys Iden fied Mail): Adds a digital signature to outgoing emails to verify
origin and integrity. Public key in DNS.

 DMARC (Domain-based Message Authen ca on, Repor ng & Conformance): Policy built
on SPF/DKIM, tells receivers how to handle unauthen cated mail (none, quaran ne, reject)
and provides repor ng.

 Email Filtering Gateways/Appliances: Scan emails for spam, viruses, phishing.

 Data Loss Preven on (DLP) Systems: Scan outgoing emails for sensi ve data.

 Email Security Procedures (Best Prac ces):

o For End-Users:

 Be Vigilant: Scru nize sender addresses, links, a achments.

 Strong Passwords & MFA: For email accounts.

 Avoid Clicking Suspicious Links/Opening A achments.

 Verify Requests: For sensi ve info or ac ons.

 Use End-to-End Encryp on (S/MIME, PGP): For sensi ve emails.

 Report Phishing/Spam.

 Keep Email Client So ware Updated.

 Be Aware of Public Wi-Fi Risks.

o For Organiza ons (Administra ve/Technical Measures):

 Deploy Robust Email Security Gateways.

 Implement and Enforce SPF, DKIM, and DMARC.

 Enforce TLS Encryp on: For server-to-server and client-to-server.

 Provide and Encourage End-to-End Encryp on Op ons.

 Implement Data Loss Preven on (DLP) Solu ons.

 Regular User Training and Awareness Programs & Phishing Simula ons.

 Strong Authen ca on Policies (MFA).

 Mail Server Hardening and Patching.

 Monitor Email Logs.

 Incident Response Plan for email incidents.

2.2 Knowing Mobile Device Security Concepts, Mobile Security Procedures

Knowing Mobile Device Security Concepts:

 o Defini on: Measures taken to protect sensi ve informa on stored on and transmi ed by portable
compu ng devices (smartphones, tablets).

o Key Risk Areas and Threats in the Mobile Environment:

 Device Loss or The : Physical loss leading to data exposure.

 Mobile Malware: Malicious apps (spyware, ransomware, Trojans, adware).

 Insecure Wi-Fi Networks: Connec ng to open/compromised Wi-Fi leading to MitM a acks.

 Phishing, Smishing (SMS Phishing), and Vishing (Voice Phishing).

 Outdated Opera ng Systems and Applica ons: Unpatched vulnerabili es.

 Data Leakage: Through insecure apps, misconfigured cloud sync, user error.

 Weak Authen ca on: No passcode, simple passcodes.

 Jailbreaking (iOS) / Roo ng (Android): Bypassing OS security, increasing vulnerability.

 Insecure Applica on Permissions: Apps reques ng excessive permissions.

 Bring Your Own Device (BYOD) Challenges.

 Bluetooth and NFC Vulnerabili es.

 QR Code A acks (Quishing).

o Core Security Features Built into Mobile Opera ng Systems:

 Device Encryp on (Full Disk Encryp on - FDE).

 Passcodes, PINs, Pa erns, and Biometrics.

 Applica on Sandboxing: Isola ng apps.

 Secure Boot Process.

 App Stores with Ve ng Processes (not foolproof).

 Permissions Model for app access to resources.

 Remote Wipe and Lock Capabili es.

 Regular OS Updates and Security Patches.

 Mobile Security Procedures (Best Prac ces):

o For Individual Users:

 Use Strong Device Authen ca on.

 Enable Device Encryp on.

 Keep OS and Applica ons Updated.

 Download Apps Only from Official App Stores.

 Review App Permissions Carefully.

 Be Cau ous with Public Wi-Fi (Use VPN).

 Enable Remote Lock and Wipe Features.

 Regularly Back Up Your Data.

  Avoid Jailbreaking/Roo ng Unless Expert.

 Be Aware of Phishing, Smishing, Vishing.

 Install Reputable Mobile Security So ware (Op onal but Recommended for Android).

 Disable Unnecessary Services (Bluetooth, NFC, Wi-Fi when not in use).

o For Organiza ons (BYOD/COMD):

 Implement Mobile Device Management (MDM) or Enterprise Mobility Management

(EMM) Solu ons: For policy enforcement, app management, remote wipe/lock,
containeriza on.

 Develop and Enforce a Clear BYOD Policy.

 Mandate VPN Usage for corporate access.

 User Training and Awareness.

 Secure Access to Corporate Resources.

 Network Access Control (NAC).

2.3 Understanding How to Secure iPhone, iPad, Android, and Windows Devices

 Understanding How to Secure iPhone and iPad (iOS/iPadOS):

o Pla orm Strengths: Tight hardware-so ware integra on, strong default encryp on, robust
sandboxing, secure boot, strict App Store review, mely OS updates.

o Key Ac ons for Users:

 Set a Strong Passcode & use Face ID/Touch ID.

 Keep iOS/iPadOS Updated.

 Enable "Find My".

 Use Two-Factor Authen ca on (2FA) for Apple ID.

 Manage App Privacy Se ngs and Permissions carefully.

 Download apps only from the Official App Store.

 Regularly Back Up (iCloud/computer, encrypt computer backups).

 Be cau ous with Wi-Fi Networks (use VPN on public).

 Review Safari Security and Privacy Se ngs.

 Limit Ad Tracking.

 Understanding How to Secure Android Devices:

o Pla orm Considera ons: Open source, device encryp on, sandboxing, Google Play Protect, secure
boot. OS update fragmenta on is a challenge.

o Key Ac ons for Users:

 Set a Strong Screen Lock (PIN, pa ern, password, biometrics).

 Keep Android OS and Security Patches Updated.

 Enable "Find My Device" (Google).

  Ensure Google Play Protect is Ac ve.

 Enable Two-Step Verifica on for Google Account.

 Download apps primarily from Google Play Store; be cau ous with sideloading.

 Disable "Install from Unknown Sources" by default.

 Review App Permissions Carefully.

 Regularly Back Up Your Data.

 Use a VPN on Public Wi-Fi.

 Consider a reputable Mobile Security App.

 Understanding How to Secure Windows Devices (PCs/Tablets):

o Pla orm Features: Windows Security (Microso Defender An virus, Firewall), BitLocker, UAC, Secure
Boot, Windows Hello.

o Key Ac ons for Users:

 Use Strong User Account Passwords or Windows Hello.

 Keep Windows Updated.

 Enable and Configure Windows Security components.

 Enable BitLocker Drive Encryp on. Store recovery key securely.

 Use Standard User Accounts for daily tasks.

 Be cau ous with So ware Downloads and Installa on.

 Regularly Back Up Your Data.

 Secure Your Web Browsers (updates, password manager, extensions).

 Secure your Home Wi-Fi Network.

 Uninstall unnecessary so ware, review privacy se ngs.

2.4 Input Valida on, Authen ca on and Authoriza on

 Input Valida on:

o Defini on: Checking any data received by an applica on to ensure it is well-formed, correct, and safe
before processing.

o Importance: Primary defense against injec on a acks (SQLi, XSS, etc.), buffer overflows, DoS.

o Types/Techniques:

 Syntac c Valida on: Checks format (e.g., email structure).

 Seman c Valida on: Checks meaning/context (e.g., start date < end date).

 Whitelis ng (Allowlis ng): Preferred. Defines what IS allowed.

 Blacklis ng (Denylis ng): Less effec ve. Defines what IS NOT allowed.

 Data Type, Length, Range, Presence Checking.

o Where to Perform:
  Client-Side: For usability, immediate feedback (can be bypassed).

 Server-Side: Essen al for security. Always re-validate on server.

o Best Prac ces: Validate all input sources, assume input is malicious, validate early, use centralized
rou nes.

 Authen ca on:

o Defini on: Verifying the iden ty of a user, process, or device ("Are you who you claim to be?").

o Authen ca on Factors:

 Something you know: Password, PIN.

 Something you have: Token, mobile phone (for OTP).

 Something you are (Biometrics): Fingerprint, face.

o Types: Single-Factor (SFA), Two-Factor (2FA), Mul -Factor (MFA - uses two or more different factors).

o Secure Prac ces:

 Strong password policies.

 Secure password storage (hashing with strong, slow, salted algorithms like Argon2, scrypt,
bcrypt).

 Implement MFA (app-based OTPs or hardware keys preferred over SMS).

 Protect against brute-force (account lockout, rate limi ng, CAPTCHA).

 Secure password reset mechanisms.

 Authoriza on (Access Control):

o Defini on: Determining if an authen cated en ty has permission to access a resource or perform an
ac on ("What are you allowed to do?"). Follows authen ca on.

o Key Principles: Principle of Least Privilege (PoLP), Separa on of Du es.

o Access Control Models:

 Discre onary (DAC): Owner controls access.

 Mandatory (MAC): Central authority controls based on labels.

 Role-Based (RBAC): Permissions assigned to roles, users assigned to roles (common in apps).

 A ribute-Based (ABAC): Access based on a ributes of user, resource, ac on, environment.

o Implementa on: Enforce server-side, deny by default, granular permissions, regular review.

2.5 Cryptography, Session Management

 Cryptography:

o Defini on: Science of secure communica on in the presence of adversaries.

o Core Goals (CIA-N): Confiden ality (encryp on), Integrity (hashing, digital signatures),
Authen ca on (digital signatures, MACs), Non-repudia on (digital signatures).

o Key Concepts/Techniques:

 Encryp on: Plaintext to ciphertext.

  Symmetric Encryp on (Secret-Key): Same key for encryp on/decryp on (e.g., AES).
Fast. Challenge: key distribu on.

 Asymmetric Encryp on (Public-Key): Public key (encrypt/verify) and private key

(decrypt/sign) pair (e.g., RSA, ECC). Slower. Solves key distribu on for symmetric
keys, used for digital signatures.

 Hashing: One-way func on, fixed-size output (hash/digest) (e.g., SHA-256, SHA-3). Used for
integrity, password storage.

 Digital Signatures: Asymmetric crypto to provide authen city, integrity, non-repudia on.
Sender hashes message, encrypts hash with private key.

 Message Authen ca on Codes (MACs): Uses a shared secret key and a message to produce
a MAC tag (e.g., HMAC-SHA256). Provides integrity and authen city.

 Key Management: Secure genera on, storage, distribu on, rota on, revoca on of crypto
keys. Cri cal.

 Digital Cer ficates (X.509): Bind public key to an iden ty, issued by a Cer ficate Authority
(CA). Used in TLS/SSL, S/MIME.

 Public Key Infrastructure (PKI): Framework for managing digital cer ficates.

 Session Management:

o Security Goals: Protect session IDs, ensure session integrity/confiden ality, proper termina on.

o Cryptographic Aspects in Secure Session Management:

 Strong Session IDs: Generated using CSPRNGs (long, unpredictable).

 Protec on in Transit: Use TLS/HTTPS (encrypts session ID in cookie). Secure cookie flag.

 Prevent Client-Side Access: H pOnly cookie flag.

 Token Integrity (e.g., JWTs): Tokens are cryptographically signed (HMAC or RSA) to ensure
integrity and authen city.

 Session ID Regenera on: Invalidate old, generate new session ID upon login/privilege
change.

2.6 Error Handling, Mobile Security Essen als (Combined part of previous syllabus item 1.10, re-labeled "Mobile
Security Essen als" from "How to Secure... Error Handling, Mobile Security Essen als")

 Error Handling (Applica on Security Context):

o Defini on: How an applica on responds to and manages errors.

o Security Implica ons:

 Informa on Leakage: Verbose error messages revealing system details (paths, DB structure,
versions, code snippets) to a ackers.

 Denial of Service: Unhandled excep ons crashing the app.

 Insecure State: Errors leaving app in an inconsistent state.

o Secure Error Handling Prac ces:

 Generic Error Messages for Users: No internal details.

  Detailed Logging (Server-Side): Log full error details on the server for debugging. Protect
these logs.

 Graceful Degrada on: Handle errors without crashing.

 Centralized Error Handling.

 Turn Off Debug Mode in Produc on.

 Mobile Security Essen als (Recap of Core Principles):

o Strong Device Access Control: Passcodes, biometrics.

o Data Protec on: Encryp on (at rest and in transit), secure backups.

o App Security: Official stores, review permissions, keep updated.

o Network Security: Secure Wi-Fi (VPNs on public), avoid untrusted networks.

o OS Integrity: Keep OS updated, avoid jailbreaking/roo ng.

o An -Malware/Security So ware: (More for Android).

o User Awareness: Phishing, smishing, social engineering.

o Remote Security Features: Remote lock, wipe, locate.

o Physical Security: Protect device from loss/the .

o (For Orgs) MDM/EMM: Centralized management and policy enforcement.

Module 3: Applica on Security Tes ng & Security related to Opera ng Systems

3.1 Security Recommenda ons for Windows Opera ng Systems, Mac OS, Studying Web Browser Concepts

 Security Recommenda ons for Windows Opera ng Systems:

o Defini on: Best prac ces and configura ons to enhance Windows OS security.

o Key Recommenda ons:

1. Keep Windows Updated (Windows Update).

2. U lize Windows Security (Microso Defender An virus, Firewall, App & browser control,
Device security).

3. Use Strong User Account Passwords/PINs & Windows Hello.

4. Keep User Account Control (UAC) enabled.

5. Use Standard User Accounts for daily tasks.

6. Enable BitLocker Drive Encryp on. Store recovery key securely.

7. Ensure Secure Boot and UEFI are enabled.

8. Regular Data Backups (File History, etc.).

9. Uninstall unnecessary so ware.

10. Secure web browsing prac ces.

11. Disable unnecessary services (advanced).

12. Monitor Event Logs.

 13. (Enterprises) Use Group Policy, hardening standards, EDR.

 Security Recommenda ons for Mac OS:

o Defini on: Best prac ces and configura ons for macOS security.

o Key Recommenda ons:

1. Keep macOS Updated.

2. Use Strong Login Passwords and Touch ID/Apple Watch Unlock.

3. Enable FileVault full-disk encryp on.

4. Enable and configure the Built-in Firewall.

5. U lize Gatekeeper (restrict app sources) and XProtect (an -malware).

6. Use Standard User Accounts for daily tasks.

7. Regular Data Backups with Time Machine (encrypt backups).

8. Secure web browsing prac ces.

9. Be cau ous with so ware downloads.

10. Review Privacy Se ngs (app access to camera, mic, loca on, etc.).

11. Enable "Find My Mac".

12. Consider a Firmware Password.

13. Keep System Integrity Protec on (SIP) enabled.

14. Regularly check Login Items.

 Studying Web Browser Concepts (Security Focus):

o Core Func on: Renders web content, manages HTTP, cookies, cache.

o Key Browser Security Features:

 Sandboxing: Isola ng browser processes (tabs, extensions).

 Same-Origin Policy (SOP): Restricts interac on between different origins (scheme,

hostname, port).

 Content Security Policy (CSP): HTTP header from server specifying allowed sources for
scripts, styles, etc., to mi gate XSS.

 HTTPS/TLS Support & Visual Indicators: Encrypted connec ons, padlock icon.

 An -Phishing and Malware Protec on (e.g., Google Safe Browsing).

 Cookie Management Controls (block third-party, honor H pOnly, Secure, SameSite).

 Private Browsing Mode (Incognito): Doesn't save local history/cookies for that session.

 Extension/Add-on Security Model: Permissions, official stores.

 Regular Updates.

o Common Browser-Based A acks: XSS, CSRF, Clickjacking, Malicious Extensions.

3.2 Immediate Messaging Security, Child Online Safety

  Immediate Messaging (IM) Security / Secure Instant Messaging:

o Defini on: Protec ng real- me communica on pla orms (text, voice, video, files).

o Threats: Eavesdropping (if not E2EE), account takeover, malware/spam, data leakage, phishing, app
vulnerabili es, metadata collec on.

o Security Measures & Best Prac ces:

 Use apps with strong End-to-End Encryp on (E2EE) (e.g., Signal, WhatsApp). Verify security
codes.

 Strong Account Security (unique password, 2FA).

 Be cau ous with links, files, unknown contacts.

 Manage Privacy Se ngs within the app.

 Keep IM Apps Updated.

 Secure device access (passcode, biometrics).

 Be mindful of backups (cloud backups may not be E2EE by default).

 (For businesses) Use enterprise-grade secure messaging pla orms.

 Child Online Safety (Internet Safety for Children):

o Defini on: Protec ng children from online risks and promo ng safe, responsible internet use.

o Key Risks: Inappropriate content, cyberbullying, online predators/grooming, privacy viola ons
(oversharing PII), malware/scams, sex ng, excessive screen me, misinforma on.

o Strategies for Parents/Guardians & Educators:

 Open Communica on: Talk regularly about online ac vi es and risks.

 Educate: Teach about risks and responsible behavior.

 Set Rules & Boundaries: Screen me, allowed sites/apps .

 Use Parental Control So ware/Tools: Content filters, me limits, ac vity monitoring (use
ethically).

 Teach Cri cal Thinking & Media Literacy.

 Emphasize Privacy & PII Protec on: What not to share.

 Stranger Danger Online.

 Address Cyberbullying: Recognize, report, support.

 Model Good Online Behavior.

 Keep devices in common areas (younger children).

 Stay informed about new apps/trends/risks.

 Encourage repor ng of uncomfortable experiences.

3.3 Introduc on Applica on Security Tes ng, Different Applica on Security Tes ng – SAST, DAST, IAST, MAST,
Cross-Site Scrip ng Issues

 Introduc on to Applica on Security Tes ng (AST):

 o Defini on: Iden fying and remedia ng security vulnerabili es in applica ons throughout their
lifecycle.

o Goal: Make apps resilient, protect data, ensure compliance.

o Why AST? So ware flaws are a leading cause of breaches; early detec on is cheaper. Part of SSDLC.

 Different Applica on Security Tes ng – SAST, DAST, IAST, MAST:

o SAST (Sta c Applica on Security Tes ng) - "White-box":

 Analyzes source code/binaries without execu on. Finds insecure coding pa erns.

 Pros: Early in SDLC, pinpoints code loca on, full code coverage.

 Cons: High false posi ves, no run me/environment issues.

 Tools: Checkmarx, Veracode Sta c, SonarQube.

o DAST (Dynamic Applica on Security Tes ng) - "Black-box":

 Tests running applica on by sending inputs and observing responses. Simulates a acker.

 Pros: Finds run me/environment issues, lower false posi ves, language-agnos c.

 Cons: No code loca on, coverage can be limited, slower.

 Tools: OWASP ZAP, Burp Suite Pro.

o IAST (Interac ve Applica on Security Tes ng) - "Grey-box":

 Uses instrumenta on (agents) in running app to monitor during dynamic tests. Combines
SAST & DAST aspects.

 Pros: Accurate, can ID code line, real- me feedback, be er coverage.

 Cons: Overhead from agents, language-dependent.

 Tools: Contrast Security, Checkmarx IAST.

o MAST (Mobile Applica on Security Tes ng):

 Specific to mobile apps (iOS, Android). Combines sta c, dynamic, forensic analysis.

 Tests: Insecure data storage/communica on, code quality, pla orm vulnerabili es.

 Tools: MobSF, NowSecure.

o Other AST: Manual Penetra on Tes ng, SCA (So ware Composi on Analysis), RASP (Run me
Applica on Self-Protec on - a control, not just test).

 Cross-Site Scrip ng (XSS) Issues:

o Defini on: Injec ng malicious client-side scripts (usually JavaScript) into web pages viewed by other
users. Browser executes script because it trusts the source.

o Impact: Session hijacking, creden al the , defacement, redirec on, phishing.

o Types:

1. Stored XSS (Persistent): Malicious script stored on server (e.g., comment), affects many users.

2. Reflected XSS (Non-Persistent): Script embedded in URL/input, reflected back immediately. User must click
malicious link.

3. DOM-based XSS: Vulnerability in client-side JavaScript; payload modifies DOM, executes.

 o Preven on:

 Output Encoding (Contextual): Primary defense. Encode data before rendering based on
HTML context (body, a ribute, JS, CSS, URL).

 Input Valida on: Defense-in-depth.

 Content Security Policy (CSP): Whitelist allowed script/resource sources.

 H pOnly Cookie A ribute: Protects session cookies from JS access.

 Using Safe JavaScript APIs: Avoid innerHTML with user data; use textContent.

 Modern Web Frameworks with built-in XSS protec on.

 Security Headers (X-XSS-Protec on - deprecated, prefer CSP).

 Regular Security Tes ng.

3.4 Opera ng System Security and Different Tes ng Methods

 Opera ng System (OS) Security:

o Defini on: Measures to protect the OS from threats, ensuring CIA of OS, data, and apps.

o Importance: Founda onal layer; if OS compromised, everything on it is at risk.

o Key OS Security Func ons: Authen ca on, Authoriza on (Access Control), Memory Protec on,
Process Isola on, File System Security, Logging/Audi ng, Crypto Services, Secure Boot, Kernel
Protec on.

o Common OS Threats: Malware, vulnerability exploita on, privilege escala on, DoS, weak creden als,
misconfigura ons, lack of patching.

o OS Hardening Best Prac ces: Patching, strong auth, PoLP, disable unnecessary services/ports,
firewalls, IDS/IPS, logging, AV, full-disk encryp on, secure boot, secure baselines (CIS).

 Different Tes ng Methods (for OS Security):

o 1. Vulnerability Scanning: Automated tools check for known vulnerabili es, missing patches,
common misconfigs (e.g., Nessus, QualysGuard).

o 2. Penetra on Tes ng (OS Level): Ethical hackers simulate a acks to ac vely exploit vulnerabili es.

o 3. Configura on Audi ng/Review (Hardening Review): Compare OS config against security baselines
(e.g., CIS Benchmarks).

o 4. Security Patch Management Audi ng: Verify OS/so ware have latest patches.

o 5. Log Review and Analysis: Examine OS logs for suspicious ac vity (manual or SIEM).

o 6. Compliance Audi ng: Assess OS security against regulatory requirements (PCI DSS, HIPAA).

o 7. Kernel and Driver Security Tes ng (Advanced): In-depth analysis of kernel/drivers (fuzzing, sta c
analysis).

o 8. Host-Based IDS (HIDS) / Endpoint Detec on and Response (EDR) Tes ng: Test effec veness of
endpoint security tools.
Module 4: Embedded Applica on and Cloud Security

4.1 Embedded Applica ons Security, Security of Embedded Applica ons Security Conclusions

 Embedded Applica ons Security:

o Embedded Systems: Specialized compu ng systems for dedicated func ons, o en resource-
constrained (IoT, ICS, medical, automo ve).

o Embedded Applica ons: So ware on these systems.

o Embedded Applica ons Security: Protec ng these systems/apps.

o Unique Challenges: Resource constraints, long lifecycles/difficult patching, physical accessibility,

network connec vity risks, RTOS/specialized OS, diverse hardware/so ware, insecure defaults, lack
of security exper se, supply chain risks.

o Common Threats: Weak/default/hardcoded creden als, insecure network services, no secure

update mechanism, insecure data storage/communica on, firmware vulnerabili es, hardware
tampering, DoS.

o Key Security Measures: Secure Boot, firmware signing/verifica on, secure update mechanism (OTA),
PoLP, input valida on, secure communica on (TLS/DTLS), secure storage (encryp on, TPM/SE),
disable unnecessary services, strong auth, hardware-based security, tamper resistance, SSDLC for
embedded, tes ng.

 Security of Embedded Applica ons Security Conclusions:

o Pervasiveness & Cri cality: Compromise has severe consequences.

o Historically Overlooked: Security now gaining priority.

o Unique Constraints Drive Different Approaches.

o Lifecycle Management is Key: Secure design, dev, deploy, maintain (patching).

o Hardware-So ware Co-design for Security.

o Connec vity Amplifies Risk.

o Defense in Depth is Non-Nego able.

o Shi -Le Security (Early in SDLC).

o Regula on and Standards are Evolving.

o Con nuous Effort and Collabora on Needed.

4.2 Remote Administra on Security, Reasons for Remote Administra on

 Remote Administra on Security (Recap):

o Managing systems from a separate loca on. Crucial for IT, but high risk if insecure.

o Protocols: SSH, RDP, VNC, Web (HTTPS), vendor-specific. Avoid Telnet.

o Risks: Weak creden als, brute-force, no MFA, protocol vulnerabili es, unencrypted channels, MitM,
public exposure of ports.

o Best Prac ces: Strong auth (MFA cri cal), secure protocols, PoLP, network segmenta on, VPNs,
firewalls/ACLs, bas on hosts, change defaults (creds & ports), patching, disable unused services,
session management, logging/monitoring, account lockout.
  Reasons for Remote Administra on:

o Convenience & Efficiency (reduces travel, quick response).

o Centralized Management (small team manages many dispersed systems).

o Scalability (for large deployments like IoT).

o Rapid Incident Response.

o Cost Savings.

o Accessibility for Una ended/Remote Systems (e.g., IoT, industrial).

o Automa on & Orchestra on.

o Monitoring & Diagnos cs.

o So ware Updates & Patch Management.

o Disaster Recovery.

o Support for Remote Workforce.

o Management of Cloud Resources.

o Essen al for embedded/IoT due to scale and o en headless nature.

4.3 Remote Administra on Using a Web Interface, Authen ca ng Web Based Remote Administra on

 Remote Administra on Using a Web Interface:

o Defini on: Managing devices/apps via a GUI in a web browser. Device hosts a web server.

o Prevalence: Network devices, consumer electronics (IoT), server management interfaces, web app
admin panels, cloud consoles.

o Advantages: Ubiquitous client (browser), pla orm-independent, user-friendly GUI.

o Security Risks: Suscep ble to web app vulnerabili es (XSS, CSRF, SQLi, auth bypass, session flaws),
HTTP instead of HTTPS, weak defaults, web server vulnerabili es.

 Authen ca ng Web Based Remote Administra on:

o Defini on: Verifying admin iden ty for web admin interface. Cri cal due to privileged access.

o Mechanisms & Best Prac ces:

1. Username/Password: Strong policies, secure server-side storage (salted hashing), HTTPS,

brute-force protec on (lockout, rate limit, CAPTCHA).

2. Mul -Factor Authen ca on (MFA): Highly recommended. OTPs (TOTP from app preferred
over SMS), hardware keys (FIDO U2F/WebAuthn), push no fica ons.

3. Client Cer ficate Authen ca on: Browser presents cert to server. Strong, but complex to
manage.

4. Single Sign-On (SSO) Integra on: (SAML, OIDC) via centralized IdP (Azure AD, Okta).

5. IP Address Whitelis ng: Addi onal layer, not sole auth.

6. Secure Session Management: Strong random session IDs, HTTPS (Secure flag), H pOnly flag,
meouts, proper logout.
 7. Avoid insecure "Remember Me" func onality.

8. Regular audit of auth logs.

o Embedded Device Considera ons: Resource constraints may limit complex auth; default creds are a
major issue.

4.4 Custom Remote Administra on Understanding Cloud Concepts

 Custom Remote Administra on:

o Defini on: Proprietary or specially developed protocols/tools for remote management, not standard
(SSH, RDP, web).

o Why: Specialized needs, resource constraints (embedded), legacy, vendor lock-in, perceived (flawed)
security by obscurity.

o Examples: Proprietary binary protocol for ICS, custom mobile app for IoT, vendor desktop tool for
equipment.

o Security Challenges: Lack of scru ny, security as a erthought, no standard test tools, poor/no
encryp on, weak auth, reverse engineering risk, hard to patch.

o Securing Custom Admin: Strong crypto (TLS/DTLS, standard libraries), robust auth (MFA if possible),
message integrity (MACs), input valida on, secure protocol design, specialized tes ng (fuzzing,
manual pen-test), secure coding, PoLP, logging.

 Understanding Cloud Concepts:

o Defini on (Cloud Compu ng): On-demand network access to shared pool of configurable compu ng
resources (servers, storage, apps, services).

o Essen al Characteris cs (NIST):

1. On-demand Self-service.

2. Broad Network Access.

3. Resource Pooling (mul -tenancy).

4. Rapid Elas city.

5. Measured Service (pay-as-you-go).

o Cloud Service Models:

1. IaaS (Infrastructure as a Service): You manage OS, apps, data. Provider: infra. (e.g., AWS EC2,
Azure VMs).

2. PaaS (Pla orm as a Service): You manage apps, data. Provider: pla orm (OS, run me), infra.
(e.g., Heroku, AWS Beanstalk).

3. SaaS (So ware as a Service): You use app. Provider: app, pla orm, infra. (e.g., Salesforce,
Microso 365).

4. FaaS (Func on as a Service) / Serverless: You provide func ons. Provider: everything else.
(e.g., AWS Lambda).

o Cloud Deployment Models:

1. Public Cloud: Owned by CSP, open to public (AWS, Azure, GCP).

 2. Private Cloud: Exclusive use by one org.

3. Community Cloud: Shared by orgs with common concerns.

4. Hybrid Cloud: Mix of public/private/community, bound together.

4.5 Securing Against Cloud Security Threats, Addressing Cloud Privacy Issues

 Securing Against Cloud Security Threats:

o Shared Responsibility Model: CSP secures "OF the cloud" (infra); Customer secures "IN the cloud"
(data, apps, configs, access). Varies by IaaS/PaaS/SaaS.

o Common Cloud Threats: Data breaches, misconfigura ons, weak iden ty/creden al/key
management, account hijacking, insider threats, insecure APIs, APTs, DoS/DDoS, shared tenancy
vulnerabili es, data loss.

o Cloud Security Best Prac ces:

1. Strong IAM (MFA cri cal, PoLP, secure secrets).

2. Secure Configura ons (CSPM tools, baselines, automa on).

3. Data Security (Encryp on at rest & in transit, DLP, key management).

4. Network Security (VPCs/VNets, security groups/NACLs, WAFs, IDS/IPS).

5. Vulnerability Management (scanning, patching).

6. Logging, Monitoring, Threat Detec on (CloudTrail, GuardDuty, SIEM).

7. Cloud Incident Response Plan.

8. Secure DevOps (DevSecOps) prac ces.

9. Compliance and Governance.

10. Employee Training.

11. Understand and u lize CSP security tools.

 Addressing Cloud Privacy Issues:

o Defini on: Protec ng personal/sensi ve info in the cloud according to laws, expecta ons, policies.

o Key Privacy Concerns: Data loca on/sovereignty (GDPR, CCPA), unauthorized access (by CSP/gov),
mul -tenancy/data segrega on, data control/ownership, compliance with diverse privacy laws, lack
of transparency, vendor lock-in/data portability, data dele on/remanence, third-party sub-
processing.

o Strategies for Addressing Cloud Privacy:

1. Data Classifica on and Governance.

2. Choose Reputable CSPs (strong privacy commitment, cer fica ons like ISO 27018).

3. Understand Contractual Agreements (SLAs, DPAs).

4. Control Data Loca on (use CSP regional op ons).

5. Encryp on & Key Management (CMK, BYOK, HSMs).

6. Strong Access Controls (IAM).

 7. Anonymiza on and Pseudonymiza on.

8. Privacy by Design and by Default.

9. Regular Audits & Privacy Impact Assessments (PIAs).

10. User Consent and Transparency.

11. Data Minimiza on.

12. Secure Data Dele on Prac ces.

13. Data Breach Response Plan (including privacy breach).

4.6 Understanding Various Networking Concepts & Se ng Up a Wireless Network in Windows and Mac

 Understanding Various Networking Concepts:

o IP Addressing: IPv4 (32-bit, e.g., 192.168.1.100), IPv6 (128-bit). Public vs. Private IPs. Subnet Mask,
Default Gateway.

o DNS (Domain Name System): Translates domain names (www.google.com) to IP addresses.

o DHCP (Dynamic Host Configura on Protocol): Automa cally assigns IP addresses & network configs.

o MAC Address: Unique hardware iden fier for NIC (Layer 2).

o Ports: Endpoint for communica on (e.g., HTTP-80, HTTPS-443, SSH-22).

o Protocols: Rules for network communica on.

 TCP: Connec on-oriented, reliable (HTTP, SMTP, FTP).

 UDP: Connec onless, unreliable, faster (DNS, DHCP, streaming).

 HTTP/HTTPS, FTP, SMTP, IMAP/POP3, ICMP.

o LAN/WAN: Local Area Network / Wide Area Network.

o Router: Forwards packets between networks (Layer 3, IP-based).

o Switch: Connects devices in LAN (Layer 2, MAC-based).

o Firewall: Monitors/controls traffic based on rules.

o Wireless Networking (Wi-Fi): Radio waves (IEEE 802.11). SSID (network name), WPA2/WPA3
(security), WEP (insecure).

o OSI Model (7 layers): Physical, Data Link, Network, Transport, Session, Presenta on, Applica on.

o TCP/IP Model (4 layers): Network Interface, Internet, Transport, Applica on.

 Se ng Up a Wireless Network in Windows (Connec ng to Wi-Fi / Crea ng Hotspot):

o Connec ng to Exis ng Wi-Fi: Network icon in tray -> select SSID -> Connect -> enter password.
Choose network profile (Public/Private).

o Se ng up Mobile Hotspot: Se ngs > Network & Internet > Mobile hotspot -> Turn on. Edit Network
name (SSID) & password. PC needs ac ve internet to share.

 Se ng Up a Wireless Network in Mac (macOS) (Connec ng to Wi-Fi / Crea ng Hotspot):

o Connec ng to Exis ng Wi-Fi: Wi-Fi icon in menu bar -> select SSID -> enter password -> Join.
 o Se ng up Internet Sharing: System Se ngs/Preferences > Sharing -> Internet Sharing. Select source
connec on & share via Wi-Fi. Configure Wi-Fi Op ons (Network Name, Security - WPA2/WPA3,
Password). Start sharing. Mac needs ac ve internet to share.

4.7 Understanding Wireless Network Security Countermeasures, Cloud Compu ng and it’s security

 Understanding Wireless Network Security Countermeasures:

o Defini on: Measures to protect Wi-Fi networks from unauthorized access, eavesdropping, a acks.

o Common Threats: Unauthorized access, eavesdropping, MitM, rogue APs, evil twins, DoS,
WPA/WPA2 cracking, MAC spoofing, war driving.

o Key Countermeasures:

1. Strong Encryp on (WPA3/WPA2-AES): WPA3 preferred. Avoid WEP/WPA/TKIP.

2. Strong & Unique PSK (Wi-Fi Password).

3. Change Default Router Admin Creden als.

4. Disable WPS (if vulnerable).

5. Regularly Update Router Firmware.

6. Disable/Restrict Remote Router Management.

7. SSID Management: Change default. Disabling broadcast is weak security.

8. MAC Filtering (Weak security, easily spoofed).

9. Network Segmenta on (Guest Networks).

10. Use Firewalls (host & router).

11. Physical security of AP/router.

12. Limit signal range (if feasible).

13. Client-side security.

14. (Enterprise) WPA2/WPA3-Enterprise (802.1X/RADIUS), WIPS, NAC.

 Cloud Compu ng and its Security (Summary/Re-emphasis):

o Cloud Compu ng Recap: On-demand self-service, broad network access, resource pooling, rapid
elas city, measured service. Service Models (IaaS, PaaS, SaaS, FaaS). Deployment Models (Public,
Private, Hybrid, Community).

o Cloud Security Principles:

1. Shared Responsibility Model is Fundamental.

2. Iden ty and Access Management (IAM) is Paramount (MFA, PoLP).

3. Data Security is Core (Encryp on at rest & in transit, key management, DLP).

4. Secure Network Configura on (VPCs, security groups, WAFs).

5. Visibility and Control Challenges (Need logging, monitoring, CSPM).

6. Configura on Management is Cri cal (IaC security).

7. Compliance and Governance.

 8. Automa on of Security (DevSecOps).

9. Address threats like data breaches, misconfigs, account hijacking.

10. Proac ve security (assessments, pen-tests).

11. Privacy considera ons (data loca on, sovereignty).

12. Vendor Due Diligence.

o Conclusion on Cloud Security: Cloud offers benefits but needs proac ve, well-architected security.
It's an ongoing journey.