Secure Software Application

About this unit

Every app you use, from a school portal to a mobile money service, stores or moves information that someone else may want. This unit teaches you to stop them.

Unit description

This unit covers the competencies required to secure a software application. You will identify the software to be secured, establish tools for application security assessment, perform the assessment, harden the software, monitor how it performs from a security point of view, and prepare reports on software security.

Learning outcomes and how these notes are arranged

1. Identify software to be secured
2. Establish tools for application security assessment, which also covers performing the assessment
3. Harden software application
4. Monitor application security performance
5. Prepare a report on software security
6. Manage data and information

The numbering inside each section (for example 3.5.1) follows the official CDACC outline, so you can match these notes to your syllabus line by line.

How to study with these notes

1. Identify software to be secured

You cannot protect what you do not know you have. The first job of a security technician is to find, name and rank the software in an organisation.

1.1 Meaning of terms

Security has its own vocabulary. Learn these terms first, because every later topic depends on them.

The CIA triad

The whole of information security rests on three goals.

1.2 Types of software

Software is grouped by the job it does. Each group faces different security problems.

1.3 Classification of software and their application

Classifying software helps you decide how much protection it needs. The same software can be classified in several ways at once.

Classification by licence

• Proprietary: source code is closed and owned by a company. You depend on the vendor for fixes.
• Open source: source code is public and can be checked by anyone. It is often reviewed widely, but you must still track updates yourself.
• Freeware and shareware: free to use or free for a trial period. Download only from the official site, because fake copies often carry malware.

Classification by deployment

• Desktop applications run on one computer. Risks include local malware and unpatched versions.
• Web applications run on a server and are used through a browser. They face the widest range of attacks because they are reachable from the internet.
• Mobile applications run on phones. Risks include insecure data storage, weak permissions and reverse engineering.
• Cloud or SaaS applications are run by a provider. You still control users, settings and data, which is the customer's share of security.

Classification by criticality

1.4 Factors influencing software selection

Security should be part of the decision when an organisation chooses software, not something added after installation.

1.5 Identify software that needs security

Almost all software needs some protection, but time and money are limited, so you must decide where to start. Software needs urgent attention when it:

• is reachable from the internet (web servers, APIs, remote access tools),
• stores or processes sensitive data such as personal, medical, financial or exam records,
• supports a critical business function,
• is custom built, because nobody else has tested it,
• is old, unsupported or has known unpatched flaws,
• uses third party libraries and plugins that may hide weaknesses,
• runs with administrator or root privileges.

A simple priority score

Score each application from 1 (low) to 3 (high) on the factors below, then add up. The highest totals are secured first.

1.6 Identify the existing list of installed software

An software inventory is a current list of every application, its version, vendor, install date, owner and the machine it runs on. You can collect it with built in commands or with inventory tools.

Windows

winget list
Get-Package
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | Select DisplayName, DisplayVersion, Publisher

Linux

dpkg -l                 # Debian and Ubuntu
apt list --installed
rpm -qa                 # Red Hat, Fedora, CentOS
snap list
pip list                # Python packages
npm ls -g               # global Node packages

macOS

system_profiler SPApplicationsDataType
brew list

Record the results in a table like this one and keep it updated.

1.7 Check software security updates

Most successful attacks use flaws that already have a fix. Keeping software up to date is the cheapest and most effective security control.

Where to find security information

• The vendor's security advisories and release notes
• The National Vulnerability Database (NVD) and CVE lists
• Advisories from the National KE CIRT/CC and other national response teams
• Operating system update tools: Windows Update, apt, dnf, the Play Store and App Store

Checking for updates by command

winget upgrade                    # Windows: apps with updates
sudo apt update && apt list --upgradable   # Debian and Ubuntu
sudo dnf check-update             # Fedora and Red Hat
pip list --outdated               # Python packages
npm outdated                      # Node packages
npm audit                         # Known vulnerabilities in Node packages

The patch management cycle

1. Identify what is installed and which patches are available.
2. Assess how serious each patch is, using the CVSS score and whether the flaw is already being attacked.
3. Test on a copy of the system so the patch does not break anything.
4. Deploy in a planned window, critical systems first.
5. Verify that the patch installed and the application still works.
6. Document what was done, when, and by whom.

Practice exercises

apt list --installed
sudo apt update
apt list --upgradable

2. Establish tools for application security assessment

A security assessment is a planned, permitted check of an application to find weaknesses before an attacker does. This section covers the tools, the areas you test, and how to run a basic scan.

2.1 Types of tools used in software application security assessment

No single tool finds everything. Testers combine several kinds, each looking at the application from a different side.

Choosing a tool

• What type of application is it: web, mobile, desktop or API?
• Do you have the source code (SAST) or only the running app (DAST)?
• Is the tool free or paid, and is it kept up to date?
• Does it produce clear reports with severity ratings?
• Can it be automated inside your build pipeline?

2.2 Assessing a software application

Whatever the tool, you test the same key areas. The three the outline names are input validation, session management and error handling.

2.2.1 Input validation

Anything that comes from outside the application is untrusted: form fields, URL parameters, cookies, headers, uploaded files and data from other systems. Input validation makes sure that data is of the expected type, length, format and range before it is used.

Validation approaches

• Allow list (whitelist): accept only what is known to be good, for example digits only for a phone number. This is the preferred approach.
• Deny list (blacklist): block known bad characters or words. Attackers often find ways around it, so use only as an extra layer.
• Type, length, range and format checks: age must be a number from 1 to 120, a name must be under 60 letters, an email must match a pattern.
• Server side validation: always required. Client side checks in the browser are only for convenience, since an attacker can skip them.
• Canonicalisation: convert input to one standard form before checking it, so encoded tricks do not slip past.

How to test input validation

1. List every input point: forms, search boxes, URL parameters, headers, file uploads, API fields.
2. Send unexpected data: very long text, special characters like ' " < > ;, negative numbers, empty values.
3. Watch the response for errors, odd behaviour or your input returned unchanged in the page.
4. Try uploading a file with the wrong type or a changed extension.
5. Confirm the server rejects what the browser blocks, using a proxy to change the request.

// Weak: trusts the input
$age = $_GET['age'];

// Better: validate type and range on the server
$age = filter_input(INPUT_GET, 'age', FILTER_VALIDATE_INT, ['options'=>['min_range'=>1,'max_range'=>120]]);
if ($age === false || $age === null) { http_response_code(400); exit('Invalid age'); }

2.2.2 Session management

HTTP does not remember users. A session is how an application remembers that you logged in. After login, the server gives your browser a session identifier, usually stored in a cookie, and checks it on every request. If an attacker steals or guesses that identifier, they become you.

What to check

Set-Cookie: sessionid=9f8a7c2e41d6...; Secure; HttpOnly; SameSite=Strict; Path=/; Max-Age=1800

2.2.3 Error handling

Errors are unavoidable, but what the application shows about them matters. A detailed error message is a gift to an attacker: it can reveal the database type, table names, file paths, software versions and even code.

Assessment checklist for error handling

• Trigger errors on purpose (bad input, missing pages, broken requests) and read what is shown.
• Look for stack traces, debug pages, file paths, database messages and version numbers.
• Confirm custom error pages exist for 400, 403, 404 and 500 responses.
• Check that login errors do not reveal whether the username or the password was wrong. Use one message: Invalid username or password.
• Check the application fails securely: if a check fails or crashes, access is denied, not granted.
• Confirm errors are logged with time, user and request details for investigation.

2.3 Perform a basic scan for a vulnerable application

A basic scan is the first quick look: what is running, what is exposed, and are there known weaknesses. Use a lab target such as DVWA or Juice Shop that you own.

Step one: prepare and get permission

Write down the target address, the tools you will use, the time window, and who approved it. Take a snapshot or backup of the lab machine so you can restore it.

Step two: discover hosts and open ports

nmap -sn 192.168.56.0/24             # which hosts are alive
nmap -sV -p 1-1000 192.168.56.101    # open ports and service versions
nmap -sV --script vuln 192.168.56.101   # run basic vulnerability scripts

The flag -sV asks Nmap to detect the version of each service. You then compare those versions with the CVE list.

Step three: scan the web application

nikto -h http://192.168.56.101/dvwa/        # common web server problems
zap-baseline.py -t http://192.168.56.101/dvwa/   # passive scan with OWASP ZAP

Step four: review and verify results

Scanners produce false positives (reports a flaw that is not real) and false negatives (misses a real flaw). Check each finding by hand before you report it.

2.4 Conduct a security assessment using tools

A full assessment adds deeper testing to the basic scan. A common structure follows the stages below.

1. Planning and scoping. Agree the goals, systems in scope, out of scope items, test times and emergency contacts.
2. Information gathering. Map pages, forms, technologies and user roles. Browse the site through a proxy so it records everything.
3. Threat modelling. Ask what an attacker wants (data, money, disruption) and which features they would target.
4. Automated scanning. Run DAST, port and vulnerability scanners, and SCA if you have the code.
5. Manual testing. Test logins, access control, business logic, file upload and the areas scanners miss.
6. Exploit verification. Confirm serious findings safely, without damaging data.
7. Analysis and rating. Score severity and impact of each confirmed finding.
8. Reporting and retest. Report clearly, then test again after fixes.

Example workflow with OWASP ZAP

1. Start ZAP and set your browser to use it as a proxy.
2. Browse every page of the lab application so ZAP builds a site map.
3. Run the Spider to find more pages, then the Active Scan on the target.
4. Open the Alerts tab and sort by risk level.
5. Select an alert, read the request and response, and confirm it manually.
6. Export the report as HTML for your documentation.

Practice exercises

nmap -sV -p 1-1000 192.168.56.101

3. Harden software application

Hardening means making an application harder to attack by removing what it does not need, fixing what is weak, and adding protection at every layer.

3.1 Introduction to software hardening

A fresh installation is built to be easy to use, not safe. It often has default accounts, sample pages, debug modes, open ports and generous permissions. Software hardening reduces the attack surface so there are fewer ways in.

Why harden

• Fewer entry points for attackers
• Less damage when something does go wrong
• Meets legal and industry requirements
• Protects users' data and the organisation's reputation

Types of hardening

3.2 Basic security principles for software applications

3.3 Software configuration

Many breaches come from misconfiguration, not clever hacking. Secure configuration means setting every option deliberately, using a documented baseline such as the CIS Benchmarks as a guide.

Configuration hardening checklist

# Example: hardening Apache in the configuration file
ServerTokens Prod          # hide detailed version
ServerSignature Off
TraceEnable Off
Options -Indexes           # stop directory listing

# Example: check and lock down a Linux firewall
sudo ufw default deny incoming
sudo ufw allow 443/tcp
sudo ufw enable

3.4 Common threats to applications

The OWASP (Open Worldwide Application Security Project) publishes the Top 10 list of the most serious web application risks. Learn it, because most exam and real world problems come from it.

Other common threats

• Malware: viruses, worms, trojans, ransomware and spyware.
• Phishing and social engineering: tricking people into giving passwords or running malicious files.
• Denial of service (DoS and DDoS): flooding an application so real users cannot reach it.
• Man in the middle: an attacker secretly reads or changes traffic between two parties.
• Brute force and credential stuffing: guessing passwords or trying leaked passwords from other breaches.
• Insider threats: staff who misuse access, deliberately or by mistake.
• Supply chain attacks: attackers compromise a library or update that many apps trust.

3.5 Software vulnerabilities

The following five vulnerability groups are named in the outline. For each you should know what it is, how it works, what damage it does, and how to prevent it.

3.5.1 Injection attacks (SQL injection, command injection)

Injection happens when an application mixes untrusted data with a command or query, so the interpreter cannot tell where the data ends and the instruction begins.

SQL injection example

// Vulnerable code: builds the query by joining text
$sql = "SELECT * FROM users WHERE name='" . $_POST['name'] . "' AND pass='" . $_POST['pass'] . "'";

// If the attacker enters   ' OR '1'='1   the query becomes:
SELECT * FROM users WHERE name='' OR '1'='1' AND pass='' OR '1'='1'
// The condition is always true, so every row is returned.

Types of SQL injection

• In band: results appear directly in the page (error based or union based).
• Blind: no data is shown, so the attacker learns from true or false behaviour or from time delays.
• Out of band: data is sent to a server the attacker controls.

Prevention

// Parameterised query (prepared statement) with PDO in PHP
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = :name");
$stmt->execute([':name' => $name]);

# Python with a placeholder
cursor.execute("SELECT * FROM users WHERE name = %s", (name,))

• Use parameterised queries or an ORM. This keeps data and code apart and is the main defence.
• Validate input with allow lists.
• Give the database account only the rights it needs.
• Do not show database errors to users.
• Use a web application firewall as an extra layer, not as the only defence.

Command injection

Here the application passes user input to the operating system shell. An attacker adds extra commands using characters such as ;, && or |.

// Vulnerable: the user supplies a host name to ping
system("ping -c 4 " . $_GET['host']);
// Input   8.8.8.8; cat /etc/passwd   runs a second command

# Safer in Python: no shell, arguments passed as a list, input checked first
import ipaddress, subprocess
ip = str(ipaddress.ip_address(host))
subprocess.run(["ping", "-c", "4", ip], check=True)

Prevention: avoid calling the shell at all, use built in library functions, pass arguments as a list, validate against an allow list, and run the application with low privileges.

3.5.2 Broken authentication and session management

Authentication proves who you are. When it is weak, attackers log in as someone else, often an administrator.

Common weaknesses

• Weak or default passwords such as admin and 123456
• No limit on failed logins, allowing brute force and credential stuffing
• Passwords stored in plain text or with fast, weak hashes
• Session IDs that are predictable, exposed in the URL, or never expire
• Weak password reset, such as easy security questions
• No multi factor authentication for sensitive accounts

Prevention

• Enforce long passwords (length matters more than odd symbols) and check them against lists of known leaked passwords.
• Store passwords using a slow, salted hash such as bcrypt, scrypt or Argon2. Never store them in plain text.
• Add multi factor authentication (something you know, have, and are).
• Lock or slow down accounts after repeated failures and send an alert.
• Use secure session handling from section 2.2.2: random IDs, cookie flags, timeouts and proper logout.
• Use the same generic message for all login failures.

# Bad: plain text or a fast hash
password = "amos123"
md5("amos123")

# Good: a slow salted hash
import bcrypt
hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))
bcrypt.checkpw(password.encode(), hashed)

3.5.3 Cross site scripting (XSS)

XSS occurs when an application includes untrusted input in a web page without proper handling, so the attacker's script runs in the victim's browser as if it came from the trusted site.

Impact: stolen session cookies, fake login forms, page defacement, redirection to harmful sites, and actions performed as the victim.

<!-- Vulnerable: prints the input directly -->
<p>Hello <?php echo $_GET['name']; ?></p>
<!-- If name is a script tag, the browser runs it -->

<!-- Safe: encode output for HTML -->
<p>Hello <?php echo htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8'); ?></p>

// In JavaScript, use textContent instead of innerHTML
element.textContent = userInput;

Prevention

• Output encoding for the place where data is used: HTML, attribute, JavaScript, URL.
• Validate input with allow lists.
• Use frameworks that escape output automatically, such as React, Angular and template engines with auto escaping.
• Add a Content Security Policy header to limit which scripts may run.
• Set the HttpOnly flag on cookies so scripts cannot read them.
• Sanitise any HTML you must accept, using a trusted library such as DOMPurify.

3.5.4 Insecure deserialization

Serialization turns an object into text or bytes so it can be stored or sent. Deserialization rebuilds the object. If the data comes from an untrusted source and the application rebuilds it blindly, an attacker can change objects or make the application run their code.

Example situations

• A cookie holds a serialised user object with a field role=user. The attacker edits it to role=admin.
• A Python application uses pickle to load data from users. Pickle can execute code while loading.
• Java or PHP objects with dangerous methods are triggered during loading.

# Dangerous: pickle on data from the user
import pickle
data = pickle.loads(request.cookies["profile"])

# Safer: use a plain data format and validate it
import json
data = json.loads(request.cookies["profile"])
if not isinstance(data.get("name"), str) or len(data["name"]) > 60:
    abort(400)

Prevention

• Do not deserialise data from untrusted sources. Prefer simple formats such as JSON.
• Sign the data with a secret key (HMAC) and verify the signature before use, so tampering is detected.
• Never trust roles or permissions stored in something the user controls. Keep them on the server.
• Allow only a short list of expected classes during deserialisation.
• Run the code with low privileges and log deserialisation failures.

3.5.5 Misconfigured security headers

HTTP security headers are instructions the server sends to the browser to switch on built in protections. When they are missing or wrong, the browser does not apply them and attacks become easier.

Also remove headers that reveal too much

Headers such as Server: Apache/2.4.7 (Ubuntu) and X-Powered-By: PHP/5.5 tell attackers exactly which versions to target.

# Nginx example
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'" always;
server_tokens off;

Test your headers with browser developer tools (Network tab), with curl -I https://yoursite, or with online header checkers, then fix any that are missing.

3.6 Security measures in software application

Hardening is a combination of technical, procedural and human measures. Use this list as a summary of what to apply.

Secure software development life cycle (SSDLC)

Security is cheaper when it begins early. At each stage of development add a security activity.

Practice exercises

stmt = pdo.prepare("SELECT * FROM learners WHERE adm = :adm")
stmt.execute({"adm": adm})

4. Monitor application security performance

Prevention is never perfect. Monitoring lets you notice an attack quickly, understand what happened, and respond before serious damage is done.

4.1 Factors to consider in monitoring application security performance

4.2 Implementation of monitoring solutions

Steps to implement monitoring

1. Define goals. What attacks or events must you detect?
2. List sources. Web server, application, database, operating system, firewall, authentication system.
3. Turn on logging at each source with enough detail.
4. Centralise logs in one protected place so an attacker who breaks into one machine cannot erase the evidence.
5. Set a baseline of normal activity.
6. Create alert rules with clear thresholds and severity levels.
7. Assign responsibility and write a response procedure.
8. Test and tune by simulating attacks and removing noisy alerts.
9. Review regularly and update as the application changes.

Types of monitoring solutions

4.3 Logs management and monitoring

A log is a time stamped record of an event. Logs answer the questions: who did what, when, from where, and with what result.

Types of logs

• Application logs: errors, user actions, business events.
• Access logs: every request to the web server, with address, page and response code.
• Authentication logs: successful and failed logins, password changes, lockouts.
• System logs: operating system events, service starts and stops.
• Database logs: queries, failed connections, permission changes.
• Audit logs: administrator actions and changes to settings or permissions.
• Firewall and network logs: allowed and blocked connections.

What a good log entry contains

Time (with time zone), user or account, source IP address, action, target resource, result (success or failure), and a request or session reference. Never log passwords, full card numbers or session tokens.

192.168.1.45 - amos [29/Sep/2026:09:14:22 +0300] "POST /login HTTP/1.1" 401 512 "Mozilla/5.0"
Sep 29 09:14:23 web1 sshd[2210]: Failed password for invalid user admin from 203.0.113.9 port 51422 ssh2

The log management life cycle

1. Generate logs at the sources.
2. Collect them to a central server.
3. Normalise them into a common format and synchronise time (use NTP so clocks agree).
4. Store securely with limited access and protection against changes.
5. Analyse manually and with automated rules.
6. Retain for the required time, then dispose of them safely.

Useful commands for reading logs

tail -f /var/log/apache2/access.log              # watch requests live
grep "Failed password" /var/log/auth.log          # find failed SSH logins
journalctl -u nginx --since "1 hour ago"          # service logs with systemd
grep " 500 " /var/log/nginx/access.log | wc -l    # count server errors

4.4 Key metrics to monitor

Metrics are measurable signs of security health. The outline names three key ones. Others give a wider view.

4.4.1 Failed login attempts

A burst of failed logins is a classic sign of brute force (many guesses on one account) or credential stuffing (one guess each on many accounts using leaked passwords).

# Top addresses with failed SSH logins
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

Example alert rule: raise a medium alert when one address causes 10 failed logins within 5 minutes, and a high alert if a success follows.

4.4.2 Unusual API requests

APIs are the doorway that mobile apps and other systems use to reach your data, so attackers probe them heavily. Look for these signs.

• A sudden rise in the number of requests from one client or address (scraping or denial of service)
• Requests to endpoints that are rarely used, or that do not exist (scanning)
• Many 401 and 403 responses (someone testing access) or 404 responses (guessing paths)
• Many 500 errors after strange input (someone probing for injection)
• Unusually large responses or many sequential record numbers requested (data harvesting)
• Requests at unusual hours, from unusual places, or with odd user agent names such as scanning tools
• Changes to normal request size, method or parameters

# Which addresses make the most requests?
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Which requests return 403 or 404?
awk '$9 ~ /403|404/ {print $1, $7, $9}' /var/log/nginx/access.log | head

Controls: rate limiting, API keys or tokens with expiry, input schema validation, authentication on every endpoint and an API gateway with logging.

4.4.3 Changes in application files

Attackers often modify or add files, for example a hidden web shell, a changed login page, or altered configuration. File integrity monitoring compares files to a known good record and reports differences.

What to watch

• Application code and scripts, especially in web folders
• Configuration files
• Uploaded files folders, where new scripts should never appear
• System files and libraries
• File permissions and ownership

# Record a baseline of file hashes
find /var/www/html -type f -exec sha256sum {} \; > baseline.txt

# Later, compare against the baseline
sha256sum -c baseline.txt | grep -v ": OK"

# Files changed in the last day
find /var/www/html -type f -mtime -1

Proper tools such as AIDE, Tripwire or Wazuh automate this, keep the baseline safe, and send alerts. Every unexpected change should be checked. Expected changes, such as a planned update, should be recorded so they are not mistaken for attacks.

Other useful metrics

Practice exercises

5. Prepare a report on software security

Your findings only matter if the right people understand them and act. A good security report is clear, accurate, evidence based and tells the reader what to do next.

5.1 Application summary

5.1.1 Overview of the application

Describe what the application is, who uses it, what data it holds, where it runs, and the technologies involved (language, framework, database, server, hosting). Include the version and the date tested.

5.1.2 Security goals

State what must be protected and why, in terms of confidentiality, integrity and availability. For example: protect learner records from exposure, ensure marks cannot be changed without authorisation, and keep the portal available during registration.

5.1.3 Key findings

Give a short executive summary: the number of findings by severity, the most serious problems, and the overall conclusion in plain language. Example: The assessment found 2 critical, 3 high, 5 medium and 4 low issues. The most serious is SQL injection on the login page that allows access to all learner records.

5.2 Methodology

5.2.1 Assessment approach

Say how the test was done: black, grey or white box, manual and automated, the dates, and any standard followed, such as the OWASP Testing Guide or OWASP Top 10. State the scope and anything left out.

5.2.2 Tools used

List each tool with its version and purpose, for example OWASP ZAP 2.15 for dynamic scanning, Nmap for port discovery, and Nikto for web server checks.

5.2.3 Testing environment

Describe where the tests ran (production, staging or a lab copy), the network position of the tester, accounts and roles used, and any limits such as time windows and excluded systems.

5.2.4 Vulnerabilities and risks

Explain how findings were identified and grouped, and how risk was judged. This links to the rating method below.

5.2.5 Identified vulnerabilities

Each finding should be written in the same structure so it is easy to read and act on.

5.2.6 Severity and impact

Severity says how bad a flaw is. Impact says what could be lost: data exposure, financial loss, downtime, legal penalties or damage to reputation. Always explain the impact in terms the organisation understands.

5.2.7 Risk rating methodology

Risk is commonly judged by combining likelihood (how easy and how probable an attack is) with impact (how damaging it would be).

5.3 Security controls

5.3.1 Existing security measures

List the protections already in place, such as HTTPS, password policy, firewall, backups, logging and multi factor authentication. Recognising what works is fair and useful.

5.3.2 Effectiveness

State how well each control performed during testing. For example: HTTPS was correctly configured (effective). Password policy allowed six character passwords (partly effective). No lockout after failed logins (not effective).

5.4 Recommendations

5.4.1 Security improvements

For every finding give a specific, practical fix, not a general statement. Say what to change and where. For example, replace string built queries in login.php with prepared statements.

5.4.2 Best practices

Suggest wider improvements that prevent whole classes of problems: secure coding training, code review, regular scanning in the build pipeline, patch policy, multi factor authentication, and central log monitoring.

5.4.3 Remediation timeline

5.5 Conclusion

Summarise the overall security position, the most important actions, and the next steps such as a retest date. Keep it short, honest and free of blame. Do not promise that the application is fully secure, because no test can prove that.

5.6 Appendices

5.6.1 Detailed findings

Place long technical evidence here: full scan output, request and response captures, screenshots, and step by step reproduction notes.

5.6.2 References

List standards and sources used, for example the OWASP Top 10, the OWASP Testing Guide, the CVE and NVD databases, CVSS documentation, and vendor advisories.

Report outline at a glance

Title page: application name, version, date, tester, confidentiality level
Document control: version history, distribution list
1. Application summary
   1.1 Overview   1.2 Security goals   1.3 Key findings
2. Methodology
   2.1 Approach   2.2 Tools   2.3 Environment
   2.4 Vulnerabilities and risks   2.5 Identified vulnerabilities
   2.6 Severity and impact   2.7 Risk rating method
3. Security controls
   3.1 Existing measures   3.2 Effectiveness
4. Recommendations
   4.1 Improvements   4.2 Best practices   4.3 Remediation timeline
5. Conclusion
6. Appendices
   6.1 Detailed findings   6.2 References

Practice exercises

6. Manage data and information

Applications exist to handle data. This section covers how to keep records and information organised, correct, protected and lawfully used, which is part of the unit's outcomes.

6.1 Data, information and records

• Data is raw facts, such as marks, names and numbers.
• Information is data that has been processed so it has meaning, such as a learner's average grade.
• Records are information kept as evidence, for example security reports, logs and inventories.

6.2 Data classification

Not all data needs the same protection. Classify it, then apply controls to match.

6.3 Data life cycle and protection

1. Collect only what you need, and tell people why.
2. Store in secure, access controlled places. Encrypt sensitive data at rest.
3. Use according to purpose and permissions.
4. Share only through approved, encrypted channels.
5. Archive what must be kept for legal or business reasons.
6. Dispose securely when no longer needed: secure delete, overwrite or physically destroy media.

6.4 Backup and recovery

Backups protect availability and integrity when data is lost, corrupted or held to ransom.

• Full, incremental and differential backups offer different trade offs between speed and storage.
• Encrypt backups and restrict who can reach them.
• Test restores regularly. A backup that cannot be restored is worthless.
• Set recovery goals: how much data you can afford to lose (RPO) and how fast you must be back (RTO).

6.5 Legal and ethical requirements in Kenya

• Data Protection Act, 2019. Organisations that collect personal data must process it lawfully, fairly and transparently, collect only what is necessary, keep it accurate, store it no longer than needed, secure it, and respect the rights of the person, such as access and correction. The Office of the Data Protection Commissioner oversees compliance, and serious breaches must be reported within the time the law sets (72 hours).
• Computer Misuse and Cybercrimes Act, 2018. Defines offences such as unauthorised access, interference with data and systems, and misuse of computer systems.

Practice exercises

Self test quiz

Twenty questions covering the whole unit. Choose an answer for each, then press the check button to see your score and the reasons.

Glossary

Quick meanings of the key words used in this unit. Type to filter.