CIS4368: Introduction to Database Security

Course Description

CIS4368 Introduction to Database Security is the course on protecting the data itself — access control, encryption, auditing, injection defence and the operational practices that keep a database from becoming the breach.

The course is offered at approximately four Florida institutions: Florida A&M University, Florida Gulf Coast University, the University of South Florida and the University of West Florida.

The University of West Florida places it in the College of Science and Engineering, Department of Cybersecurity and Information Technology at 3 semester hours and requires COP 4710 (database systems). ⚠ Its description is unusually specific about the course's provenance: "The Database Security course follows guidelines set forth by the National Security Agency Centers of Academic Excellence in Information Assurance and Cyber Defense. This course is considered a core knowledge unit for institutions to be considered a Center of Academic Excellence."

Florida Gulf Coast University carries it as Introduction to Database Security at 3 credits, "designed to teach students how database systems are used, managed, and issues associated with protecting the associated data assets," with prerequisite COP 3710.

⚠ The NSA/CAE alignment is the most useful thing to know about this course, and it is worth understanding what it means. The National Centers of Academic Excellence in Cybersecurity programme, sponsored by the NSA, designates institutions whose curricula meet defined Knowledge Units. Database security is one of them. UWF is a designated CAE institution and hosts substantial cybersecurity infrastructure including the Florida Cyber Range. The practical consequence for a student: the course content is standardised against a published external specification rather than left entirely to the instructor, and the designation is recognised by federal employers and contractors — which matters in a field where a large share of the well-paid work requires a clearance.

Why database security is its own course rather than a chapter in a general security course. Network and application security defend the perimeter and the code. The database is where the thing worth stealing actually sits — the customer records, the payment data, the health information, the credentials. Attacks that get through everything else end at the data store, and the defences that operate there are specific: they are about who may read which rows, what is recorded when they do, what the data looks like if the file is stolen outright, and how a query can be prevented from doing more than it was meant to.

SQL injection is the course's signature topic, and it deserves the attention. It has been on the OWASP list of critical web application risks for two decades, it remains among the most damaging classes of vulnerability, and — this is the part students find striking — it is completely solved as a technical matter. Parameterised queries and prepared statements eliminate it. It persists because of string concatenation habits, legacy code and dynamic SQL built at runtime. ⚠ Learning to write the vulnerable version, exploit it, and then fix it properly is the standard and correct way to teach this, and it is why the course normally includes a lab environment.

Access control is the conceptual core. Discretionary access control through GRANT and REVOKE, role-based access control, and the principle of least privilege — which is simple to state and almost universally violated in practice, because it is easier to give an application account full rights than to work out what it actually needs. Views as a security mechanism, and row-level and column-level security, are where the theory becomes concrete.

Encryption is treated operationally rather than mathematically. The course is not a cryptography course; it is about where encryption goes and what it does and does not protect — data at rest versus in transit, transparent database encryption, column-level encryption, and the recurring problem that encryption is only as good as the key management, which is where most real deployments fail.

⚠ Compliance is a substantial and unglamorous part of the subject, and students should expect it: HIPAA for health data, PCI DSS for payment cards, FERPA for student records, GDPR where European data is involved, and Florida's own Information Protection Act, which sets breach notification obligations for organisations holding Floridians' personal information. A great deal of professional database security work is driven by these requirements rather than by threat modelling, and knowing them is genuinely employable.

Learning Outcomes

Required Outcomes

• Explain the CIA triad — confidentiality, integrity, availability — as it applies specifically to data at rest and in use.
• Identify the principal threats to database systems — injection, privilege abuse, excessive privilege, inference, insider threat, weak audit, exposed backups.
• Apply discretionary access control — users, roles, privileges, GRANT and REVOKE, ownership chains.
• Apply role-based access control and design a role structure for a stated organisation.
• Apply the principle of least privilege and explain why application accounts commonly violate it.
• Use views, row-level and column-level security as access control mechanisms.
• Explain and demonstrate SQL injection — classic, blind and second-order — in a controlled environment.
• Prevent injection correctly using parameterised queries and prepared statements, and explain why input filtering alone is insufficient.
• Explain authentication options for database systems and the security implications of each.
• Apply encryption appropriately — at rest, in transit, column-level, transparent — and explain what each protects against.
• Explain key management and why it is the common point of failure.
• Design and interpret database auditing and logging, and explain what an audit trail must capture to be useful after an incident.
• Explain inference and aggregation attacks and statistical disclosure, and apply basic mitigations.
• Apply data masking, redaction, tokenisation and anonymisation, and distinguish their guarantees.
• Explain backup, recovery and business continuity as security concerns, including the security of the backups themselves.
• Explain the principal regulatory frameworks — HIPAA, PCI DSS, FERPA, GDPR, and Florida's Information Protection Act — and their database implications.
• Conduct a basic database security assessment and produce a written finding with a remediation recommendation.
• Explain the legal and ethical boundaries of security testing, including authorisation requirements.

Optional Outcomes

• Secure NoSQL and non-relational stores, and explain how their threat models differ.
• Secure cloud-managed databases — shared responsibility, IAM integration, network isolation.
• Apply database activity monitoring and anomaly detection tooling.
• Explain differential privacy and modern statistical disclosure control.
• Explain multilevel security and mandatory access control models — Bell-LaPadula, Biba.
• Perform database forensics after an incident.
• Apply secure development practice for database-backed applications, including ORM pitfalls.
• Apply vulnerability scanning and hardening against CIS benchmarks.
• Explain data governance, classification and retention.
• Explain blockchain and immutable ledger approaches to data integrity.

Major Topics

Required Topics

• Database security fundamentals — assets, threats, the CIA triad applied to data.
• Threat landscape — injection, privilege abuse, insider threat, inference, exposed backups.
• Access control — discretionary, role-based, least privilege, separation of duties.
• Views and fine-grained access control — row and column level.
• SQL injection — mechanics, variants, exploitation in a lab, and correct prevention.
• Authentication and account management for database systems.
• Encryption — at rest, in transit, column-level, transparent; and key management.
• Auditing and logging — what to capture, retention, and use in incident response.
• Inference and aggregation; statistical database security.
• Masking, tokenisation and anonymisation.
• Backup, recovery and availability as security properties.
• Database hardening — configuration, patching, surface reduction.
• Compliance and regulation — HIPAA, PCI DSS, FERPA, GDPR, Florida Information Protection Act.
• Security assessment and reporting.
• Law and ethics of security testing.

Optional Topics

• NoSQL and non-relational security.
• Cloud database security and the shared responsibility model.
• Database activity monitoring and detection.
• Differential privacy.
• Multilevel security models.
• Database forensics and incident response.
• Secure application development and ORM security.
• Benchmarks and automated hardening.
• Data governance, classification and retention.
• Distributed ledger approaches to integrity.

Resources & Tools

• Textbooks in use: Natan, Implementing Database Security and Auditing; Basta and Zgola, Database Security; Afyouni, Database Security and Auditing; Castano et al., Database Security. ⚠ This subject dates quickly, so most instructors supplement heavily with vendor documentation and current advisories — expect the textbook to be a framework rather than the substance.
• The standards and frameworks are the durable material, and they are free: the OWASP Top Ten and OWASP's SQL Injection Prevention and Database Security cheat sheets; NIST SP 800-53 and the NIST Cybersecurity Framework; the CIS Benchmarks for MySQL, PostgreSQL, Oracle and SQL Server; and the PCI DSS standard itself.
• Database platforms you may work in: PostgreSQL and MySQL/MariaDB (free), Microsoft SQL Server Developer Edition (free), Oracle Database Express Edition (free). All support the access control, auditing and encryption features the course covers.
• Deliberately vulnerable practice environments — the standard way this subject is taught safely: OWASP Juice Shop, DVWA (Damn Vulnerable Web Application), bWAPP, and PortSwigger's Web Security Academy (free, excellent, and its SQL injection labs are the best available anywhere).
• Tools: sqlmap for injection testing, Burp Suite Community Edition, Wireshark, and the database vendors' own audit and encryption tooling.
• ⚠⚠ Run all of these only in an environment you are authorised to test. A local virtual machine, a course-provided range, or a platform's own sandbox. Pointing these tools at a system you do not own or have written permission to test is a crime under the federal Computer Fraud and Abuse Act and Florida's Computer Crimes Act — regardless of intent, and regardless of whether damage occurs. This is not a formality; students have been prosecuted.
• Florida context: UWF is an NSA/DHS-designated National Center of Academic Excellence in Cyber Defense and operates the Florida Cyber Range; UCF, USF, FIU, FAU and FSU also hold CAE designations. ⚠ These designations matter for federal hiring and for scholarship eligibility — see below.
• Scholarships worth knowing about: the CyberCorps: Scholarship for Service programme funds cybersecurity study in exchange for federal service, and is available at CAE-designated institutions. It is competitive, generous, and under-applied for.

Career Pathways

⚠ Cybersecurity is one of the few fields where entry-level demand genuinely exceeds supply in Florida, and database security is a specialism within it with a smaller candidate pool than general security.

• Information security analysts (SOC 15-1212) — the primary destination; among the faster-growing occupations nationally.
• Database administrators and architects (SOC 15-1242, 15-1243) — ⚠ security has become a core part of the DBA role rather than an adjacent one, and this course is directly applicable.
• Security engineers and architects (SOC 15-1212).
• Compliance and audit specialists (SOC 13-1041, 15-1212) — HIPAA, PCI DSS and SOX audit work; steady, well paid, and consistently short of qualified people.
• Penetration testers and application security specialists (SOC 15-1212) — ⚠ requires authorisation discipline as much as technical skill; the OSCP and similar certifications are the usual credentials.
• Incident responders and digital forensics analysts (SOC 15-1212, 33-9021).
• Data governance and privacy roles (SOC 13-1041) — a growing function as state privacy statutes proliferate.
• Cloud security engineers (SOC 15-1212, 15-1241).
• Federal and defence cybersecurity — ⚠ this is where the CAE designation pays. Florida's cleared cyber workforce is substantial: US Cyber Command and NSA elements at Fort Gordon-adjacent contractors, CENTCOM and SOCOM at MacDill Air Force Base (Tampa), L3Harris (Melbourne, Palm Bay), Lockheed Martin (Orlando), Northrop Grumman, and the Space Force presence on the Space Coast. Most require US citizenship and a security clearance.
• Healthcare information security (SOC 15-1212) — Florida's large health systems (AdventHealth, Orlando Health, BayCare, Baptist Health, Tampa General) all maintain security teams, and HIPAA makes database security a statutory obligation rather than a preference.
• Financial services and payments security — Florida's banking and payments sector, concentrated in South Florida and Jacksonville.

Certification

• CompTIA Security+ — the standard entry credential, and a DoD 8570/8140 baseline requirement for many defence roles. Take it early; it is the single highest-return certification for a student in this field.
• (ISC)² CISSP — the senior generalist credential; requires five years of experience, but the Associate of (ISC)² status can be earned by passing the examination before you have it.
• ISACA CISA (audit) and CDPSE (privacy) — relevant to the compliance pathway.
• Vendor certifications — Oracle, Microsoft SQL Server and cloud provider security specialties.
• OSCP for offensive roles.

Special Information

⚠ The prerequisite differs, and it is a database-course numbering divergence

Institution	Prerequisite
UWF	COP 4710 — database systems
FGCU	COP 3710 — database systems

Both are the introductory database course; the institutions number it differently — 4000-level at UWF, 3000-level at FGCU. That is a level divergence in the prerequisite rather than in this course, but it has the same consequence: a student arriving with COP3710 at an institution expecting COP4710 may find the prerequisite check fails even though the preparation is present.

⚠ Resolve prerequisite substitutions before registration opens, not during it. A blocked registration in a sequence course costs a term.

The prerequisite is genuine content, not a formality. This course assumes you can already write non-trivial SQL, understand relational schema design, and know what a transaction and a view are. It teaches security on top of database knowledge; it does not teach databases. A student without the prerequisite will spend the term learning SQL while trying to learn how to attack and defend it.

⚠ The NSA/CAE Knowledge Unit alignment — what it does and does not mean

UWF states that this course follows the NSA Centers of Academic Excellence guidelines and is a core Knowledge Unit for CAE designation.

• What it means: the content is mapped to a published external specification, so coverage is more consistent across CAE institutions than an ordinary elective would be. The designation is institutional and programme-level, and it is recognised by federal agencies and cleared contractors.
• What it does not mean: ⚠ it is not a certification you personally hold. You graduate from a CAE-designated programme; you do not become CAE-certified. Say it accurately on a résumé — "graduated from an NSA/DHS-designated CAE in Cyber Defense programme" is both true and worth saying.
• Why it is worth caring about: CAE designation is a prerequisite for CyberCorps: Scholarship for Service eligibility, and it is used as a screening signal by some federal hiring programmes.
• ⚠ Designations are periodically re-reviewed and can lapse. Confirm current status with the institution rather than relying on any secondary source, including this one.

Prerequisites and position in the curriculum

The course sits in the senior year of a cybersecurity, information technology or computer science programme, after the database course and normally alongside or after an introductory security course. It is a required or strongly recommended course in cybersecurity concentrations and an elective in computer science.

⚠ Useful preparation beyond the listed prerequisite: an introduction to information security course supplies the threat vocabulary; networking helps with the transport-layer and architecture material; and any programming experience with a database-backed application makes the injection material click immediately, because you will recognise the code that causes it.

Course format and workload

3 credits, 45 contact hours — lecture with substantial hands-on work. ⚠ Neither UWF nor FGCU carries a C suffix on this number, so laboratory work is normally assigned rather than scheduled — which means the practical hours come out of your own week rather than out of a timetabled block. Plan for that.

Expect 8–10 hours per week outside class. Assessment typically includes hands-on labs, a security assessment project with a written report, examinations, and often a research paper on a current topic or breach.

⚠ Set up your lab environment in week one. Virtual machine, database instance, vulnerable application. Students who defer this lose disproportionate time later, because environment problems block the assignments rather than merely delaying them.

⚠⚠ Legal and ethical boundaries — the most important section on this page

This course teaches attack techniques, because you cannot defend against what you do not understand. That knowledge carries a legal boundary that is absolute and worth stating plainly.

• Only test systems you own or have explicit written authorisation to test. The course lab, your own virtual machine, or a platform that publishes an authorisation to test.
• Unauthorised access is a crime under the federal Computer Fraud and Abuse Act and Florida's Computer Crimes Act (Chapter 815, Florida Statutes), and intent to help is not a defence. Neither is causing no damage. Neither is stopping at proving the vulnerability exists.
• ⚠ "I found it and reported it" is not a legal defence, though it is often treated leniently. If you discover a vulnerability in a system you are not authorised to test — including your own institution's — report it through the proper channel and do not investigate further. Most institutions and many companies have a disclosure process; use it.
• Your institution's acceptable use policy applies to campus networks and systems, and violating it is a disciplinary matter independent of criminal law.
• ⚠ A conviction, or in some cases an unresolved allegation, will end a security career before it starts. This field's employment depends on background investigation and, for the best-paid work, on a security clearance. The professional stakes here are higher than in almost any other discipline.

Articulation and transfer

CIS4368 is a 4000-level upper-division course, not offered at Florida College System institutions, and taken after transfer. The number is consistent across the Florida institutions that carry it, so SCNS articulation is clean.

⚠ Prefix note. CIS is computer information systems; COP is computer programming; CDA computer organisation and architecture; CNT networking; CEN software engineering; CGS general computing. Cybersecurity content is distributed across CIS, CNT and CET depending on the institution, and programmes specify which numbers satisfy which requirement. Related numbers: COP3710/COP4710 (databases), CIS4362 and neighbours (cryptography, network security at various institutions), CIS4622 (FGCU's hands-on cybersecurity course).

AI Integration

⚠ Database security is a field where AI is operationally significant on both sides, and where the study-tool question has an unusually sharp edge.

On the defensive side, machine learning is genuinely deployed: database activity monitoring that flags queries deviating from an established baseline, user behaviour analytics for insider threat detection, automated data classification that identifies sensitive columns across large estates, and anomaly detection in access patterns. ⚠ These are detective controls, not preventive ones, and they generate false positives at rates that make tuning a real job. The course's point stands: an anomaly detector is not a substitute for least privilege.

On the offensive side, the same tooling lowers the cost of attack — automated vulnerability discovery, and notably far more convincing phishing, which matters here because credential theft is one of the main routes to a database.

⚠⚠ The genuinely new problem the course should address: AI systems as a data exposure channel. This is now a live professional issue and it sits squarely in this course's territory:

• Retrieval-augmented systems connected to production databases can leak data across access boundaries if the retrieval layer does not enforce the same row- and column-level controls the database does. Access control has to be applied at retrieval, not merely at the database, and a great many deployments get this wrong.
• Training data extraction — models trained on sensitive records can reproduce them.
• Prompt injection against systems with database access is, structurally, the same problem as SQL injection one layer up: untrusted input reaching an interpreter that acts on it. ⚠ The parallel is exact and instructive, and it is the clearest available illustration that this course's central lesson generalises.
• Employees pasting production data into public AI services is a straightforward confidentiality breach and, for regulated data, a reportable one.

Using AI tools for coursework. Models are useful for explaining a concept, for generating SQL for lab exercises, for explaining what a piece of unfamiliar code does, and for drafting the narrative sections of an assessment report.

⚠ Where they fail, specifically: models produce insecure code by default — string-concatenated queries rather than parameterised ones — because that is what dominates their training data. This course teaches you to recognise exactly that flaw, which makes it a genuinely good exercise: ask for a database-backed login function and audit what comes back. They also invent configuration syntax and vendor features that do not exist, which in a hardening exercise produces a configuration that silently does nothing. Verify against vendor documentation and the CIS benchmarks.

⚠⚠ Two rules specific to this field, and neither is negotiable. First: never paste real credentials, connection strings, production data or client information into an AI service. In professional practice that is a disclosure incident; in coursework it is a habit you cannot afford to form. Second: AI assistance does not extend authorisation. A model will explain how to attack a system it has no idea you lack permission to touch. The legal boundary is yours alone.

Academic integrity. Read the syllabus; computing departments have generally written specific policies. Submitting generated work as your own violates every Florida institution's policy — and in this discipline an academic integrity finding is reportable in background investigations and can be disqualifying for a clearance, which raises the stakes well above the grade.