Security Discovery Tool
A database-centered cybersecurity project that centralized security discovery data across enterprise sources to improve visibility, data integrity, reporting quality, and incident-response readiness.
Centralizing security data is a database problem
Security Discovery Tool was completed as part of the Academic Industry Immersion Seminar (AIIS) during Summer 2023, connected to a Park Place Technologies industry case study. Working as part of the Database I team, the project focused on a database-first solution to a persistent operations problem: security data scattered across multiple disconnected systems.
The goal was to design a centralized PostgreSQL security database that could consolidate discovery data from enterprise sources — Active Directory, Cisco AMP, and Microsoft Defender — and make that data trustworthy enough to drive faster reporting, cleaner validation, and more confident incident response.
Instead of treating the database as just a storage layer, the work framed it as a security capability: clean schemas, referential integrity, validation rules, source tracking, and recovery planning can directly improve how quickly and confidently a security team responds to threats.
Fragmented security data slows everything down
Security teams need accurate and timely data to understand their environment. But in practice, that data is rarely in one place. Identity records live in Active Directory. Endpoint protection logs sit in Cisco AMP. Threat detections come from Microsoft Defender. Device inventories are maintained in spreadsheets. Compliance documentation is in separate folders.
When these sources are disconnected, several problems compound:
Analysts spend time searching across tools instead of responding to threats.
The same asset may have different names, statuses, or owners across systems.
Incident triage slows when data has to be manually cross-referenced.
Without a central record, compliance reporting becomes labor-intensive.
Duplicate or outdated entries can mislead risk assessments.
Scattered data makes disaster-recovery planning and verification difficult.
The project addressed this problem from the database side: improve the structure, validation, and governance of the security data layer so that analysts and systems above it can operate more reliably.
A validated, centralized security database
The proposed solution was a centralized security discovery database. Instead of leaving security information scattered across tools, the system would collect and normalize records into a consistent relational schema — acting as a trusted layer for reporting, validation, analysis, and response workflows.
Five-stage data pipeline
Design principles
One reliable place to query asset and security posture data reduces manual lookup time and makes reporting repeatable.
Security decisions are only as good as the data behind them. Validation rules, required fields, and referential integrity enforce that quality.
Every record should preserve source, timestamp, and change history to support audits and compliance workflows.
Documentation, naming conventions, and schema clarity ensure future engineers can extend the system without breaking it.
Disaster-recovery procedures and backup validation ensure the database can recover without data loss.
Validation rules must balance strictness with flexibility — a rule that blocks useful data fails its purpose.
Schema built for security operations
The database schema was designed around the key entities a security team needs to query: assets, users, endpoint protection records, security findings, and audit logs. Every table was designed with source tracking and change history in mind.
This relational structure supports stronger reporting than disconnected spreadsheets because records can be joined, validated, audited, and queried consistently. The audit_logs table in particular ensures every data change is traceable — who changed it, when, and from which source system.
Database tools and security context
Stack tags
Database engineering as a security capability
The project demonstrated that a well-designed database is not just a storage layer — it can directly improve security operations. The outcomes connected classroom database concepts to real cybersecurity workflows.
Consolidated queries replaced manual cross-tool lookup, reducing time-to-answer for analysts.
Validation rules and normalization eliminated duplicate, stale, and inconsistent security records across reporting workflows.
Quarterly disaster-recovery simulations confirmed backup integrity and recovery procedures under simulated failure conditions.
Active Directory, Cisco AMP, and Microsoft Defender data unified into a single queryable schema.
Validation rules designed to support compliance-friendly record keeping and audit-ready change history.
Full case study project completed on schedule within the AIIS Summer 2023 cohort timeline.
What this project actually taught
This was one of my first experiences applying computer science skills to a real engineering business problem. A few lessons stuck:
A validated schema with referential integrity, source tracking, and audit logs is not just good engineering — it is a security control. Clean data enables better detection, faster response, and credible compliance.
Validation rules that block too much data fail their operational purpose. The right rule improves quality without stopping useful information from entering the system.
Security and compliance systems only stay useful if they are understandable. Maintainable schemas, clear naming conventions, and written procedures reduce the risk of the system becoming a black box.
AIIS-style projects demand communication, planning, stakeholder alignment, and trade-off analysis. The database schema was only one deliverable; the ability to explain its value mattered just as much.
Most inconsistencies in security data come from mismatched tooling conventions meeting at a shared boundary — not from external threats. Fixing the data layer fixes the downstream problem.
Where this goes next
The core database design establishes a foundation that could be extended into a full security operations platform. A phased roadmap:
- Live dashboard for security posture and asset health
- Automated ingestion connectors for Active Directory, Defender, and endpoint tools
- Role-based access control for analysts, admins, and auditors
- Alert prioritization and severity scoring engine
- Historical trend analysis for endpoint risk
- Data-quality scoring for missing, stale, or conflicting records
- Automated compliance report generation
- Anomaly detection for unusual asset or account behavior
- Audit-ready change history for all critical records
- Backup verification and DR-status dashboards
- Cross-tenant federation for multi-org environments
Security teams often focus on tools, alerts, and dashboards. But behind every security workflow is data. If that data is fragmented, inconsistent, or poorly governed, even advanced tools become less effective.
The Security Discovery Tool project shows that database design is a cybersecurity capability — one that scales across every other layer of the stack.